Redis配置热更新最轻量路径是PUBLISH/SUBSCRIBE，但需独立连接、自动重连重订阅；推荐单key存储+EXPIRE，配合本地缓存；键空间通知仅适用于过期场景；客户端须用AtomicReference等安全替换配置实例。
Redis 作为配置中心时，PUBLISH + SUBSCRIBE 是最轻量的热更新路径
不依赖额外中间件、不改客户端 SDK、不重启服务，靠 Redis 自带的发布订阅机制就能把配置变更实时推到各节点。但前提是：你的应用得自己维护一个长期运行的 SUBSCRIBE 连接，并且能安全地重载配置对象——不是所有框架都支持运行时替换配置实例。
- 必须用独立连接做订阅（不能复用写配置的连接），否则
SUBSCRIBE后该连接进入“订阅模式”，不能再执行SET等命令 - 客户端断连后需自动重连 + 重订阅，Redis 本身不保存订阅关系，断开即丢失
- 消息无持久化，发布时若无人在线，这条更新就丢了；需要强一致性时得配合
SCAN+GET做兜底轮询 - 示例发布命令：
PUBLISH config:app:database '{"host":"new-db","port":5433}'
GET + EXPIRE 组合读取配置，比 HGETALL 更适合单配置项热更新
很多人习惯把整个配置存成 Hash，用 HGETALL config:app 一次性拉全。但这样会导致两个问题：一是字段增减时客户端解析易出错；二是无法对某个配置项单独设过期或触发更新。更稳妥的做法是每个配置项独立 key，用字符串类型存储 JSON 或纯值。
- 更新某项配置：
SET config:app:timeout "3000" && EXPIRE config:app:timeout 86400 - 读取时加一层本地缓存（比如 Guava Cache），避免每次请求都打 Redis；但要注意缓存失效策略必须和 Redis 的
EXPIRE对齐 - 如果用 Hash 存，
HGET config:app timeout可以精准读单字段，但HSET不会触发任何通知，得靠外部发PUBLISH手动通知 - 注意
GET返回null时，要区分是 key 不存在，还是值本身就是空字符串——建议约定空值也写入"null"字符串
监听 __keyevent@0__:expired 通道实现被动式刷新，但只适用于带过期时间的配置
Redis 的键空间通知（Keyspace Notifications）可以让你在 key 过期、删除、修改时收到事件。这对“定时切换配置”场景很实用，比如灰度开关按时间自动关闭。但它不是为热更新设计的通用方案——因为 EXPIRE 触发的是“过期”，不是“更新”。
- 启用前必须配置：
redis.conf中打开notify-keyspace-events Ex（E表示键事件，x表示过期事件） - 订阅命令：
SUBSCRIBE __keyevent@0__:expired（数字0是数据库编号，按实际 DB 调整） - 收到消息如：
config:app:maintenance，说明这个 key 刚过期，可触发一次GET重读，或直接走默认值逻辑 - 陷阱：如果配置没设
EXPIRE，这个通道完全收不到消息；而且它不告诉你新值是什么，只告诉你“旧的没了”
客户端 reload 配置时，AtomicReference 比全局变量更安全，但要注意序列化兼容性
Java 里常见错误是把配置对象存在 static final 字段里，结果 reload() 方法只是 new 了个新对象却没真正替换引用。Python 里则是模块级字典被闭包捕获后无法更新。核心是：运行时替换必须作用于所有正在使用的引用位置。
- Java 推荐用
AtomicReference，更新时调用set(newConfig)，各业务线程通过get()读取最新实例 - Python 可用
types.SimpleNamespace替代 dict，配合globals()['config'] = new_config（需谨慎，仅限单模块场景） - 无论哪种语言，新旧配置类字段名/类型变化时，reload 过程中可能出现
NullPointerException或KeyError，必须做字段存在性校验 - Redis 存的是 JSON 字符串，反序列化失败（比如字段类型从
int改成string）会导致 reload 中断，建议加 try-catch 并 fallback 到旧配置
配置热更新真正的复杂点不在 Redis 怎么发，而在于客户端能否原子、无感、可回滚地切换配置实例——尤其是当多个模块共享同一份配置，又各自持有引用的时候。这里没有银弹，只有根据语言特性和部署形态做针对性裁剪。
