Sentinel和Cluster，到底该怎么选？-EW帮帮网

Redis的主从复制拓扑，从简单到复杂，主要有以下几种形态：

这是最简单、最基础的复制结构。

• 结构图: Master ---> Slave
• 工作模式:
- • Master节点负责所有的读写操作。
- • Slave节点作为Master的一个精确副本，通常用于数据备份或读请求的分担。
• 优点: 部署简单，实现了一个基本的热备份。
• 缺点:
- • 存在单点故障 (SPOF): Master宕机后，写服务中断。需要手动将Slave提升为Master，恢复过程有延迟且可能丢失数据。
- • 读写压力: 如果Slave既要同步数据，又要承担所有读请求，压力会比较大。

这是最常用、最经典的“读写分离”架构。

• 结构图:

  Master
  / | \
 /  |  \
S1  S2  S3

• 工作模式:
- • Master节点只负责写操作。
- • 多个Slave节点分担所有的读操作。
• 优点:
- • 高读性能: 可以通过增加Slave节点的数量，线性地扩展系统的读性能。
- • 高可用性: 任何一个Slave宕机，都不会影响整个系统。
• 缺点:
- • Master写压力大: Master不仅要处理写请求，还要向所有Slave同步数据，复制压力集中在Master上。
- • Master仍是单点: 写操作的单点故障问题依然存在。

这种结构通过让从节点成为其他从节点的“主节点”，来减轻主库的复制压力。

• 结构图: Master ---> Slave1 ---> Slave2 ---> Slave3
• 工作模式:
- • Master只将数据同步给Slave1。
- • Slave1再将数据同步给Slave2，以此类推。
• 优点:
- • 减轻Master负担: 极大地降低了Master的复制压力，使其能更专注于处理写请求。
• 缺点:
- • 同步延迟加剧: 数据每经过一层中继，延迟就会增加。末端的Slave3数据会比Slave1滞后很多。
- • 链路脆弱: 中间的任何一个Slave宕机，都会导致其下游的所有Slave复制中断，需要重新配置。

以上三种是基础构件。在生产环境中，为了解决Master的单点故障问题，我们通常会引入自动化的高可用方案：

• 哨兵模式 (Sentinel):
- • 本质: 一个自动化的监控和故障转移系统，它本身不存储数据。
- • 工作模式: Sentinel进程会监控“一主多从”的拓扑结构。当它发现Master宕机时，会自动在所有Slave中选举出一个新的Master，并通知其他Slave去复制新的Master，同时通知客户端“老大换人了”。
- • 解决了什么: Master的单点故障和自动故障转移问题。
• 集群模式 (Cluster):
- • 本质: Redis官方提供的分布式、去中心化的解决方案。
- • 工作模式: 数据通过哈希槽（hash slots）被自动分片存储在多个Master节点上。每个Master节点自己又可以拥有一或多个Slave节点。
- • 解决了什么:
  - • 写性能瓶颈: 通过将数据分散到多个Master，实现了写的横向扩展。
  - • 高可用: 每个Master都有备份，任何一个Master宕机，其Slave可以被集群自动提升为新的Master。

• 学校模式: 大师在他的私人画室里，只收了一个关门弟子。他亲自手把手地教。
• 优点: 教学关系简单直接。
• 问题: 如果大师生病了（Master宕机），这位弟子的学习就完全中断了。而且，如果外面有很多人想来参观画作（读请求），都得找这个唯一的弟子，他既要学习临摹，又要接待访客，忙得不可开交（Slave压力大）。

• 学校模式: 大师的名气越来越大，他开了一个大型工作室，同时招收了多位学徒。他站在画室中央作画，所有学徒都直接围绕着他进行学习和临摹。
• 优点:
- • 分流参观者 (读扩展): 当有访客想看大师的画风时，可以随便去任何一位学徒的画板前看，不会打扰到正在创作的大师本人。
- • 传承有保障 (高可用): 任何一位学徒生病了，都不要紧，还有其他学徒在继续学习。
• 问题: 大师需要同时指导好几位学徒，确保每个人都看清楚了他的笔法，这让他有点分心（Master复制压力大）。而且，大师本人如果生病了，整个工作室还是得停摆。

• 学校模式: 大师年事已高，成了泰斗。他不再亲自教每一个学生，他只教他最得意的大弟子。然后，他要求大弟子去教二弟子，二弟子再去教小师弟。
• 优点: 大师的负担大大减轻，他可以专注于最高深的艺术创作。
• 问题: 大师的一个新技法，要传到小师弟那里，会经过好几手，信息延迟很严重。而且，如果大弟子某天偷懒没来（中间节点宕机），那么他后面的所有师弟今天就都没得学了。

• “学院董事会” (Sentinel模式):
- • 运作方式: 学校成立了一个由几位德高望重的老先生组成的“董事会”。他们不画画，唯一的任务就是每天盯着大师的健康状况。一旦发现大师病倒了，董事会会立刻开会，从所有学徒中投票选出一位最优秀的，任命为“代理大师”，并通知其他学徒：“从现在起，你们都去临摹新大师的作品！”
- • 解决了: 大师病倒后，学校无人领导的混乱局面。
• “艺术联盟” (Cluster模式):
- • 运作方式: 这已经不再是一所学校了。它变成了一个由多位大师组成的“艺术联盟”。
  - • 山水画大师A，带着自己的几个学徒。
  - • 花鸟画大师B，也带着自己的几个学徒。
  - • 人物画大师C，同样带着自己的学徒。
- • 联盟（Cluster）负责管理所有资源。当有客户想要一幅“山水画”时（写请求），联盟会直接把他引荐给大师A。这样，多位客户可以同时向不同的大师约稿，整个联盟的创作能力（写性能）得到了极大的扩展。同时，每位大师都有自己的学徒作为备份，保证了传承的稳定。

Sentinel和Cluster，到底该怎么选？