Redis 的 发布订阅(Pub/Sub)模型 是一种基于 Channel(频道) 的实时消息通信机制
允许发送者(发布者)向频道发布消息,接收者(订阅者)订阅频道并接收消息
Subscribe订阅,Publish发布
角色 |
作用 |
Channel(频道) |
消息传递的通道,订阅者需先订阅频道才能收到发布者发送到该频道的消息。 |
Publisher(发布者) |
向指定频道发送消息的客户端(无需订阅频道)。 |
Subscriber(订阅者) |
订阅一个或多个频道的客户端,实时接收这些频道的消息(阻塞等待)。 |
(1)实时性+无持久化机制
消息无持久化:订阅者只能收到订阅后发布的消息,历史消息无法获取
无消息堆积:若订阅者离线,期间的消息会丢失
(2)广播模式
一个频道的消息会被所有订阅者接收(一对多通信)
(3)无ACK机制
消息发出后,Redis 不确认订阅者是否成功处理(若需可靠性,需自行实现)
维护订阅关系:
使用一个全局字典(Publish_channels)来管理所有 Channel 和订阅关系:
Key:Channel 名称
Value:一个 链表(linked list),存储所有订阅该 Channel 的客户端
消息发布:
从 Publish_channels 字典中查找目标 Channel 的所有订阅者。遍历链表,向每个客户端发送消息
Redis 的 Pipeline(管道) 是一种用于优化大量命令执行的技术,通过减少客户端与服务器之间的网络往返次数(Round-Trip Time, RTT),显著提升批量操作的性能
适用于批量操作:客户端将多个命令一次性打包发送给服务器,服务器按顺序执行后,再将所有结果一次性返回。减少了网络往返次数,尤其适合批量操作(如写入大量数据)
PipeLine的特点:
1.命令批量发送
2.多个命令不具备原子性,其他客户端命令可能穿插执行
3.非阻塞,务器会顺序执行命令,但不会阻塞其他请求
特性 |
Pipeline(管道) |
Redis 事务(MULTI/EXEC) |
Lua 脚本 |
核心目标 |
减少网络往返(RTT),提升批量操作吞吐量 |
保证命令的原子性顺序执行 |
原子性执行复杂逻辑,减少网络交互 |
命令发送方式 |
一次性打包所有命令发送 |
命令先入队, 时批量执行(仍逐条发送) |
脚本整体发送,服务器单线程执行 |
网络优化 |
✅ 大幅减少 RTT(仅 1 次往返) |
❌ 无优化(服务端要发送 |
✅ 脚本单次发送,减少 RTT |
原子性 |
❌ 无原子性(命令可能被其他客户端穿插执行) |
✅ 弱原子性(命令连续执行,但无回滚) |
✅ 强原子性(脚本整体执行,不可打断) |
错误处理 |
需检查返回结果中的错误 |
语法错误会拒绝整个事务,运行时错误继续执行 |
语法错误拒绝执行,运行时错误可自定义处理 |
复杂度 |
低(仅批量发送命令) |
中(需理解事务队列机制) |
高(需编写 Lua 脚本) |
是否阻塞其他客户端 |
❌ 非阻塞 |
❌ 非阻塞(但 时队列命令连续执行) |
✅ 阻塞(脚本执行时单线程处理) |
适用场景 |
批量写入/读取(如数据初始化) |
需要顺序执行的原子操作(如余额扣减) |
复杂逻辑(如库存扣减+日志记录) |
性能 |
⚡️ 极高(纯网络优化) |
中等(无网络优化,但命令连续执行) |
高(单次交互,逻辑在服务端执行) |