Sentinel和Cluster,到底该怎么选?

技术解析

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

1. 一主一从 (One Master - One Slave)

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

  • • 结构图 : Master ---> Slave

  • • 工作模式:

    • • Master节点负责所有的读写操作。

    • • Slave节点作为Master的一个精确副本,通常用于数据备份或读请求的分担。

  • • 优点: 部署简单,实现了一个基本的热备份。

  • • 缺点:

    • • 存在单点故障 (SPOF) : Master宕机后,写服务中断。需要手动将Slave提升为Master,恢复过程有延迟且可能丢失数据。

    • • 读写压力: 如果Slave既要同步数据,又要承担所有读请求,压力会比较大。

2. 一主多从 (One Master - Multiple Slaves)

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

  • • 结构图 :

    复制代码
      Master
      / | \
     /  |  \
    S1  S2  S3
  • • 工作模式:

    • • Master节点只负责写操作。

    • • 多个Slave节点分担所有的读操作。

  • • 优点:

    • • 高读性能: 可以通过增加Slave节点的数量,线性地扩展系统的读性能。

    • • 高可用性: 任何一个Slave宕机,都不会影响整个系统。

  • • 缺点:

    • • Master写压力大: Master不仅要处理写请求,还要向所有Slave同步数据,复制压力集中在Master上。

    • • Master仍是单点: 写操作的单点故障问题依然存在。

3. 链式/树状主从 (Chained/Tree-like Replication)

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

  • • 结构图 : 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宕机),这位弟子的学习就完全中断了。而且,如果外面有很多人想来参观画作(读请求),都得找这个唯一的弟子,他既要学习临摹,又要接待访客,忙得不可开交(Slave压力大)。

阶段二:"大师开班授课" (一主多从)

  • • 学校模式 : 大师的名气越来越大,他开了一个大型工作室,同时招收了多位学徒。他站在画室中央作画,所有学徒都直接围绕着他进行学习和临摹。

  • • 优点:

    • • 分流参观者 (读扩展): 当有访客想看大师的画风时,可以随便去任何一位学徒的画板前看,不会打扰到正在创作的大师本人。

    • • 传承有保障 (高可用): 任何一位学徒生病了,都不要紧,还有其他学徒在继续学习。

  • • 问题: 大师需要同时指导好几位学徒,确保每个人都看清楚了他的笔法,这让他有点分心(Master复制压力大)。而且,大师本人如果生病了,整个工作室还是得停摆。

阶段三:"师兄带师弟" (链式主从)

  • • 学校模式 : 大师年事已高,成了泰斗。他不再亲自教每一个学生,他只教他最得意的大弟子。然后,他要求大弟子去教二弟子,二弟子再去教小师弟。

  • • 优点: 大师的负担大大减轻,他可以专注于最高深的艺术创作。

  • • 问题 : 大师的一个新技法,要传到小师弟那里,会经过好几手,信息延迟很严重。而且,如果大弟子某天偷懒没来(中间节点宕机),那么他后面的所有师弟今天就都没得学了。

终极形态:引入"自动化管理"

  • • "学院董事会" (Sentinel模式):

    • • 运作方式 : 学校成立了一个由几位德高望重的老先生组成的"董事会 "。他们不画画,唯一的任务就是每天盯着大师的健康状况 。一旦发现大师病倒了,董事会会立刻开会,从所有学徒中投票选出 一位最优秀的,任命为"代理大师",并通知其他学徒:"从现在起,你们都去临摹新大师的作品!"

    • • 解决了 : 大师病倒后,学校无人领导的混乱局面。

  • • "艺术联盟" (Cluster模式):

    • • 运作方式 : 这已经不再是一所学校了。它变成了一个由多位大师组成的"艺术联盟"。

      • • 山水画大师A,带着自己的几个学徒。

      • • 花鸟画大师B,也带着自己的几个学徒。

      • • 人物画大师C,同样带着自己的学徒。

    • • 联盟 (Cluster )负责管理所有资源。当有客户想要一幅"山水画"时(写请求),联盟会直接把他引荐给大师A 。这样,多位客户可以同时向不同的大师约稿 ,整个联盟的创作能力(写性能)得到了极大的扩展。同时,每位大师都有自己的学徒作为备份,保证了传承的稳定。

故事总结:

拓扑结构 核心比喻 解决了什么问题?
一主一从 一对一私教 基础备份
一主多从 大师开班授课 读性能扩展
链式主从 师兄带师弟 减轻主库复制压力
哨兵模式 学院董事会 (自动化) Master自动故障转移
集群模式 艺术联盟 (分布式) 写性能扩展 + 高可用
相关推荐
Promising_GEO7 小时前
GEE实战02期:从卫星波段开始:利用 Sentinel-2 自己计算 NDVI
java·sentinel·遥感·空间分析
我不会起名字3222 天前
Redis 从 0 到 1(九):主库宕机 30 秒自动切主——1 主 2 从 3 哨兵 + Go 客户端
redis·docker·sentinel·高可用·哨兵
Msshu1233 天前
PD快充诱骗取电芯片工作原理,XSP17诱骗取电5V9V12V15V20V功能测试
spring boot·spring cloud·sentinel·java-rocketmq·java-zookeeper·java-consul·java-activemq
流烟默7 天前
Spring Cloud 微服务 Sentinel 热点参数与授权规则集成指南(附架构建议)
spring cloud·微服务·架构·sentinel
Thomas.Sir7 天前
第23课:Sentinel熔断降级、系统自适应保护、集群限流
spring cloud·sentinel
jyOverQ9 天前
Redis 主从复制、Sentinel 和 Cluster 到底有什么区别?
java·redis·sentinel
流烟默10 天前
网关 Sentinel 限流实战:API 分组、规则加载与全量匹配踩坑记
nacos·gateway·sentinel·流控规则
guo_wen_qiang15 天前
云服务器sentinel搭建-控制台
服务器·sentinel
guo_wen_qiang15 天前
项目使用sentinel遇到的问题
java·sentinel
天天喝旺仔1 个月前
分布式服务容错实战:用 Sentinel 实现限流、熔断与降级
分布式·微服务·云原生·sentinel