Redis PUB/SUB仅适合实时广播，因其无持久化、无送达保证、不支持历史回溯；监控数据应通过TS.ADD落盘至TimeSeries或有序集合，再用TS.RANGE等计算聚合。
Redis 的 PUB/SUB 机制能快速把各节点的性能指标广播出去，但**它本身不存数据、不保证送达、不支持回溯**——所以只适合做「实时通道」，不能当「监控数据库」用。
为什么不用 PUB/SUB 直接存监控数据
发布订阅是纯内存、无持久化的消息中转：一旦订阅者断连、Redis重启，所有中间消息就丢了。而监控数据需要可查、可聚合、可告警，比如「过去5分钟平均延迟 > 200ms」这种查询，PUB/SUB 根本不提供历史窗口。
-
PUBLISH发出的消息不会写入任何键，INFO或KEYS命令都查不到 - 没有 ACK 机制，发布者无法知道谁收到了、谁没收到、谁处理慢了
- 订阅连接被踢掉（如网络抖动）后，重连前的消息完全丢失，无法补推
正确做法：用 PUB/SUB 回传 + TS.ADD 落盘
把 PUB/SUB 当成“快递员”，只负责把指标从节点送到聚合服务；真正存数据、算指标、设告警，交给 Redis 的 TimeSeries 模块（需 Redis 7.0+ 启用 redis-ts 模块）或有序集合 + 过期 TTL 组合。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 各节点用
PUBLISH metrics:node01 "{"cpu":42,"latency_ms":18}"推送原始指标 - 一个常驻的聚合服务
SUBSCRIBE metrics:*，收到后立即解析并写入时间序列：TS.ADD cpu_usage:node01 * 42 RETENTION 3600000 - 用
TS.RANGE或TS.AGGREGATE做滑动窗口计算，例如每10秒取一次平均值 - 关键指标再同步写一份到
HSET metrics_summary:today，方便快速查最新快照
避免踩坑：频道命名与订阅范围要收敛
别让所有节点往同一个大频道（如 all_metrics）狂发，容易压垮订阅端解析逻辑；也别每个指标建一个频道（如 cpu_node01, mem_node01），频道数爆炸且无法统一管理。
- 按「节点维度」分频道更可控：例如
metrics:node01、metrics:node02，聚合服务用PSUBSCRIBE metrics:*匹配 - 避免通配符嵌套过深：
PSUBSCRIBE metrics:*.prod在高并发下会显著增加 Redis CPU 开销（匹配逻辑是 O(N) 遍历） - 生产环境务必给频道加前缀隔离环境：
metrics:staging:node01和metrics:prod:node01，防止测试流量污染线上监控
替代方案：什么时候该换 MQ
如果你发现以下任一情况，说明 PUB/SUB 已经撑不住了：
- 监控数据开始出现「偶发性断流」，且业务方要求「至少一次送达」
- 需要按消费组（consumer group）分流，比如一组做实时告警、另一组做离线训练
- 单节点每秒推送指标超过 5k 条，
SUBSCRIBE客户端频繁超时或丢包 - 需要基于时间戳重放某段历史指标（
PUB/SUB完全不支持）
这时候该切到 Kafka 或 Pulsar——不是因为 Redis 不够快，而是它的设计目标本来就不包括可靠消息传递。
