redis pub/sub不适合异步任务处理，因其无确认机制、无持久化、不支持消费者组与积压缓冲；应选用lpush+brpop或xadd+xreadgroup(stream)实现可靠任务队列。
Redis 的 PUBLISH/SUBSCRIBE 机制可以快速实现轻量级远程指令下发，但**它不保证送达、不支持应答确认、不保存历史消息**——适合“发了就走”的运维场景（如重启服务、触发备份、清理缓存），不适合要求强一致或需反馈结果的任务。
为什么不能直接用 redis-cli 做生产级远程执行
常见错误是把 redis-cli SUBSCRIBE 当成常驻守护进程跑在目标机器上，结果遇到网络抖动、终端退出、shell 脚本退出就断连，且无重连逻辑。更严重的是：SUBSCRIBE 是阻塞命令，一旦进入监听状态，后续 shell 命令不会执行，导致脚本卡死。
-
redis-cli SUBSCRIBE channel在收到 Ctrl-C 或连接中断后不会自动重试 - 没有心跳保活，TCP 空闲超时（
timeout配置）会静默断开，订阅丢失 - 无法区分消息来源或校验签名，任意能连 Redis 的客户端都可发指令（安全风险）
- 消息体是裸字符串，没结构化字段（如
target、ttl、signature），易误执行
Python 订阅端必须处理的三个关键点
用 redis-py 写订阅脚本时，pubsub.get_message() 默认非阻塞且返回 None，不能直接 while True 循环空转耗 CPU；同时要避免因网络闪断导致整个进程退出。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须设置
pubsub.get_message(timeout=1)，加超时避免忙等 - 捕获
redis.ConnectionError和redis.TimeoutError，发生时重建pubsub实例并重新subscribe - 对收到的
message['data']做基础校验：比如检查是否为合法 JSON、是否含cmd字段、是否带时间戳防重放（如ts > time.time() - 30） - 执行前建议用
shlex.split()解析命令，而非直接os.system()，防止注入（例如data: "reboot; rm -rf /"）
发布端如何避免指令被误刷或重复执行
运维指令不是聊天消息，一次误发可能造成服务中断。发布端要自带约束，不能依赖下游判断。
- 指令必须序列化为字典，至少包含
{"cmd": "systemctl restart nginx", "target": "web-01", "nonce": "abc123"}，用json.dumps()发送 - 使用
redis.Redis().publish()前，先用PUBSUB NUMSUB channel检查当前订阅数，为 0 时拒绝发送（说明目标机器离线或未启动监听） - 敏感操作（如
reboot、drop database）应在发布前加二次确认，或要求携带auth_token字段并与白名单比对 - 不要用通配符频道（如
PSUBSCRIBE ops.*）接收指令，避免模式匹配导致跨环境指令污染
真正上线前必须关掉的 Redis 默认配置
默认的 redis.conf 是本地开发模式，远程指令下发必须显式放开并加固：
-
bind不能只写127.0.0.1，需明确绑定内网 IP（如bind 192.168.10.5）或注释掉以监听所有接口（不推荐） -
protected-mode yes必须改为no，否则非本地连接会被拒绝（但仅限内网环境） -
requirepass必须设置强密码，发布/订阅两端均需传password=xxx参数，否则指令通道裸奔 -
tcp-keepalive 60建议设为 60，避免 NAT 设备或防火墙主动踢掉长连接
最易忽略的是：订阅脚本启动后，Redis 连接对象（redis.Redis()）和 pubsub 对象是两个生命周期。断连时只重建 pubsub 不够，底层连接也需重连——否则 get_message() 会持续抛 ConnectionError 却不恢复。
