作者
编辑撒娇之夜
展出品| csdn (标识： csdn新闻) )。
在说xsdxl之前，先介绍主从复制，Redis的主从复制模式。 如果主节点发生故障而无法提供服务，则需要手动将从节点调整为主节点。 另外，APP端需要修改新主节点的地址。 这种故障转移方式在很多APP场景中是无法忍受的。 正式因为这个问题，Redis提供了Sentinel(xsdxl )体系结构来解决这个问题。
什么是xsdxl？
Redis Sentinel是一种分布式体系结构，它本身也是一个独立的Redis节点。 但是，不保存数据，只支持某些命令。 这样可以自动完成故障检测和故障转移，并通知APP端，从而实现高可用性。
Redis Sentinel包含多个Sentinel节点和Redis数据节点。 每个Sentinel节点监视数据节点和其他Sentinel节点，如果发现节点异常，则通过下划线标识节点，如果识别到主节点，则与其他Sentinel节点协商。 如果大多数Sentinel节点无法到达主节点，则选举将开始，选择Sentinel节点以完成自动故障切换工作，然后将更改通知Redis的APP端。 这个过程是完全自动化的，不需要手动干预。
Sentinel主要提供以下功能：
监视：定期检测Redis数据节点、其他Sentinel节点是否可以到达。
通知—将故障切换的结果通知APP端。
主节点的故障转移：从主节点上升为主节点，维持之后正确的主从关系
配置提供器：客户端在初始化时连接到Sentinel节点的集合，并从中获取主节点信息。
通过在多个Sentinel节点上判断故障，可以有效防止误判断。 另外，如果单个Sentinel节点不可用，则整个Sentinel节点集合仍具有高可用性。
安装和部署
配置说明
3个Sentinel节点，1个主节点，2个从节点。
数据节点的配置
redis-6379.conf
端口6379
动态是
日志文件6739 .日志'
db文件名'双核- 6379.RDB '
DIR '/OPT /软件/Redis /数据'
redis-6380.conf
端口6380
动态是
日志文件' 6780 .日志'
db文件名'双核- 6380.RDB '
DIR '/OPT /软件/Redis /数据'
从属127.0.0.1 6379
redis-6381.conf
端口6381
动态是
日志文件' 6781 .日志'
db文件名'双核- 6381.RDB '
DIR '/OPT /软件/Redis /数据'
从属127.0.0.1 6379
部署sentinel节点
sentinel的默认端口是26379。 在本例中，我们将创建三个sentinel节点： 26379、26380和26381。
redis-sentinel-26379.conf
端口26379
动态是
日志文件' 26379 .日志'
dir/opt /软件/就绪/数据
sentinelmonitormymaster 127.0.0.163792
sentinel down -后- millisecondsmymaster 30000
sentinel并行同步主机1
sentinel failover -时间主机180000
redis-sentinel-26380.conf
端口26380
动态是
日志文件' 26380 .日志'
dir/opt /软件/就绪/数据
sentinelmonitormymaster 127.0.0.163792
sentinel下推-后铣削
conds mymaster 30000sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
redis-sentinel-26381.conf
port 26381
daemonize yes
logfile "26381.log"
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
如果要监控多个主节点，则只需要指定多个 msater-name 来区分不同的主节点即可。
sentinel monitor mymaster-1 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster-1 1
sentinel failover-timeout mymaster-1 180000
sentinel monitor mymaster-2 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster-2 1
sentinel failover-timeout mymaster-2 180000
配置说明：
sentinel monitor
port 指定 sentinel 节点的端口
sentinel monitor master-name 是给要监控的节点起一个名字，ip 和 port 表示监控一个主节点，quorum 表示要判断主节点最终不可达所需要的票数。同时这个参数还与选举领导者有关，至少需要max(quorum,num/2+1)个节点参与选举，才能选出领导者 sentinel，从而完成故障转移。比如总共有 5 个 sentinel 节点，quorum =4 ，name 至少需要 4 个sentinel 节点才可以进行领导者的选举。
当所有节点启动时候，配置文件会发生变化，包括：
sentinel 自动发信了从节点以及其他 sentinel 节点。
去掉里面默认配置，例如 parallel-sync failover-timeout 参数。
添加了配置 纪元相关参数。
sentinel down-after-milliseconds
配置
sentinel down-after-milliseconds <master-name> <times>
每个 sentinel 节点都要定期发送 ping 命令来判断 redis 数据节点和其他 sentinel 节点是否可达，如果超过了down-after-milliseconds 配置的时间且没有有效回复，则判断节点不可达。times 单位是毫秒。
down-after-milliseconds虽然以
sentinel parallel-syncs
配置：
sentinel parallel-syncs <master-name> <nums>
当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs 就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数。如果这个参数配置的比较大，那么多个从节 点会向新的主节点同时发起复制操作，尽管复制操作通常不会阻塞主节点， 但是同时向主节点发起复制，必然会对主节点所在的机器造成一定的网络和 磁盘IO开销。
sentinel failover-timeout
配置：
sentinel failover-timeout <master-name> <times>
failover-timeout通常被解释成故障转移超时时间，但实际上它作用于故障转移的各个阶段:
选出合适从节点；
晋升选出的从节点为主节点；
命令其余从节点复制新的主节点；
等待原主节点恢复后命令它去复制新的主节点。
failover-timeout的作用具体体现在四个方面：
如果Redis Sentinel对一个主节点故障转移失败，那么下次再对该主 节点做故障转移的起始时间是failover-timeout的2倍；
在晋升选出的从节点为主节点阶段如果执行成功，Sentinel节点还会执行info命令来确认a) 阶段选出来的节点确实晋升为主节点，如果此过程执行时间超过failover- timeout时，则故障转移失败；
如果命令其余从节点复制新的主节点阶段执行时间超过了failover-timeout(不包含复制时间)， 则故障转移失败。注意即使超过了这个时间，Sentinel节点也会最终配置从 节点去同步最新的主节点。
部署注意事项
sentinel 节点不应该部署在同一台物理机上；
至少要部署三个以上的奇数 sentinel 节点；
选一套还是多套 sentinel，如果选一套可以一定程度降低维护成本，但是如果 sentinel 节点出现异常，可能会多多个 redis 数据节点造成影响，如果是多套，会造成资源浪费，但是每套 sentinel 都彼此隔离。
客户端连接
客户端连接，以 Java 为例，可使用 jedis 调用 jedisSentinelPool 方法来配置：
public class RedisSentinelClient {
/**
* @param args
*/
public static void main(String[] args) {
Set sentinels = new HashSet;
sentinels.add(new HostAndPort("10.12.37.71", 26379).toString);
sentinels.add(new HostAndPort("10.12.37.72", 26380).toString);
sentinels.add(new HostAndPort("10.12.37.73", 26381).toString);
JedisSentinelPool sentinelPool = new JedisSentinelPool("mymaster", sentinels);
System.out.println("Current master: " + sentinelPool.getCurrentHostMaster.toString);
Jedis master = sentinelPool.getResource;
master.set("username","awen");
sentinelPool.returnResource(master);
Jedis master2 = sentinelPool.getResource;
String value = master2.get("username");
System.out.println("username: " + value);
master2.close;
sentinelPool.destroy;
}
}
实现原理
Sentinel 的三个定时监控任务：
每隔 10 秒向主节点和从节点发送 info 命令获取最新的拓扑。
每隔 2 秒，每个 sentinel 节点会向数据节点的sentinel:hello频道发送该 sentinel 节点对于主节点的判断以及当前 sentinel 节点信息，同时每个 sentinel 节点也会订阅该频道，来了解其他 sentinel 节点以及他们对主节点的判断。
每个 1 秒，每个 sentinel 节点会向主节点、从节点、其他 sentinel 节点发送一条 ping 命令做一次心跳检测，判断节点是否存活。
主观下线：
当节点超过 down-after-milliseconds 没有进行有效回复，就会判定该节点失败，这叫主观下线。
客观下线：
当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel is- master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过
领导者选举：选举的过程非常快，基本上谁先完成客观下线，谁就是领导者。
每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观 下线时候，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令， 要求将自己设置为领导者。
收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令，将同意该请求，否则拒绝。
如果该Sentinel节点发现自己的票数已经大于等于max(quorum， num(sentinels)/2+1)，那么它将成为领导者。
如果此过程没有选举出领导者，将进入下一次选举。
故障转移，在从节点列表中选出一个节点作为新的主节点，选择方法如下：
过滤：“不健康”（主观下线、断线）、5秒内没有回复过Sentinel节 点ping响应、与主节点失联超过down-after-milliseconds*10秒。
选择slave-priority(从节点优先级)最高的从节点列表，如果存在返回，不存在则继续。
选择复制偏移量最大的从节点(复制的最完整)，如果存在则返回，不存在则继续。
选择runid最小的从节点。
【End】