Redis笔记-主从复制与哨兵机制

Redis主从复制

方式一: 新增 redis6380.conf, 加入 slaveof 172.17.0.2 6379, 在 6379 启动完后再启 6380，完成配置；
方式二: redis-server --slaveof 172.17.0.2 6379
查看状态：info replication
断开主从复制：在 slave 节点，执行 : slaveof no one
断开后再变成主从复制：6380:> slaveof 172.17.0.2
数据较重要的节点，主从复制时使用密码验证： requirepass
从节点建议用只读模式 slave-read-only=yes, 若从节点修改数据，主从数据不一致
传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis 提供repl-disable-tcp-nodelay 参数决定是否关闭 TCP_NODELAY,默认为关闭
参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景.
参数启用时：主节点合并所有数据成 TCP 包节省带宽，默认为 40 毫秒发一次.取决于内核，主从的同步延迟 40 毫秒，适用于网络环境复杂或带宽紧张，如跨机房

复制原理

数据同步：
redis 2.8 版本以上使用 psync 命令完成同步，过程分“全量”与“部分”复制
全量复制：一般用于初次复制场景（第一次建立 SLAVE 后全量）
部分复制：网络出现问题，从节占再次连主时，主节点补发缺少的数据，每次数据增加同步
心跳：主从有长连接心跳，主节点默认每 10S 向从节点发 ping 命令，repl-ping-slave-period 控制发送频率

哨兵机制

我们学习了 redis 的主从复制，但如果说主节点出现问题不能提供服务，需要人工重新把从节点设为主节点，还要通知我们的应用程序更新了主节点的地址，这种处理方式不是科学的，耗时费事。同时主节点的写能力是单机的，能力能限。而且主节点是单机的，存储能力也有限。

主从故障如何故障转移(不满足高可用)：

1. 主节点(master)故障，从节点 slave-1 端执行 slaveof no one 后变成新主节点
2. 其它的节点成为新主节点的从节点，并从新节点复制数据

哨兵机制(sentinel)的高可用：
原理：当主节点出现故障时，由 redis sentinel 自动完成故障发现和转移，并通知应用方，实现高可用性。

其实整个过程只需要一个哨兵节点来完成，首先使用 Raft 算法（感兴趣的同学可以查一下，其实就是个选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知，哨兵有三个定时监控任务完成对各节点的发现和监控：

任务1: 每个哨兵节点每 10 秒会向主节点和从节点发送 info 命令获取最新拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送 info，获取从节点的信息，并当有新的从节点加入时可以马上感知到

任务2: 每个哨兵节点每隔 2 秒会向 redis 数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息 publish 和 subscribe 来完成的；

任务 3:每隔 1 秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次 ping 命令做一次 心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

主观下线和客观下线
主观下线:刚我知道知道哨兵节点每隔 1 秒对主节点和从节点、其它哨兵节点发送 ping做心跳检测，当这些心跳检测时间超过 down-after-milliseconds 时，哨兵节点则认为该节点 错误或下线，这叫主观下线;这可能会存在错误的判断。

客观下线:当主观下线的节点是主节点时，此时该哨兵 3 节点会通过指令 sentinel is-masterdown-by-addr 寻求其它哨兵节点对主节点的判断，当超过 quorum(法定人数)个 数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意 下线操作，也就说是客观下线

领导者哨兵选举流程
每个在线的哨兵节点都可以成为领导者，当它确认(比如哨兵 3)主节点下线时，会向其它哨兵发 is-master-down-by-addr 命令，征求判断并要求将自己设置为领导者，由领导 者处理故障转移;

当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者;

如果哨兵 3 发现自己在选举的票数大于等于 num(sentinels)/2+1 时，将成为领导者， 如果没有超过，继续选举…

故障转移机制
由 Sentinel 节点定期监控发现主节点是否出现了故障sentinel 会向 master 发送心跳 PING 来确认 master 是否存活，如果 master 在“一定 时间范围”内不回应 PONG 或者是回复了一个错误消息，那么这个 sentinel 会主观地(单 方面地)认为这个master 已经不可用了

当主节点出现故障，此时 3 个 Sentinel 节点共同选举了 Sentinel3 节点为领导， 负载处理主节点的故障转移

由 Sentinel3 领导者节点执行故障转移，过程和主从复制一样，但是自动执行

