不能直接用作生产级日志主链路，但可作为轻量旁路实时汇总手段——关键在隔离频道、防断连、统一格式、不依赖ACK；混用logs频道会导致来源混淆、限流失效、日志交叉污染，且断连期间消息永久丢失。
不能直接用作生产级日志主链路，但可作为轻量旁路实时汇总手段——关键在隔离频道、防断连、统一格式、不依赖ACK。
为什么不能把所有服务日志塞进一个logs频道
混用频道会导致监控端无法区分来源、无法按服务做限流或告警、排查时日志交叉污染。Redis的PUBSUB不维护订阅者状态，一旦某服务重启或网络抖动，它离线期间发布的日志永久丢失，且其他服务的日志会继续涌入同一频道，进一步掩盖问题。
- 必须按
log:{service}:{env}分层命名，例如log:order-service:prod、log:user-service:staging - 避免使用通配符
PSUBSCRIBE log:*做统一对接——它会拉取所有匹配频道，包括你没权限看的测试环境日志 - 频道名里不要带动态ID（如
log:app:1001），否则订阅端需动态管理成百上千个频道，运维成本爆炸
Python客户端如何稳定监听不掉线
redis-py原生pubsub对象不自动重连，一次网络抖动就永久失联。不能靠get_message()轮询，它返回None时容易跳过消息；必须用listen()阻塞迭代器，它内部已封装心跳与重连逻辑。
- 初始化
Redis实例时传connection_kwargs={'retry_on_timeout': True} - 每次
ps.subscribe('log:payment:prod')后，直接进入for msg in ps.listen():循环 - 捕获
ConnectionError时，重建pubsub对象并重新subscribe，不要试图复用旧对象 - 日志体必须是合法JSON字符串，字段如
{"level":"ERROR","ts":"2026-10-19T15:28:01Z","msg":"timeout","trace_id":"abc123"}，避免换行或未转义引号
用redis-cli快速验证通路是否跑通
别急着写代码，先确认基础链路：发布能发出去、订阅能收到、频道名没拼错、网络和认证没问题。
- 开终端A执行：
redis-cli -h 192.168.1.100 -p 6379 SUBSCRIBE log:auth-service:dev（卡住是正常的，SUBSCRIBE是阻塞命令） - 另开终端B执行：
redis-cli -h 192.168.1.100 -p 6379 PUBLISH log:auth-service:dev '{"level":"INFO","msg":"test from cli"}' - 看到终端A输出
{"type":"message","pattern":null,"channel":"log:auth-service:dev","data":"{...}"}即表示通了 - 注意：
PUBSUB只在DB 0生效，SELECT 1后再PUBLISH会静默失败，不报错也不投递
Spring Data Redis中订阅端怎么避免内存泄漏
RedisMessageListenerContainer默认不自动销毁监听器，若频繁创建/销毁MessageListener实例（比如按服务动态注册），旧监听器可能残留，持续占用连接和线程。
- 监听器类必须是单例（
@Component），不要每次new一个新实例 - 容器启动前，用
pubsub channels log:*命令确认没有残留的旧频道监听 - 关闭应用时显式调用
container.stop()，否则JVM退出前可能仍有未处理完的消息在队列中 - 不要在
onMessage里做耗时操作（如同步写ES），应转发到线程池或消息队列异步处理，否则监听器线程被阻塞，后续消息积压
最易被忽略的一点：Redis PUBSUB没有“消费位点”概念，也没有“消息重放”能力。一旦订阅进程崩溃，重启后只能收到新消息，历史日志全丢——所以它永远只是Kafka或Fluentd链路的补充，不是替代。
