Redis哨兵集群

Posted 2023-04-19

参考技术A Redis-Sentinel是redis官方推荐的高可用性解决方案，
当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。

而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave集群，
自动发现master宕机，进行自动切换slave > master

每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令

如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。

如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线

在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令

当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次

若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。

若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

主观下线和客观下线

主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.

SDOWN适合于Master和Slave，只要一个 Sentinel 发现Master进入了ODOWN， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对下线的主服务器执行自动故障迁移操作。

ODOWN只适用于Master，对于Slave的 Redis 实例，Sentinel 在将它们判断为下线前不需要进行协商， 所以Slave的 Sentinel 永远不会达到ODOWN。

Redis主从复制可将主节点数据同步给从节点，从节点此时有两个作用：

但是问题是：

那么这个问题，redis-sentinel就可以解决了

Redis的一个进程，但是不存储数据，只是监控redis

本实验是在测试环境下，因此只准备一台linux服务器用作环境！！

服务器环境，一台即可完成操作

所有配置文件如下

总体redis配置文件如下，6379为master，6380和6381为slave

redis-6380.conf slave配置文件详解，6381端口的配置文件，仅仅和6380端口不一样

在主节点上查看主从通信关系

在从节点上查看主从关系（6380、6379）

此时可以在master上写入数据，在slave上查看数据，此时主从复制配置完成

redis-sentinel-26379.conf配置文件写入如下信息

redis-sentinel-26380.conf和redis-sentinel-26381.conf的配置仅仅差异是port(端口)的不同。
然后启动三个sentinel哨兵

此时查看哨兵是否成功通信

实例的思路

首先查看三个Redis的进程状态

第一个

第二个

第三个

直接干掉master，然后等待其他两个节点是否能自动被哨兵sentienl，切换为master节点

此时查看两个slave的状态

然后会发现slave节点成为master节点！！

Redis的哨兵模式和集群模式

参考技术A 原文地址： https://www.cnblogs.com/itplay/p/11098990.html

哨兵模式 #

哨兵模式是redis高可用的实现方式之一

使用一个或者多个哨兵(Sentinel)实例组成的系统，对redis节点进行监控，在主节点出现故障的情况下，能将从节点中的一个升级为主节点，进行故障转义，保证系统的可用性。

哨兵们是怎么感知整个系统中的所有节点(主节点/从节点/哨兵节点)的 #

首先主节点的信息是配置在哨兵(Sentinel)的配置文件中

哨兵节点会和配置的主节点建立起两条连接命令连接和订阅连接

哨兵会通过命令连接每10s发送一次INFO命令，通过INFO命令，主节点会返回自己的run_id和自己的从节点信息

哨兵会对这些从节点也建立两条连接命令连接和订阅连接

哨兵通过命令连接向从节点发送INFO命令，获取到他的一些信息

a. run_id

b. role

c. 从服务器的复制偏移量 offset

d. 等

因为哨兵对与集群中的其他节点(主从节点)当前都有两条连接，命令连接和订阅连接

a. 通过命令连接向服务器的_sentinel:hello频道发送一条消息，内容包括自己的ip端口、run_id、配置纪元(后续投票的时候会用到)等

b. 通过订阅连接对服务器的_sentinel:hello频道做了监听，所以所有的向该频道发送的哨兵的消息都能被接受到

c. 解析监听到的消息，进行分析提取，就可以知道还有那些别的哨兵服务节点也在监听这些主从节点了，更新结构体将这些哨兵节点记录下来

d. 向观察到的其他的哨兵节点建立命令连接----没有订阅连接

哨兵模式下的故障迁移 #

主观下线

哨兵(Sentinel)节点会每秒一次的频率向建立了命令连接的实例发送PING命令，如果在down-after-milliseconds毫秒内没有做出有效响应包括(PONG/LOADING/MASTERDOWN)以外的响应，哨兵就会将该实例在本结构体中的状态标记为SRI_S_DOWN主观下线

客观下线

当一个哨兵节点发现主节点处于主观下线状态是，会向其他的哨兵节点发出询问，该节点是不是已经主观下线了。如果超过配置参数quorum个节点认为是主观下线时，该哨兵节点就会将自己维护的结构体中该主节点标记为SRI_O_DOWN客观下线

