在之前的文章中，FastAPI 学习之路（二十九）使用（哈希）密码和 JWT Bearer 令牌的 OAuth2，FastAPI 学习之路（二十八）使用密码和 Bearer 的简单 OAuth2，FastAPI 学习之路（三十四）数据库多表操作，我们分享了基于jwt认证token和基于数据库创建用户，那么我们今天把这些代码整理下，形成基于数据库用户名密码，登陆验证token存储到redis中。实际

Python 目前已经进化到了 3.11 版本，对操作数据库也提供了相应的异步支持。当我们做一个 Web 服务时，性能的瓶颈绝大部分都在数据库上，如果一个请求从数据库中读数据的时候能够自动切换、去处理其它请求的话，是不是就能提高并发量了呢。下面我们来看看如何使用 Python 异步操作 MySQL、PostgreSQL 以及 Redis，以上几个可以说是最常用的数据库了。至于 SQLServer、

import asyncioimport aioredisasync def operate():conn = await aioredis.StrictRedis(host="", port=xx, password="xx")test = await conn.get("test")print(test)await conn.set("name", "li")name = await conn

实战：Redis 哨兵模式（下）上一篇我们介绍了 Redis Sentinel 的搭建和运行原理，本文我们重点来看下 Sentinel 的命令操作和代码实战。Sentinel 命令操作要使用 Sentinel 实现要连接到 Sentinel 服务器，和连接 Redis 服务相同，我们可以使用 redis-cli 来连接 Sentinel，如下命令所示：[@iZ2ze0nc5n41zomzyqtks

在开始使用消息分组之前，我们必须手动创建分组才行，以下是几个和 Stream 分组有关的命令，我们先来学习一下它的使用。消息分组命令创建消费者群组127.0.0.1:6379> xgroup create mq group1 0-0OK相关语法：xgroup create stream-key group-key ID其中：mq 为 Stream 的 key；group1 为分组的名称；0-

在 Redis 5.0 Stream 没出来之前，消息队列的实现方式都有着各自的缺陷，例如：发布订阅模式 PubSub，不能持久化也就无法可靠的保存消息，并且对于离线重连的客户端不能读取历史消息的缺陷；列表实现消息队列的方式不能重复消费，一个消息消费完就会被删除；有序集合消息队列的实现方式不能存储相同 value 的消息，并且不能阻塞读取消息。并且以上三种方式在实现消息队列时，只能存储单 valu

在 Redis 中提供了专门的类型：Publisher（发布者）和 Subscriber（订阅者）来实现消息队列。在文章开始之前，先来介绍消息队列中有几个基础概念，以便大家更好的理解本文的内容。首先，发布消息的叫做发布方或发布者，也就是消息的生产者，而接收消息的叫做消息的订阅方或订阅者，也就是消费者，用来处理生产者发布的消息。除了发布和和订阅者，在消息队列中还有一个重要的概念：channel 意为

一个问题引发的「血案」曾经发生过这样一件事，我们的 Redis 服务器存储了海量的数据，其中登录用户信息是以 user_token_id 的形式存储的。运营人员想要当前所有的用户登录信息，然后悲剧就发生了：因为我们的工程师使用了keys user_token_*来查询对应的用户，结果导致 Redis 假死不可用，以至于影响到线上的其他业务接连发生问题，然后就收到了一堆的系统预警短信。并且这个假死的

在 Redis 中我们可以给一些元素设置过期时间，那当它过期之后 Redis 是如何处理这些过期键呢？过期键执行流程Redis 之所以能知道那些键值过期，是因为在 Redis 中维护了一个字典，存储了所有设置了过期时间的键值，我们称之为过期字典。过期键判断流程如下图所示：过期键源码分析过期键存储在 redisDb 结构中，源代码在 src/server.h 文件中：/* Redis databas

使用 RDB 持久化有一个风险，它可能会造成最新数据丢失的风险。因为 RDB 的持久化有一定的时间间隔，在这个时间段内如果 Redis 服务意外终止的话，就会造成最新的数据全部丢失。可能会操作 Redis 服务意外终止的条件：安装 Redis 的机器停止运行，蓝屏或者系统崩溃；安装 Redis 的机器出现电源故障，例如突然断电；使用kill -9 Redis_PID等。那么如何解决以上的这些问题呢