Redis集群之主从集群模式(哨兵模式Sentinel)

本文介绍Redis主从集群的部署及测试过程,包括配置主从节点、哨兵进程监测及故障转移机制。通过具体步骤展示如何实现高可用性和数据同步。

前言

Redis集群模式主要有2种:

  • 主从集群
  • 分布式集群。

前者主要是为了高可用或是读写分离,后者为了更好的存储数据,负载均衡。
本文主要讲解主从集群。

与本文相关的代码与配置文件都已经上传至github上:
地址: https://github.com/SeanYanxml/bigdata


主从切换原理

Redis的主从原理与MySQL相似,都是设置两台机器,一主一从。也就是常说的热备与冷备。设置主从的同时,设置两个哨兵进程,用来检测主节点是否宕机。若发现主节点宕机,立马从从节点内选取出合适的节点 作为新的主节点。这点与VIP(虚拟IP技术有点相似)。说的有点抽象,可看原理图,加深印象。原理图如下所示(略):


基本部署操作

基本操作与配置详见我的Redis教程第二篇: Redis & Redis Sentinel 基本使用

操作简略如下:

  • 主节点:启动Redis Server进程与Redis Sentinel进程
  • 从节点:启动Redis Server进程与Redis Sentinel进程

注:特别注意主从节点的redis.conf与sentinel.conf文件的配置,详细更改见Github地址。


测试实验

主要测试实验如下所示:

切换前

  • 主从节点,通过INFO命令查询集群信息;
  • 主从哨兵节点,通过Sentienl mastersSentinel slaves查询集群信息;
  • 主节点更新数据值,查看从节点是否有更改。

关闭主节点

  • 从节点,通过INFO命令查询集群信息;
  • 主从哨兵节点,通过Sentienl mastersSentinel slaves查询集群信息;
  • 从节点更新数据值。

开启主节点

  • 主从节点,通过INFO命令查询集群信息;
  • 主从哨兵节点,通过Sentienl mastersSentinel slaves查询集群信息;
  • 判断主节点是否更新了之前从节点 插入的数据。

实验进行

由于主从的Log太多,这边就放置一张选举 主从切换部分的截图。
Redis 选举

主要总结:

  • 切换前,Redis Server与Sentinel 应当都能够获取到整个集群的信息(包括主从节点),且主节点信息更新,从节点也会更新。
  • 切换中,Sentinel哨兵会重新选举,从节点会更新为主节点。
  • 切换后,原主节点会作为从节点(注意 并不会切换为主节点),切会获取到宕机这段时间的数据,并且作为冷备运行。
  • 当原从节点宕机后,原主节点会再次被选举为主节点。

注: 当使用哨兵后,Jedis内将使用JedisSentinelPool,而不再使用JedisPool,因为后者不具有高可用的性能。


Reference

