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