Redis开发与运维学习笔记---(18)

//

Redis开发与运维学习笔记---(18)

//

Redis Sentinel实现原理---(二)

前面的文章讲述了redis sentinel实现原理当中的定时任务、主观下线和客观下线，今天我们来看sentinel领导者选举以及故障转移部分。

sentinel领导者选举

当sentinel节点对于主节点做了客观下线之后，紧接着是选取一位sentinel的领导者，然后这个领导者来完成故障转移工作，注意，这里不需要所有的sentinel都参与故障转移。

Redis sentinel进行选举的过程是使用的raft算法，该算法大家可以搜一些专门的文章去了解，这里仅提供简化版的内容，大致思路如下：

1、每隔在线的sentinel节点都有资格成为领导者，当它确认主节点主观下线的时候(也就是他自己访问不了主节点的时候)，会向其他其他sentinel节点发送sentinel is-master-down-by-addr的命令，要求让自己设置成为领导者。感觉有点一厢情愿。

2、收到命令的sentinel节点，如果没有同意过其他sentinel节点的sentinel is-master-down-by-addr命令，将同意该请求，否则的话，拒绝之

3、如果该sentinel节点发现自己的票数已经大于等于max[quorum，num（sentinel）/2+1],那么它将成为领导者。

4、如果此过程没有选举出领导者，将进入下一次选举。

从上面的例子，不难看出，最先完成了客观下线(超过<quorum>个sentinel节点对它反馈)的sentinel在选举中会占优，因为它能拿到最多的票数。

故障转移

领导者选举处的sentinel节点负责故障转移，具体步骤如下：

1、在所有的从节点中，选出一个节点作为新的主节点，选择方法如下：

a、过滤"不健康"（断线、主观下线）、5s内未回复ping响应、与主节点失联超过down-after-milliseconds*10s的从节点

b、选择slave-priority最高的从节点列表，如果存在则返回，如果不存在，则继续

c、选择复制偏移量最大的从节点，如果存在则返回，不存在则继续

d、选择runid最小的节点

2、sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令，让其成为主节点

3、sentinel领导者节点会向剩余的从节点发送命令，让他们成为新主节点的从节点，复制规则和parallel-syncs参数有关

4、sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复后，命令它去复制新的主节点

sentinel节点运维

节点下线

sentinel节点下线，一般分为临时下线和永久下线，临时下线是指暂时将sentinel节点关闭掉，之后还会重新启动，继续提供服务。永久下线是指将节点关掉后不再使用，需要做一些清理工作，如删除配置文件，持久化文件，日志文件等。

主节点下线方法：

如果需要对主节点进行下线，比较合理的做法是选出一个“更好”的从节点，一般是配置更高的从节点，使用sentinel failover功能将从节点晋升为主节点，注意，此时应该提前将该从节点的slave priority值调高，保证failover之后，它会被提升为主节点。sentinel failover执行命令如下：

sentinel failover master-name

从节点下线方法：

如果需要对从节点或者sentinel节点进行下线，只需要确定好是临时下线还是永久下线，并执行对应的操作即可。如果使用了读写分离，下线从节点需要保证应用方可以感知从节点的下线变化，并把读取请求转移到其他从节点上。

当然，sentinel还是会对这些从节点进行监控。

节点上线

1、添加从节点

添加从节点的场景大致有如下几种，

a、使用了读写分离，但是现有的从节点无法支撑应用方的流量

b、主节点没有可用的从节点，无法支持故障转移

c、添加一个更强悍的从节点利用手动failover替换主节点

添加方法：slaveof master_ip master_port

2、添加sentinel节点

添加sentinel节点的场景有如下几种，

a、当前sentinel节点数量不够，无法达到redis sentinel健壮性要求或者无法达到票数

b、原来的sentinel节点需要下线

添加方法：添加sentinel monitor主节点的配置，使用redis-sentinel启动即可，他将会被自动发现

3、添加主节点

redis sentinel中只有一个主节点，所以一般是需要通过手动failover来进行故障转移，从而产生新的主节点。

节点配置

redis sentinel节点的配置尽可能一致，这样在判断节点故障时会更加准确；redis sentinel节点支持的命令十分有限，不过所幸sentinel节点不存储数据，如果需要修改配置，重新启动即可，但是往往配置修改是所有sentinel节点都要修改，全部重启比较麻烦，所以尽量在一开始就规划好。

redis sentinel高可用读写分离

redis中，从节点一般是作为主节点的后备力量，当主节点出现故障之后，顶替主节点的位置的。如果我们要考虑读写分离的场景，那么从节点的高可用也要得到保证，因为从节点挂掉之后，redis sentinel并不会进行故障转移。

所以，在设计redis sentinel的高可用读写分离时，如果有多个从节点，需要将从节点的列表提供给业务方，让业务方轮询的从从节点的列表中获取能用的从节点，切不可一个业务对应一个从节点，这样极易出现读服务不可用现象。

错误的做法：

正确的做法：