不能直接用PUBLISH/SUBSCRIBE传配置内容，因其即发即弃、不持久、无ACK，订阅者离线或网络抖动即丢失消息，导致集群配置不同步；真数据必须存STRING/HASH，收到通知后再GET拉取。
不能直接用 PUBLISH/SUBSCRIBE 传配置内容，只能当“通知铃”，真数据必须存 STRING 或 HASH，收到消息后再 GET 或 HGETALL 拉取——否则服务重启或断连就会丢配置。
为什么不能把配置值直接塞进 PUBLISH 消息里？
Redis Pub/Sub 是即发即弃模型：消息不持久、无 ACK、订阅者离线就彻底丢失。你发一条 PUBLISH config:timeout "5000"，但某个服务刚好在 GC 暂停或网络抖动，这条消息就永远消失了。线上集群几十个节点，只要有一个没收到，配置就不同步。
- 常见错误现象：后台改了开关，部分机器生效、部分仍走旧逻辑，排查时发现日志里根本没收到任何
message事件 - 真实使用场景：灰度发布功能开关、风控阈值调整、数据库连接超时时间变更——这些都要求强一致性，不能靠“大概率送达”
- 性能影响：JSON 字符串越大，网络传输和反序列化开销越高；而只传 key 名（如
"timeout"），再由客户端按需拉取，更轻量也更可控
如何设计带版本校验的“通知+拉取”流程？
核心是两个 key：一个存配置值，一个存版本号，二者必须原子更新。收到通知后先比版本，再决定是否拉取。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 写配置时用 Lua 脚本或
WATCH+MULTI保证SET config:timeout "5000"和SET config:timeout:version "1717025488"同时成功 - 服务监听
config:updated频道，收到消息（如"timeout"）后，先GET config:timeout:version，只有比本地缓存版本高才执行GET config:timeout - 首次启动必须主动
GET全量配置 key 列表（可用SCAN+KEYS config:*:version），不能只等通知——否则冷启动节点永远不知道当前配置是什么 - Java 客户端建议用
AtomicReference<String>存版本号，避免多线程下脏读；Python 可用threading.local()或全局 dict 加锁
订阅连接断了怎么办？原生命令根本不帮你重连
SUBSCRIBE 是阻塞命令，连接一断，监听就停，且 Redis 服务端不会记住你曾经订过哪个频道。Jedis、redis-py 等默认都不自动重连重订阅，必须自己兜底。
- Python 示例里常见错误写法：
pubsub.subscribe('config:updated'); for msg in pubsub.listen(): ...——一旦网络闪断，整个循环退出，后续消息全丢 - 正确做法：用 while 循环包裹，捕获
ConnectionError后重建pubsub对象，并重新subscribe；同时加time.sleep(1)避免高频重试打爆 Redis - Java 推荐用 Lettuce，开启
setAutoReconnect(true)并配好timeout和reconnectDelay，它能在连接恢复后自动重订阅，比手写逻辑更稳 - 务必用独立连接做订阅——不能复用业务写 Redis 的连接，否则
SUBSCRIBE后该连接进入只读监听状态，再发SET就报错
通配符订阅（PSUBSCRIBE）适合模块化配置吗？
适合，但得配合频道命名规范，且别指望 Redis 帮你过滤消息体。
- 订单服务可
PSUBSCRIBE config:order:*，支付服务PSUBSCRIBE config:pay:*，避免互相干扰 - 发布时按需发到具体频道：
PUBLISH config:order:timeout "3000"、PUBLISH config:pay:retry "3"，Redis 服务端完成匹配，不增加客户端负担 - 注意：通配符只对频道名生效，不是对消息内容；收到消息后仍要解析
msg['channel']确认归属，不能只看 payload - 别用
PSUBSCRIBE config:*这种宽泛模式——随着配置项增多，无效消息堆积会拖慢处理速度
最易被忽略的点：所有配置 key 必须设 EXPIRE，否则 Redis 内存无限增长；而版本 key 的过期时间要略长于配置 key，防止先删版本、后删配置导致比对失效。
