Netty服务器需通过Lettuce桥接Redis Pub/Sub，必须复用同一EventLoopGroup、禁用其内部线程池、单例管理连接，并用eventLoop().execute()安全投递消息，同时监听断连事件启用自动重连，配合Redis Stream提升可靠性。
Netty服务器本身不直接支持Redis Pub/Sub，必须通过外部客户端桥接；Lettuce是唯一推荐的集成方案，它原生基于Netty，能复用同一套EventLoopGroup，避免线程切换开销。
Lettuce连接池与Netty EventLoop共享配置
强行让Lettuce用自己的NIO线程组，会和你的Netty服务产生两套独立的I/O调度器，导致CPU缓存失效、上下文频繁切换。关键是要把Lettuce的ClientResources绑定到Netty的EventLoopGroup上。
- 创建
DefaultClientResources.builder()，调用.ioThreadPoolSize(0)禁用Lettuce内部线程池 - 用
.eventLoopGroup(eventLoopGroup)传入Netty的workerGroup（注意：不能是bossGroup） -
RedisClient必须单例，否则连接池无法复用；StatefulRedisPubSubConnection也建议单例或按频道池化 - 不要在
ChannelHandler里每次connect再subscribe，而应在服务启动时完成订阅，并监听ConnectionEvents处理断连重试
订阅消息如何安全投递到Netty Channel
Redis Pub/Sub是异步广播，收到消息后不能直接调用channel.writeAndFlush()——因为Lettuce回调线程和Netty EventLoop线程不是同一个，直接操作会触发IllegalStateException: channel not registered to an event loop错误。
- 必须用
channel.eventLoop().execute()或channel.writeAndFlush().addListener()把写操作切回目标Channel所属的EventLoop - 如果要广播给所有在线Channel，别用
GlobalEventExecutor，而是遍历ChannelGroup，对每个channel单独做eventLoop().submit() - 注意消息体序列化：Lettuce默认返回
byte[]，若你协议是JSON，需提前用StringCodec.UTF8或自定义RedisCodec，否则每次都要new String(bytes)，触发GC
避免Redis订阅连接成为Netty服务的单点故障
一个StatefulRedisPubSubConnection挂了，整个订阅就中断，且Lettuce默认不会自动重连Pub/Sub连接（只重连普通命令连接）。
- 监听
ConnectionEvents.CONNECTED和ConnectionEvents.DISCONNECTED事件，在断连后主动调用connection.setOptions(PubSubConnectionOptions.builder().autoReconnect(true).build()) - 不要依赖Lettuce的
timeout参数来判断离线，Redis本身不发心跳，得自己用ping命令探测或结合ChannelHealthChecker - 如果业务要求强可靠性，别只靠Pub/Sub，应配合Redis Stream + 消费组，用
XREADGROUP拉取，失败可ACK重试；Pub/Sub本质是“发了就算”，网络抖动丢消息不通知
真正难的不是怎么连上，而是当你的Netty服务有5000个长连接，Redis订阅通道突然卡顿1秒，这1秒内涌进来的几百条消息怎么不压垮内存、不阻塞EventLoop——这时候ChannelOption.SO_BACKLOG没用，得靠Lettuce的CommandLatencyCollector监控延迟，再配合背压队列限流。