<think>嗯,用户想了解Redis集群中的主从复制、哨兵机制和分片的概念及实现方式。首先,我需要回忆一下这些技术的基本原理和它们之间的关系。 主从复制,我记得是Redis实现高可用性的基础。主节点负责写操作,从节点复制主节点的数据,处理读请求。引用中提到主从复制是单向的,从节点只能有一个主节点。需要说明复制的流程,比如全量复制和增量复制的区别,以及如何配置。用户提供的引用[2]和[3]里提到主从架构的优势,比如数据冗余和高可用性,这些需要整合到回答中。 然后是哨兵模式主从复制如果主节点挂了,需要手动切换,而哨兵可以自动监控和故障转移。哨兵的作用包括监控、通知、自动故障转移和配置提供。要解释哨兵如何检测主节点下线,如何选举新的主节点,以及如何通知客户端。这里可能需要提到主观下线和客观下线的概念,但用户提供的引用中没有详细说明,所以是否需要补充?不过根据用户的问题,可能需要简要说明。 接下来是分片和集群模式。分片是将数据分布到多个节点,Redis Cluster是官方解决方案。需要解释哈希槽的概念,数据如何分配到16384个槽,节点如何负责这些槽。还要提到客户端重定向和节点间通信,比如Gossip协议。用户提到分片原理,所以需要详细说明数据分片的机制,可能涉及一致性哈希或者Redis的特定实现。 现在,需要确保回答符合用户的要求:结构清晰,分点说明每个概念的定义、原理、实现方式、优缺点。同时,要引用提供的参考文献中的内容,比如引用[2]和[3]关于主从复制的部分,引用[1]可能涉及配置文件的设置,但用户的问题更多是理论上的,所以可能引用较少。 需要检查是否有遗漏的部分,比如主从复制的配置步骤,哨兵的选举过程,集群模式的数据迁移等。但用户可能不需要过于详细的步骤,而是概念和原理层面的解释。另外,用户提到的分片原理是否和集群模式是一回事,需要明确说明Redis Cluster是分片的实现方式。 可能需要注意术语的准确性,比如分片(Sharding)和集群(Cluster)的关系,确保不混淆。此外,回答中需要包含用户提供的引用内容,例如主从复制的数据冗余优势来自引用[2],主节点可写从节点只读来自引用[3]。 最后,生成相关问题时要围绕这三个技术点,可能涉及比较、原理深入、应用场景等。比如主从复制与集群的区别,哨兵如何选举,分片的数据分布方式等。 总结步骤:分三个大点,每个点下分定义、原理、实现、优缺点。使用引用标注来源。确保LaTeX格式正确,行内公式用$,独立公式用$$。最后生成相关问题。</think>### Redis集群架构解析 #### 一、主从复制 **定义** 主从复制是通过数据单向复制实现读写分离的机制,主节点(Master)负责写操作,从节点(Slave)通过复制主节点数据提供读服务[^2][^3]。 **原理** 1. **全量复制**:从节点首次连接主节点时,主节点生成RDB快照文件并传输给从节点,从节点加载数据完成初始化同步。 2. **增量复制**:后续主节点将写命令通过`replication buffer`异步发送给从节点,保持数据一致性。 **实现方式** - 配置从节点:在从节点配置文件中添加`replicaof <master-ip> <master-port>`[^1]。 - 验证:通过`INFO replication`命令查看主从关系。 **优缺点** - 优点:读写分离提升性能;数据冗余提高可用性[^2]。 - 缺点:主节点故障需手动切换;写操作仍为单点瓶颈。 --- #### 二、哨兵模式Sentinel) **定义** 哨兵模式主从复制的升级方案,通过独立进程监控主节点状态,实现自动故障转移。 **原理** 1. **监控**:哨兵每秒向主/从节点发送`PING`命令检测存活状态。 2. **故障判定**:若主节点未响应,哨兵集群通过投票机制将其标记为**客观下线**。 3. **选举新主**:根据优先级、复制偏移量等规则,从从节点中选举新主节点。 4. **切换通知**:更新客户端连接至新主节点。 **实现方式** - 配置文件:启动哨兵进程需配置`sentinel monitor <master-name> <ip> <port> <quorum>`。 - 示例: ```conf sentinel monitor mymaster 127.0.0.1 6379 2 ``` **优缺点** - 优点:自动化故障恢复;支持高可用。 - 缺点:配置复杂;扩容需手动调整。 --- #### 三、分片与集群模式(Cluster) **定义** 分片(Sharding)通过数据分区实现水平扩展,Redis Cluster是其官方分布式解决方案。 **原理** 1. **哈希槽分配**:将数据划分为16384个槽(slot),每个节点负责部分槽。 $$ \text{slot} = \text{CRC16}(key) \mod 16384 $$ 2. **节点通信**:采用Gossip协议交换节点状态信息。 3. **重定向机制**:客户端访问错误节点时,返回`MOVED`指令引导至正确节点。 **实现方式** - 集群配置: ```bash redis-cli --cluster create <node1-ip:port> <node2-ip:port> ... --cluster-replicas 1 ``` - 数据迁移:通过`CLUSTER ADDSLOTS`动态分配槽。 **优缺点** - 优点:支持海量数据;无中心化架构。 - 缺点:跨槽事务不支持;运维复杂度高。 --- ### 对比总结 | 方案 | 适用场景 | 数据一致性 | 扩展性 | |--------------|----------------------|------------|--------| | 主从复制 | 读写分离、备份 | 最终一致 | 垂直 | | 哨兵模式 | 高可用、自动故障转移 | 最终一致 | 有限 | | 集群模式 | 大规模数据、高并发 | 分区一致 | 水平 | ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值