使用Redis的Pub/Sub机制实现高效消息发布：PUBLISH channel message 发布消息，SUBSCRIBE channel 订阅通道。结合Lua脚本原子操作避免并发问题，提升吞吐。配置maxmemory-policy allkeys-lru控制内存，pipelining批量发送减少RTT延迟。示例代码：redis-cli --eval script.lua ,key1,key2 ; 脚本中keys[1]为channel，ARGV[1]为message。通过Stream数据结构追加消息：XADD mystream * sensor_id 123 temperature 19.8，实现持久化和消费者组消费，解决丢失和重复问题。

Redis Pub/Sub 优化

Redis Pub/Sub 是轻量级、高性能的消息模式，单机支持每秒数百万消息。瓶颈在于网络延迟，使用pipeline批量PUBLISH命令，减少往返时间。订阅端使用多线程或epoll高效处理事件循环。针对吞吐瓶颈，部署Redis Cluster分片通道，负载均衡发布。延迟优化：本地化订阅，避免跨机订阅；使用RPUSH+BRPOP实现可靠队列，超时重试机制。

解决消息队列延迟

传统MQ如RabbitMQ有元数据开销，Redis Streams无 broker，直接内存操作，延迟低至微秒级。实现：XGROUP CREATE mystream mygroup $ MKSTREAM 创建组，XREADGROUP读取未确认消息，XACK确认。吞吐测试：单节点10万QPS，集群百万QPS。通过LISTPACK编码压缩数据，减少内存和CPU。

高吞吐实现

Redis作为消息队列的核心优势：零配置、亚毫秒延迟、无持久化开销。高效发布：使用MULTI/EXEC事务打包多条PUBLISH。瓶颈解决：监控INFO stats 中的 pubsub_patterns、pubsub_channels，避免订阅爆炸；结合Sentinel高可用，自动故障转移。代码示例：import redis; r = redis.Redis(); p = r.pubsub(); p.subscribe('channel'); for message in p.listen(): print(message['data'])

Stream vs Pub/Sub

Pub/Sub 适合实时广播，丢失可忍；Stream 提供ACK、重试、持久化。混合使用：热点事件Pub/Sub，冷门事件Stream。延迟瓶颈：设置stream.max-len~1000丢弃旧消息；消费者并行XREADGROUP BLOCK 0 COUNT 10。实际案例：电商秒杀，Redis Stream处理订单峰值，吞吐达50万/秒。

性能调优技巧

1. tcp-keepalive 60 保持长连接。2. 客户端连接池复用。3. Lua脚本内联PUBLISH+EXPIRE原子执行。4. 针对延迟，禁用save RDB，使用AOF fsync everysec。吞吐提升：sharding key基于用户ID hash。监控命令：redis-cli --latency，识别瓶颈。

实战部署

部署3节点Cluster，hash-tag {user123}channel 确保同槽。发布端pipeline 100条消息/次。订阅端多进程listen，消息分发到worker。解决瓶颈：backpressure机制，订阅缓冲满时NACK重入队列。测试：压测工具redis-benchmark -t publish -n 1000000 -c 50。

FAQ
Q: Redis Pub/Sub消息丢失怎么处理？
A: Pub/Sub不持久化，改用Streams + 消费者组ACK。
Q: 如何监控Redis消息延迟？
A: 用SLOWLOG和LATENCY命令，设置slowlog-log-slower-than 10000。
Q: 集群环境下吞吐怎么最大化？
A: 分片通道，使用hash-tag，避免跨槽PUBLISH。
Q: Lua脚本在消息发布中作用？
A: 原子执行多命令，如PUBLISH后HINCRBY计数。