将 slave-1 脱离原从节点，升级主节点
将从节点 slave-2 指向新的主节点 
通知客户端主节点已更换 
将原主节点(oldMaster)变成从节点，指向新的主节点

哨兵机制-故障转移详细流程
过滤掉不健康的(下线或断线)，没有回复过哨兵 ping 响应的从节点
选择 slave-priority 从节点优先级最高(redis.conf)
选择复制偏移量最大，指复制最完整的从节点

如何安装和部署 Reids Sentinel?

先搭好一主两从 redis 的主从复制，和之前复制搭建一样，搭建方式如下：
主节点 6379 节点(redis6379.conf):
修改 requirepass 12345678，注释掉#bind 127.0.0.1

从节点 redis6380.conf 和 redis6381.conf:
修改port 6380 port 6381
修改 requirepass 12345678
注释掉#bind 127.0.0.1, 加上 masterauth 12345678
加上 slaveof 127.0.0.1 6379

**注意:**当主从起来后，主节点可读写，从节点只可读不可写

redis sentinel 哨兵机制核心配置(也是 3 个节点):
sentinel_26379.conf, sentinel_26380.conf, sentinel_26381.conf

将三个文件的端口改成: 26379 26380 26381
然后:sentinel monitor mymaster 10.60.83.4 6379 2 //监听主节点 6379
sentinel auth-pass mymaster 12345678 //连接主节点时的密码 三个配置除端口外，其它一样。

**哨兵其它的配置:**只要修改每个 sentinel.conf 的这段配置即可:
sentinel monitor mymaster 10.60.83.4 6379 2
监控主节点的 IP 地址端口，sentinel 监控的 master 的名字叫做 mymaster
2 代表，当集群中有 2 个 sentinel 认为 master 死了时，才能真正认为该 master
已经不可用了

sentinel auth-pass mymaster 12345678
sentinel 连主节点的密码

sentinel config-epoch mymaster 2
故障转移时最多可以有 2 从节点同时对新 主节点进行数据同步

sentinel leader-epoch mymaster 2
sentinel failover-timeout mymasterA 180000
故障转移超时时间 180s，
a,如果转移超时失败，下次转移时时间为之前的 2 倍;
b,从节点变主节点时，从节点执行 slaveof no one 命令一直失败的话， 当时间超过 180S 时，则故障转移失败
c,从节点复制新主节点时间超过 180S 转移失败

sentinel down-after-milliseconds mymasterA 300000
sentinel节点定期向主节点ping 命令，当超过了 300S 时间后没有回复，可能就认定为此主节点出现故障了…

sentinel parallel-syncs mymasterA 1
故障转移后，1 代表每个从节点按顺序排队一个一个复 制主节点数据，如果为 3，指 3 个从节点同时并发复制主节点数据，不会影响阻塞，但存在 网络和 IO 开销

启动 sentinel 服务:

./redis-sentinel ../sentinel_26379.conf &
./redis-sentinel ../sentinel_26380.conf &
./redis-sentinel ../sentinel_26381.conf &

关闭:./redis-cli -h localhost -p 26379 shutdown

测试：
kill掉6379服务，看日志是分配 6380 还是 6381 做为主节点，当 6379 服务再启动时，已变成从节点
使用info replication 查看

重启6379服务，可以看到6379变成master

重要:sentinel monitor mymaster 10.60.83.4 6379 2 //切记将 IP 不要写成 127.0.0.1
不然使用 JedisSentinelPool 取 jedis 连接的时候会变成取 127.0.0.1 6379 的错误地址

sentinel 哨兵的 API
命令:redis-cli -p 26379 //进入哨兵的命令模式，使用 redis-cli 进入
26379>sentinel masters 或 sentinel master mymaster //查看 redis 主节点相关信息
26379>sentinel slaves mymaster //查看从节点状态与相关信息
26379>sentinel sentinels mymaster //查 sentinel 节点集合信息(不包括当前 26379)
26379>sentinel failover mymaster //对主节点强制故障转移，没和其它节点协商

程序连接sentinel

    Set<String> sentinels = new HashSet<String>();
    sentinels.add("127.0.0.1:26379");
    sentinels.add("127.0.0.1:26380");
    sentinels.add("127.0.0.1:26381");

    String clusterName = "mymaster" ;

    JedisSentinelPool jsentinelPool = new JedisSentinelPool(clusterName,sentinels,"12345678");
    Jedis jedis = jsentinelPool.getResource();
    jedis.set("key", "aaa");