Redis RESP3 Push 类型通知客户端如何兼容

Redis RESP3 Push 不是“另一种普通返回值”，而是服务端可以在连接任意时刻送来的带外数据。客户端要兼容它，关键不是把 RESP2 的数组强行改成 RESP3 的数组，而是让读取器先识别顶层类型：遇到 > 就交给通知处理器，遇到其他类型才继续匹配正在等待的命令回复。Redis 官方文档地址：https://redis.io/docs/latest/。

先分清 RESP3 Push 和普通命令回复

RESP2 的常规连接是请求—响应模型，客户端发出命令后等待下一个返回值。RESP3 仍然保留这个模型，但增加了 Push 类型：服务端可以把通知放在顶层，既可能早于命令回复，也可能晚于命令回复，还可以在没有新命令时单独到达。Push 不会嵌在 Map 或 Array 的内部，所以读取器只要在顶层先看类型字节，就能建立清晰边界。

例如下面是静态协议示意，不是运行日志。第一帧是 Pub/Sub 风格的消息，第二帧才是某个命令的普通返回：

>3\r\n
$7\r\nmessage\r\n
$7\r\norders\r\n
$5\r\nhello\r\n
$5\r\nvalue\r\n

这里不能按“读到第一帧就当作 GET 结果”的思路实现。同步客户端可以循环读取，跳过并分发 Push，直到拿到下一个非 Push 回复；异步客户端则应把 Push 投递给回调、事件队列或专用处理协程。无论采用哪种方式，命令回复的对应关系都不能被通知打乱。

三种兼容方案怎么选

把方案拆成三类，迁移时更容易控制风险。

Redis 6 引入了通过 HELLO 协商协议的方式，Redis 7 以后 RESP2 与 RESP3 客户端都能调用核心命令，但同一命令的返回类型可能不同。因此“服务端升级了但业务没改”并不等于安全兼容，尤其要盘点把数组按固定下标读取、把整数当布尔值的旧代码。

用 HELLO 3 与客户端配置建立兼容边界

新连接可以用 HELLO 3 明确请求 RESP3。成功结果应能看到协议字段为 3；如果服务端不认识 HELLO，或认证参数错误，连接可能仍停留在 RESP2，客户端必须根据实际协商结果决定是否启用 Push 相关能力。

以 Go 的 go-redis 为例，配置层应显式表达协议意图，连接关闭也要交给客户端管理：

opts := &redis.Options{
    Addr:     "localhost:6379",
    Protocol: 3, // 中文：明确要求连接按 RESP3 协商
}
rdb := redis.NewClient(opts)
defer rdb.Close() // 中文：应用退出时释放连接池资源

// 中文：Push 由客户端库的通知处理机制消费，业务代码只接收已分类事件
// 中文：若库回退到 RESP2，不要继续假设同连接会出现 RESP3 Push

如果还启用了服务端辅助客户端缓存，CLIENT TRACKING 在 RESP3 下会把失效消息作为 Push 送到同一连接，或送到重定向连接。这个场景不能只测试一次 GET：还要确认失效事件被消费、缓存条目被移除，并验证业务连接没有把事件当成命令返回。

把 Push 分发和普通回复分开验证

建议按三层验收，而不是只看连接能否建立。

1. 协商层：记录 HELLO 3 的结果，确认实际 proto 为 3；失败时明确记录回退到 RESP2，而不是继续打开 Push 功能。
2. 解析层：构造“Push 在前、普通回复在后”和“普通回复在前、Push 在后”两种输入，确认读取器只把非 Push 帧交给等待中的命令。
3. 业务层：对 Pub/Sub、client tracking 或维护通知分别注册事件处理，检查重复通知、断线重连和队列积压，不用一个通用字符串分支吞掉所有事件。

自写解析器至少要保留两个独立出口：一个是命令回复队列，一个是 Push 回调/事件队列。顶层首字节判断只能说明“这是一帧 Push”，后续仍要按第一个元素的通知名称解释字段；未知通知应可记录并安全跳过，不能因为服务端新增通知类型就让整个连接失步。

哪些场景仍应保留 RESP2

如果现有客户端只支持 RESP2、业务没有同连接通知需求，而且代码大量依赖历史返回形状，继续使用 RESP2 往往是更低风险的选择。需要 RESP3 的新能力时，再为能明确处理返回类型和 Push 的客户端单独开连接或分批灰度。

迁移前可以用下面的清单收口：客户端是否真正支持顶层 >；是否区分 Push 与命令回复；是否覆盖认证失败和服务端不支持 HELLO；是否检查 Map/Set/Null 等返回类型；断线重连后是否重新建立通知处理；以及是否保留 RESP2 的回滚开关。满足这些条件，兼容的判断才从“能连上”升级为“消息和结果都没有串线”。

常见问题

RESP3 Push 只会出现在 Pub/Sub 吗？

不是。Pub/Sub 是常见来源，client tracking 失效消息和部分平台维护通知也可能使用 Push。客户端应按通知名称分发，而不是把所有 Push 都硬编码成一种消息格式。

HELLO 3 成功后，旧代码就一定不用改吗？

不一定。协议协商成功只证明连接进入 RESP3；命令返回类型可能变化，旧代码仍需检查数组、Map、Set、Null 和布尔值的转换。

能不能用一个普通读取函数忽略所有 Push？

只有在业务明确不需要任何 Push 且客户端库已安全丢弃或托管这些帧时才可行。对 Pub/Sub、缓存失效或维护通知连接，忽略 Push 会造成数据过期或事件丢失。