Redis ( 2 ) 集群设计分压以及高可用哨兵机制 -- COOKIE

目录

 

集群的设计:

     1.节点分离,主从分离,从而读写分离:   master: 写  , slave: 读   

     2. 哈希slot: 减缓写的压力:​

哨兵机制 故障转移：　

哨兵模式工作流程的内部实现：

---

集群的设计:

     1.节点分离,主从分离,从而读写分离:   master: 写  , slave: 读   

 

 1.只有1个Master，可以有N个slaver，而且Slaver也可以有自己的Slaver，由于这种主从的关系决定他们是在配置阶段就要指定他们的上下级关系，而不是Zookeeper那种平行关系是自主推优出来的。

2.读写分离，Master只负责写和同步数据给Slaver，Slaver承担了被读的任务，所以Slaver的扩容只能提高读效率不能提高写效率。

3.Slaver先将Master那边获取到的信息压入磁盘，再load进内存，client端是从内存中读取信息的，所以Redis是内存数据库。

5.当一个新的Slaver加入到这个集群时，会主动找Master来拜码头，Master发现新的小弟后将全量数据发送给新的Slaver，数据量越大性能消耗也就越大，所以尽量避免在运行时做Slaver的扩容。

 

优点：  可以进行读写分离，对读的并发没有限制，扩增slave就可以减轻读的压力；

缺点： 写遇到瓶颈，只有一个master ，数据量大维护这些slave的数据的统一也是有压力的。

 

 

2. 哈希slot: 减缓写的压力:

1.对象保存到Redis之前先经过CRC16哈希到一个指定的Node上，例如Object4最终Hash到了Node1上。

2.每个Node被平均分配了一个Slot段，对应着0-16384，Slot不能重复也不能缺失，否则会导致对象重复存储或无法存储。

3.Node之间也互相监听，一旦有Node退出或者加入，会按照Slot为单位做数据的迁移。例如Node1如果掉线了，0-5640这些Slot将会平均分摊到Node2和Node3上,由于Node2和Node3本身维护的Slot还会在自己身上不会被重新分配，所以迁移过程中不会影响到5641-16384Slot段的使用

 

简单总结下哈希Slot的优缺点：

缺点：每个Node承担着互相监听、高并发数据写入、高并发数据读出，工作任务繁重

优点：将Redis的写操作分摊到了多个节点上，提高写的并发能力，扩容简单。

 

 

双剑合璧：

双剑合璧： 利用hash slot解决并发写的问题，同时利用主从读写分离和哨兵机制解决每个槽的读的压力和监控维护高可用的压力

 

 

 

哨兵机制 故障转移：　

 

由一个或者多个sentinel实例组成的sentinel系统，

作用：监视任意多个master主服务器，以及这些主服务器下的slave从服务器；

如果master挂掉，他会将这个master主服务器下面的从服务器上推选以为出来升级为新的主服务器：

 

具体的流程如下：

 

当原来的主服务器server1出现崩溃，此时Sentinel系统将会在从服务器中选出一个服务器来担任主服务器 :

 

 

 

当原来的主服务器server1恢复服务后，将把server1定义为当前主服务器server2的从服务器

 

 

哨兵模式工作流程的内部实现：

 

 

1. 创建连上主服务器的链接

         当初始化哨兵时，将会向主服务器创建两个链接

         命令链接：主要用来发送命令

         订阅链接：主要用来监听信息

 

        随后哨兵便能通过info命令获取到主服务与所有从服务器的信息，根据反馈内容哨兵在内部构建监视的服务器对象，并实时更新状态 

•  每隔1s，每个S节点会向主节点、从节点、其余S节点发送一条ping命令做一次心跳检测(心跳检测机制)，来确认这些节点当前   是否可达
•  每隔2s，每个S节点会向某频道上发送该S节点对于主节点的判断以及当前Sl节点的信息,同时每个Sentinel节点也会订阅该频     道，来了解其他S节点以及它们对主节点的判断（做客观下线依据）
•  每隔10s，每个S节点（哨兵节点）会向主节点和从节点发送info命令获取最新的拓扑结构

 

 

不仅如此，如果有多个哨兵监视同一个服务器的话，那么哨兵可以通过与主服务器的交互来了解到当前的哨兵系统集

 

 

   哨兵系统监测下线的逻辑；

1.当其中一台哨兵发A现主服务器下线时，此时对A来说主服务器是主观下线，他需要把该消息传递给系统中其他哨兵

2.当其他哨兵B、C接受到A的消息后，会对主服务器进行监测，如果判断为下线，将对A进行反馈，此时如果认为主服务器已经进入下线状态的Sentinel的数量超过配置中设置的quorum值，那么该Sentinel就会认为主服务器已经进入客观下线状态。.选举出某一哨兵节点作为领导者，来进行故障转移。选举方式：raft算法。每个S节点有一票同意权，哪个S节点做出主观下线的时候，就会询问其他S节点是否同意其为领导者。获得半数选票的则成为领导者。基本谁先做出客观下线，谁成为领导者。

 

 

3.当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个Sentinel会进行协商，选举出一个领头，执行故障转移操作:

        1.   在已下线主服务器树下的所有从服务器里面，挑出一个从服务器，并将其转换为主服务器(根据其活跃的状态与级别，                  可 以在从服务器里面进行设置)

       2.   让已下线主服务器树下的所有从服务器改为复制新的主服务器

       3.   将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线

哨兵机制个人总结：

   作用：

1. 设置一个或者一个哨兵集群，来监控者redis集群中的master以及slave
2. 如果有master挂机了，这样哨兵集群就通过选举一个哨兵 执行者 ; 他来做决定接下来那个 slave来作为主服务器，其他的为从服务器
3. 原先宕机的服务器重启之后，会成为当前主服务器的从服务器；

 

 

redis高可用集群的组成：

概述

HA(High Available，高可用性群集)机集群系统简称，是保证业务连续性的有效解决方案，一般有两个或两个以上的节点，且分为活动节点及备用节点。通常把正在执 行业务的称为活动节点，而作为活动节点的一个备份的则称为备用节点。当活动节点出现问题，导致正在运行的业务（任务）不能正常运行时，备用节点此时就会侦测到，并立即接续活动节点来执行业务。从而实现业务的不中断或短暂中断。

Redis 一般以主/从方式部署（这里讨论的应用从实例主要用于备份，主实例提供读写）该方式要实现 HA 主要有如下几种方案：

• keepalived： 通过 keepalived 的虚拟 IP，提供主从的统一访问，在主出现问题时， 通过 keepalived 运行脚本将从提升为主，待主恢复后先同步后自动变为主，该方案的好处是主从切换后，应用程序不需要知道(因为访问的虚拟 IP 不变)，坏处是引入 keepalived 增加部署复杂性，在有些情况下会导致数据丢失
• zookeeper： 通过 zookeeper 来监控主从实例， 维护最新有效的 IP， 应用通过 zookeeper 取得 IP，对 Redis 进行访问，该方案需要编写大量的监控代码
• sentinel： 通过 Sentinel 监控主从实例，自动进行故障恢复，该方案有个缺陷：因为主从实例地址( IP & PORT )是不同的，当故障发生进行主从切换后，应用程序无法知道新地址，故在 Jedis2.2.2 中新增了对 Sentinel 的支持，应用通过 redis.clients.jedis.JedisSentinelPool.getResource() 取得的 Jedis 实例会及时更新到新的主实例地址

 

注意： sentinel 是解决 HA 问题的，cluster 是解决主从复制问题的，不重复，并且经常一起用

 

redis命令的汇总： https://www.jianshu.com/p/3d0289cbd507