Redis 客户端缓存怎么避免脏数据：CLIENT TRACKING、BCAST 与失效消息处理

商品详情接口明明已经用了 Redis，压测时还是看到每个应用实例不断发同一批 GET product:42。这种读多写少的场景，数据副本可以暂存在进程内存；难点不在读得更快，而在商品改价、上下架后，怎样让每个实例及时丢掉旧值。Redis 的 CLIENT TRACKING 正好提供了服务端协助的失效通知。

把本地缓存当作短暂副本，而不是第二个数据源：先按业务前缀订阅失效消息，收到通知立即删本地键；连接断开时宁可清空相关副本，也不要带着旧值继续命中。

先确认这是不是值得放进进程内存的读路径

本地缓存适合商品标题、价格展示、配置开关这类读频繁、单值不大、允许极短时间延迟后回源的场景。库存扣减结果、支付状态和权限校验逻辑，不适合只靠进程副本承载，这类场景对即时一致性的要求更高。

这里不用急着直接开追踪功能。先从访问日志里梳理出高频访问的键前缀，比如 product:、category:，再确认所有写入操作都统一走 Redis 通路。如果存在脚本绕过 Redis 直接改数据库的逻辑，本地副本不可能收到对应键的变更通知，就不该把这条链路当成可靠的失效来源。

用 BCAST 和 PREFIX 建立失效消息通道

生产环境一般会单独开一条专用连接接收推送，剩下的普通业务连接开启追踪功能，指定接收推送的通路。下面用两个终端操作演示：先在接收方拿到连接编号，再让负责读写的业务连接把 product: 前缀的变更消息转发过去。

# 终端 A：接收失效消息
CLIENT ID
# 假设返回 481

# 终端 B：开启前缀广播追踪
CLIENT TRACKING ON REDIRECT 481 BCAST PREFIX product: NOLOOP
GET product:42

# 任意写入方修改同一键
SET product:42 '{"name":"keyboard","price":199}'

BCAST 的作用是让 Redis 不需要逐个记录每个读连接访问过的所有键，直接把匹配指定前缀的变更通知发给所有订阅该规则的客户端；所以设置前缀的时候要尽量精准收拢范围。商品和类目可以分开配置规则，不要为了省事直接订阅空前缀。NOLOOP 适合写入方本身就已经做了本地缓存删除的场景，避免自己刚写入的操作触发通知又回传给自身，产生不必要的重复处理。

收到失效消息时只做一件事：删掉本地键

接收连接拿到的推送内容会包含失效类型和对应的键列表。应用侧直接把对应键映射到本地缓存里删掉就好；下一次用户请求过来自然会走到 Redis 读取最新值。这里不要在通知回调逻辑里主动拉取新内容预热，批量改价场景下这么做，会把一次写操作扩散成几十上百个实例的同步读请求，直接产生严重的读放大问题。

func onInvalidation(keys []string, local *Cache) {
    for _, key := range keys {
        local.Delete(key)
    }
}

func getProduct(id string, local *Cache, rdb *Client) (string, error) {
    key := "product:" + id
    if value, ok := local.Get(key); ok {
        return value, nil
    }
    value, err := rdb.Get(key)
    if err != nil {
        return "", err
    }
    local.Set(key, value, 30*time.Second)
    return value, nil
}

本地缓存条目最好额外加一个较短的 TTL 兜底。它不能代替失效通知逻辑，而是用来应对消息漏处理、应用进程长时间暂停、接收连接异常这类边缘场景的第二层防护。价格类公开展示的数据 TTL 可以设得更短，体积更大的详情类对象，可以先观察访问命中率，不要盲目把所有键都塞进每个应用实例的内存。

把连接重连和发布动作纳入同一条流程

最容易漏考虑的异常场景是连接重建的处理。连接断开的这段窗口里，应用完全不知道哪些键已经被更新，要是恢复连接之后直接沿用之前存的本地副本，旧数据问题只会零星出现在少数实例上，排查起来难度很高。更稳妥的执行顺序是：先标记接收连接不可用，清空受对应前缀影响的所有本地条目，重连成功后拿到新的接收方连接编号，再重新配置追踪规则恢复服务。

1. 接收连接断开时记录对应前缀和发生时间，临时暂停该前缀的本地缓存命中逻辑。
2. 清理掉 product: 对应的全部进程内副本，避免旧条目跨断线窗口残留。
3. 重连完成后先获取新的接收端连接编号，再由业务读写连接配置 REDIRECT 和 BCAST 规则。
4. 用一次改价搭配两次读取的流程验证：第一次请求直接回源读新值，第二次请求可以正常走本地缓存命中；再次触发改价后对应本地条目会被正常删除。

线上发布新版本的时候也要走一遍同样的校验逻辑。滚动更新流程里，新启动的实例先把失效通知通道搭好再接流量，旧实例下线前先停掉本地缓存命中逻辑，就不会出现一半实例已经完成订阅、另一半还在跑旧逻辑的不一致窗口。

相关问题

BCAST 会不会让 Redis 压力变大？

它不需要单独维护每个读连接访问过的键清单，但匹配到前缀的所有变更都会推送给所有订阅的客户端。前缀范围越宽、订阅的应用实例越多，通知总量就越大，建议先从少量高频、读多写少的键前缀开始试水。

本地 TTL 已经设得很短，还需要失效通知吗？

短 TTL 只能限制旧数据最多残留的时长，没办法在数据更新之后立刻清掉本地旧值。对商品展示价格、活动生效开关这类需要快速同步更新的内容，失效通知搭配短 TTL 兜底的组合可靠性更高。

失效消息丢了怎么办？

可以把通知连接的断开次数、重连耗时、本地缓存清理条目数这几个指标加到监控里。发生断线场景时主动清空对应前缀的本地缓存，后续读取全部走 Redis 回源，比留着没法确认新旧状态的副本要稳妥很多。

能给所有 Redis 键都开客户端缓存吗？

不建议这么做。先观察访问命中率、应用实例总数量和内存占用情况，只为重复读取特征特别明显的前缀启用就行。如果键的访问范围和数据新鲜度要求没梳理清楚，直接用常规的 Redis 集中式缓存反而更容易维护。

收尾：先把失效路径跑通，再追求本地命中率

进程内缓存的核心难点从来不是靠 GET 请求少走一次网络往返，而是每次写入操作之后，所有分散在不同实例里的本地副本都能最终收敛到一致的最新状态。把业务前缀筛选、失效只删不回源、断线清理、发布前验证这几个环节串成统一流程，才能放心把高频热点键留在应用进程的内存里。