redis的redis-cli --subscribe在无公网ip边缘节点上会静默断连，因其未实现重连逻辑，而pubsub依赖长连接，易受nat超时、网关重置或dns漂移影响；需用redis-py手动管理连接，配置tcp保活、心跳验证、异常捕获与连接重建，并辅以本地消息队列兜底。
为什么 redis-cli --subscribe 在无公网IP边缘节点上会断连
边缘节点没公网IP，通常走NAT或内网穿透通道（如frp、ngrok），但Redis的PUBSUB协议依赖长连接+服务端主动推送，一旦TCP空闲超时、中间网关重置连接或DNS缓存漂移，redis-cli --subscribe 就静默断开且不重连。这不是客户端bug，是它根本没实现重连逻辑。
用 redis-py 手动管理连接 + 心跳保活
Python生态里最可控的方式是用redis-py搭配自定义重连策略。关键不是“连上就行”，而是要让连接在NAT超时窗口内持续活跃。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
connection_kwargs中必须设socket_keepalive=True，并配socket_keepalive_options（Linux下常用{socket.TCP_KEEPIDLE: 60, socket.TCP_KEEPINTVL: 30, socket.TCP_KEEPCNT: 3}） - 订阅前用
r.ping()验证连接，失败则重建Redis实例，不要复用已断的连接对象 - 在
pubsub.listen()循环里捕获ConnectionError和TimeoutError，sleep后重新初始化pubsub对象（不是调pubsub.close()再pubsub.subscribe()——旧对象内部状态可能已损坏）
避免用 redis-server 的 notify-keyspace-events 直接推到边缘
如果云端Redis开了notify-keyspace-events Ex，再让边缘节点直接PSUBSCRIBE __keyevent@0__:expired，看似省事，实则风险高：keyspace事件量大时会积压、丢失，且事件不带业务上下文。更稳的做法是云端用PUBLISH channel:alarm {json}显式发消息，边缘只订阅固定channel，并在消息体里塞timestamp和seq用于幂等与断点续订。
边缘侧加一层本地消息队列兜底
即使做了心跳和重连，网络抖动仍可能导致几秒消息空白。建议在边缘节点本地跑一个轻量级sqlite或redis-server --port 6380（内存模式），收到云端消息后先落本地队列再通知业务模块。这样重启或短暂失联后，能从本地读取未处理消息，避免“一断就丢”。注意：本地Redis不能用appendonly yes（写放大），改用save ""禁用RDB，靠进程生命周期管理数据即可。