询问命令SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <run_id>

参数意义

ip/port当前认为下线的主节点的ip和端口

current_epoch配置纪元

run_id*标识仅用于询问是否下线

有值标识该哨兵节点希望对方将自己设置为leader

询问时用*，选举时用run_id

leader选举

在认为主节点客观下线的情况下,哨兵节点节点间会发起一次选举，命令还是上面的命令SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <run_id>,只是run_id这次会将自己的run_id带进去，希望接受者将自己设置为主节点。如果超过半数以上的节点返回将该节点标记为leader的情况下，会有该leader对故障进行迁移

故障迁移

在从节点中挑选出新的主节点

a. 通讯正常

b. 优先级排序

c. 优先级相同是选择offset最大的

将该节点设置成新的主节点 SLAVEOF no one,并确保在后续的INGO命令时，该节点返回状态为master

将其他的从节点设置成从新的主节点复制, SLAVEOF命令

将旧的主节点变成新的主节点的从节点

优缺点 #

优点

高可用，在主节点故障时能实现故障的转移

缺点：好像没办法做到水平拓展，如果内容很大的情况下

集群模式 #

官方提供的分布式方案(槽指派/重新分片/故障转移)

集群内的节点，都会有个数据结构存储整个集群内的节点信息

//整体structclusterStateclusterNode *mySelf;  ....  dict *nodes;//集群内的所有节点// 单个节点structclusterNodecharname[];charip[];intport;  clusterLink *link;//保存节点间，连接的信息intflags;//状态标记//节点间连接的信息structclusterLinkmstime_tctime;//创建时间intfd;//tcp套接字描述符sds sndbuf;// 输出缓存区sds rcvbuf;//输入缓存区structclusterNode*node;

槽指派 #

redis集群可以被分为16384个槽，只有这些槽全被指派了处理的节点的情况下，集群的状态才能是上线状态(ok)

操作redis集群的时候，将key作为参数，就可以计算出对应的处理槽上，所以存储等操作都应该在该槽对应的节点上。通过这种方式，可以完美的实现集群存储的水平拓展。

defslot_number(key):returnCRC16(key) &16383//得到的结果就是槽的序号

槽指派的信息是怎么存储的

structclusterStateclusterNode *slots[16384] structclusterNodeunsignedcharslots[16384/8]

通过上面两个结构体中的定义可以看出，槽指派的信息是分了两种方式，保存在结构体里面。

分两种存储的好处

1. 如果需要判断某一个节点负责的槽，只需要获取方式二中的数组做判断就可以

2.如果找某个槽是哪个节点负责，只需要获取方式一的列表，一查就知道

重新分片 #

将已经指派给节点的槽，重新执行新的节点。

故障转移 #

发现故障节点

集群内的节点会向其他节点发送PING命令，检查是否在线

如果未能在规定时间内做出PONG响应，则会把对应的节点标记为疑似下线

集群中一半以上负责处理槽的主节点都将主节点X标记为疑似下线的话，那么这个主节点X就会被认为是已下线

向集群广播主节点X已下线,大家收到消息后都会把自己维护的结构体里的主节点X标记为已下线

从节点选举

当从节点发现自己复制的主节点已下线了，会向集群里面广播一条消息，要求所有有投票权的节点给自己投票(所有负责处理槽的主节点都有投票权)

主节点会向第一个给他发选举消息的从节点回复支持

当支持数量超过N/2+1的情况下，该从节点当选新的主节点

故障的迁移

新当选的从节点执行 SLAVEOF no one,修改成主节点

新的主节点会撤销所有已下线的老的主节点的槽指派，指派给自己

新的主节点向集群发送命令，通知其他节点自己已经变成主节点了，负责哪些槽指派

新的主节点开始处理自己负责的槽的命令

集群模式和哨兵模式的区别 #

哨兵模式监控权交给了哨兵系统，集群模式中是工作节点自己做监控

哨兵模式发起选举是选举一个leader哨兵节点来处理故障转移，集群模式是在从节点中选举一个新的主节点，来处理故障的转移

转自：https://www.jianshu.com/p/d6d2325a5ec7