文章

4.Redis模式总结

发表于
作者 lfj
4 分钟阅读

分工

1
2
3
4
5
6
7
8
9
10
11

        ┌-------- 高可用 ---------------------┐
        │                         │
   +----+-----+             +-----+----+
   │  Master  │◀---failover─│  Slave   │  Slave 随时
   │  写+读   │          │  热备    │  准备升主
   +----------+             +----------+
        ▲  ▲                       │
        │  └----- 同步 -----------------------┘
        │                          │
        └--------- 高并发 ---------------------┘
              水平加更多 Master-Replica 组

「主从 + 哨兵」模式

  • 默认行为：客户端只连主节点，读写都在主节点完成，从节点纯粹是热备 。
  • 想直接用从节点读：
    • 业务侧主动建一条连接到从节点；
    • 在连接上先执行 READONLY；
    • 之后就能发只读命令。
  • 结果：只要客户端愿意做这两步，从节点可以被“直接”使用，常见场景是读写分离、分析报表等对延迟不敏感的读。

Redis Cluster 模式

  • 默认路由表只有「槽 → 主节点」映射；
  • 官方 SDK 默认把请求发到主节点；
  • 要让从节点参与读，必须：
    • 客户端实现 READONLY + 槽位到从节点的二次路由；
    • 自己处理「从节点 lag」「主从切换后连接刷新」等细节。
  • 结果：理论上能读从，但官方不自动做，成本高，所以生产里绝大多数集群仍全部走主节点。

节点行为

模式主节点从节点从节点能否被直接读读请求默认行为
主从+哨兵读写只读✅ 可以，连过去发 READONLY 即可优先走主节点
Cluster读写只读⚠️ 可以，但客户端要自己维护复杂路由优先走主节点

高可用/高并发原因

一、高可用：从节点 = 热备 + 自动升主

  1. 哨兵模式 主宕机 → 哨兵投票 → 把其中一个从节点 slaveof no one 提为新主；业务方只感受到秒级闪断，数据服务继续。
  2. Cluster 模式 每组主自带 1~N 个从；集群内部 Gossip 探测失败 → 剩余主节点投票 → 直接把从提拔成新主，槽位不丢。整个过程完全自动，从节点就是“随时待命的替身”。

二、高并发：靠“加主节点”水平扩展，而不是硬啃读写分离

  • 写只能走主 → 把主节点数量从 3 组扩到 5、10、20 组，写吞吐线性翻倍。
  • 每加一组主，同时也多了一台物理 CPU + 网卡 + 内存；即使读也全部走主，总QPS 照样随节点数线性增加（实测单分片 10w+ QPS 很轻松）。
  • 运维成本最低：客户端零改造，无延迟顾虑，无一致性问题。

三、读写分离到底用不用？——看场景，不是刚需

读写分离 = “写”只打主节点，“读”尽量打到从节点

使用场景:

  • 线上业务往往是读 » 写（10:1 甚至 100:1）。
  • 主节点单机能扛的写够用，但读 QPS 先顶到天花板。
场景是否值得把从节点拉出来读
读 » 写，且对毫秒级延迟不敏感、允许短暂脏读✅ 可做，省几台主节点钱
读/写比例 < 5:1，或业务对一致性/延迟敏感❌ 直接加主更简单、更稳
Redis, Redis模式
Redis

© 2024- lfj