Redis RESP3协议作为Redis 6.0引入的新一代通信协议，对原有的RESP2进行了大幅升级。其中最引人注目的特性之一就是Push推送模式的加入。这种模式允许Redis服务端在客户端没有发送任何命令的情况下，主动向客户端推送数据。这一改变对于需要实时数据通知的场景来说意义重大，尤其是在缓存失效通知和集群拓扑变更通知等场景中，Push推送模式展现出了独特的优势。
RESP3协议基础与Push类型定义
RESP3协议是Redis 6.0引入的新一代通信协议，相比RESP2，它增加了更多数据类型和更丰富的响应格式。在RESP3中，每个数据帧的第一个字节用于标识数据类型。Push推送类型使用特定的字节标识来区分于其他类型的响应。在RESP3规范中，Push类型使用大于号字符作为帧类型标识，后面紧跟一个包含两个元素的数组，第一个元素是推送类型字符串，第二个元素是推送的具体数据。
在传统的RESP2协议中，客户端发送命令后，服务端必须返回一个对应的响应。这种严格的请求-响应模型虽然简单可靠，但在某些场景下显得不够灵活。比如当客户端正在等待一个长时间运行的命令返回时，如果服务端需要通知客户端某些紧急信息（如键空间事件），在RESP2中是无法做到的，因为连接正在被当前命令占用。客户端只能等待当前命令返回后，才能处理其他逻辑。
RESP3的Push类型正是为了解决这个问题而设计的。当服务端需要推送数据时，它会发送一个以Push类型标识开头的数据帧，客户端读取到这个标识后，就知道这不是对某个命令的回复，而是服务端主动推送的带外数据。这种设计使得连接复用变得更加安全，即使在命令执行期间也能接收推送。需要注意的是，Push消息不会占用命令的回复槽位，客户端在收到Push消息后，仍然需要继续读取流数据来获取真正的命令响应。
Push推送模式的工作原理与协议格式
Push推送模式的工作原理可以从服务端发送和客户端接收两个角度来理解。从服务端角度看，当Redis需要向客户端推送消息时，它会构造一个Push类型的数据帧。这个数据帧的第一个字节是大于号字符，后面跟着一个数组，数组中包含推送的类型标识和具体的数据内容。推送类型是一个字符串，目前Redis定义了几种标准推送类型，包括invalidate（缓存失效通知）等。
从客户端角度看，处理Push消息需要客户端库的支持。当客户端发送了一个命令并等待响应时，它可能会在读取响应流的过程中遇到Push类型的数据帧。此时客户端需要先处理Push消息，然后继续读取真正的命令响应。这就要求客户端的协议解析器能够正确区分Push帧和普通响应帧。一个设计良好的客户端库应该将Push消息的处理与普通命令响应的处理完全解耦，通过回调函数或事件机制将Push消息传递给上层应用。
下面通过一个具体的协议交互示例来展示Push帧的格式。假设Redis服务端要推送一个缓存失效通知，告诉客户端key1和key2已经失效，那么它发送的数据帧如下：
>4 $9 invalidate *2 $4 key1 $4 key2
在这个示例中，第一行的大于号表示这是一个Push类型的帧。后面的4表示这个Push帧包含4个元素（注意这里使用了RESP3的属性扩展格式）。第一个元素是字符串invalidate，表示推送类型为缓存失效通知。后面的内容则是具体的失效键列表。客户端在解析到这个帧后，应该触发相应的缓存失效回调，将本地缓存中对应的key1和key2删除。
Push推送的实际应用场景与代码实现
Push推送模式在实际应用中有几个典型场景。第一个是缓存失效通知。在Redis集群中，当某个键被修改或删除时，服务端可以通过Push模式通知所有订阅了该键的客户端，让它们更新本地缓存。这种机制被称为client-side caching，是Redis 6.0引入的重要特性。通过Push推送，客户端可以在不额外占用连接的情况下，实时感知缓存键的变化，从而保证本地缓存与Redis服务端数据的一致性。
第二个典型场景是集群拓扑变更通知。当Redis Cluster的节点信息发生变化时，比如某个节点下线或者新增了节点，集群可以通过Push模式通知客户端更新路由表。在传统的RESP2协议中，客户端只能通过定期执行CLUSTER NODES命令来轮询集群状态，这种方式不仅增加了网络开销，还存在感知延迟。而通过Push推送，客户端可以在拓扑变更的第一时间收到通知，立即更新路由策略。
下面通过Python代码展示如何使用支持RESP3的客户端库来接收Push消息。以redis-py库为例，首先需要建立RESP3连接并开启Push通知：
import redis
# 创建RESP3连接
r = redis.Redis(host='127.0.0.1', port=6379, protocol=3)
# 定义Push消息回调函数
def handle_push(message):
print(f"收到Push消息: {message}")
if message[0] == b'invalidate':
# 处理缓存失效通知
invalidated_keys = message[1]
for key in invalidated_keys:
print(f"键 {key} 已失效，需要更新本地缓存")
# 注册Push消息处理器
r.register_push_handler(handle_push)
# 开启缓存失效通知
r.execute_command('CLIENT', 'TRACKING', 'ON', 'BCAST')
# 正常执行命令，同时可以接收Push消息
r.set('mykey', 'myvalue')
value = r.get('mykey')
print(f"获取到值: {value}")
# 当其他客户端修改了mykey时，当前客户端会收到Push通知
在这段代码中，首先创建了一个使用RESP3协议的Redis连接。然后定义了一个回调函数handle_push来处理Push消息。当收到invalidate类型的推送时，函数会遍历失效的键列表并打印提示信息。通过register_push_handler方法将回调函数注册到连接上后，客户端在执行任何命令的过程中都可以接收并处理Push消息。最后通过CLIENT TRACKING ON BCAST命令开启了广播模式的缓存追踪，这样当任何客户端修改了被追踪的键时，服务端都会通过Push模式通知当前客户端。
Push模式与传统Pub/Sub的对比分析
虽然Push推送模式和传统的Pub/Sub机制都能实现消息推送，但它们在实现方式和适用场景上有很大区别。传统的Pub/Sub需要客户端显式执行SUBSCRIBE命令来订阅频道，而且订阅后该连接只能用于接收消息，不能再执行其他命令。这是因为SUBSCRIBE命令会改变连接的状态，使其进入订阅模式，在此模式下服务端只会发送消息而不会接受其他命令。如果客户端既需要订阅消息又需要执行普通命令，就必须维护两个连接。
而Push推送模式是在普通连接上进行的，客户端可以在执行其他命令的同时接收推送消息。Push消息是带外数据，不会影响命令的请求-响应配对关系。这意味着客户端只需要一个连接就能同时完成命令执行和消息接收，大大简化了连接管理的复杂度。此外，Push推送是由服务端主动发起的，客户端不需要显式订阅某个频道，只需要在连接建立时通过命令（如CLIENT TRACKING）开启相应的推送功能即可。
下表对两种机制的关键特性进行了对比：
| 特性 | Push推送模式 | 传统Pub/Sub |
|---|---|---|
| 连接占用 | 不独占连接，可与命令复用 | 独占连接，无法执行其他命令 |
| 订阅方式 | 通过命令开启，无需显式订阅频道 | 需要执行SUBSCRIBE命令订阅频道 |
| 消息类型 | 结构化数据，支持多种推送类型 | 简单的字符串消息 |
| 协议要求 | 需要RESP3协议支持 | RESP2和RESP3均支持 |
| 典型场景 | 缓存失效通知、集群拓扑变更 | 实时消息广播、聊天室 |
从对比可以看出，Push推送模式更适合需要与命令执行并行的通知场景，而Pub/Sub则适合纯粹的消息广播场景。在实际应用中，应该根据具体需求选择合适的机制。如果应用需要同时执行Redis命令和接收通知，Push推送模式是更好的选择；如果应用只需要接收广播消息而不需要执行其他Redis命令，Pub/Sub则更加简单直接。
需要注意的是，Push推送模式目前需要客户端库的支持。并非所有的Redis客户端库都已经实现了RESP3协议和Push消息处理。在选择客户端库时，需要确认其是否支持RESP3协议以及是否提供了Push消息的回调机制。随着RESP3协议的普及，越来越多的客户端库正在添加对Push推送模式的支持，这将使得这一强大特性得到更广泛的应用。
Redis RESP3Push推送协议解析修改时间：2026-08-23 01:53:34