Redis主从集群架构的升级版。
sentinal,哨兵,redis集群架构中非常重要的一个组件,主要功能如下
哨兵本身也是分布式,作为一个集群运行:
目前采用的是sentinal 2版本,sentinal 2相对于sentinal 1来说,重写了很多代码,主要是让故障转移的机制和算法变得更加健壮和简单
哨兵 + Redis主从的部署架构不保证数据零丢失,只保证redis集群的高可用性。
必须部署2个以上的节点。若仅部署2个实例,quorum=1
+----+ +----+
| M1 |---------| R1 |
| S1 | | S2 |
+----+ +----+
Configuration: quorum = 1
master宕机,s1和s2中只要有1个哨兵认为master宕机就可以进行切换,同时会在s1和s2中选举出一个执行故障转移. 但此时,需要majority,也就是大多数哨兵都是运行的,2个哨兵的majority就是2
2个哨兵的majority=2 3个哨兵的majority=2 4个哨兵的majority=2 5个哨兵的majority=3
2个哨兵都运行着,就可以允许执行故障转移
若整个M1和S1运行的机器宕机了,那么哨兵仅剩1个,此时就无majority来允许执行故障转移,虽然另外一台机器还有一个R1,但故障转移不会执行
+----+
| M1 |
| S1 |
+----+
|
+----+ | +----+
| R2 |----+----| R3 |
| S2 | | S3 |
+----+ +----+
Configuration: quorum = 2,majority
若M1节点宕机了,还剩下2个哨兵,S2和S3可以一致认为master宕机了,然后选举出一个来执行故障转移
同时3个哨兵的majority
是2,所以余存的2个哨兵运行着,就可执行故障转移
Redis 主节点
[启动]
redis-server redis- 7000.conf
[配置]
port 7000
daemonize yes
pidfile /var/run/redis-7000.pid
logfile "7000.log"
dir "/opt/soft/redis/data/"
Redis 从节点
[启动]
redis-server redis-7001.conf
redis-server redis-7002.conf
slave-1[配置]
port 7001
daemonize yes
pidfile /var/run/redis-7001.pid
logfile "7001.log"
dir "/opt/soft/redis/data/"
slaveof 127.0.0.1 7000
slave-2[配置]
port 7002
daemonize yes
pidfile /var/run/redis-7002.pid
logfile "7002.log"
dir "/opt/soft/redis/data/"
slaveof 127.0.0.1 7000
Sentinel 主要配置
port $(port)
dir "/opt/soft/redis/data/"
logfile " $(port).log"
sentinel monitor mymaster 127.0.0.1 7000 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
JedisSentinelPool sentinelPool = new JedisSentinelPool(masterName, sentinelSet, poolConfig, timeout);
Jedis jedis = null;
try {
jedis = redisSentinelPool.getResource();
//jedis command
} catch (Exception e) {
logger.error(e.getMessage(), e);
} finally {
if (jedis != null)
jedis.close();
}
单个
Sentinel 节点对服务器做出的下线判断,即单个 Sentinel 认为某个服务下线(有可能是接收不到订阅,之间的网络不通等一系列原因)。
主观下线是每个sentinel节点对Redis节点失败的偏见。 所以还需客观下线机制。
多个
Sentinel 实例在对同一服务器做出 SDOWN 判断,并通过命令互相交流后,得出的服务器下线判断,然后开启 failover。
只有在足够数量( 超过quorum
个)的 Sentinel 都将一个服务器标记为主观下线后, 服务器才会被标记为客观下线(ODOWN)。
只有当 M 被认定为客观下线时,才会发生故障迁移。
仲裁指配置文件中的 quorum
参数。某个 Sentinel 先将 Master 节点标记为主观下线,然后会将这个判定通过 sentinel is-master-down-by-addr
命令询问其他 Sentinel 节点是否也同样认为该 addr 的 Master 节点要做主观下线。
sentinel monitor <masterName> <ip> < port> <quorum>
sentinel monitor myMaster 127.0.0.1 6379 2
#
sentinel down-after-milliseconds < masterName> < timeout>
sentinel down-after-milliseconds mymaster 30000
最后当达成这一共识的 Sentinel 个数达到前面说的 quorum 设置的值时,该 Master 节点会被认定为客观下线并进行故障转移。
quorum
值一般设为 Sentinel 个数的二分之一加 1,例如 3 个 Sentinel 就设为 2。
综上可得
down-after-milliseconds
,则该实例会被 Sentinel 标记为 主观下线原因:只有一个sentinel节点完成故障转移。 选举:通过sentinel is-master-down-by-addr命令都希望成为领导者:
主节点
sentinel failover <masterName>
节点下线
节点上线
从节点的作用
由于Redis Sentinel只会对主节点进行故障转移,对从节点采取主观的下线,所以需要自定义一个客户端来监控对应的事件
三个消息
参考