6.redis-Sentinel(主从复制高可用)

1.主从复制的作用：为主提供一个备份，当主挂掉以后，备份中有一个完整的数据，第二个作用是为主实现一个分流，例如实现读写分离
2.主从复制的问题：
(1)手动故障转移
(2)写能力和存储能力受限
3.redis sentinel实现redis的高可用方案：故障发现，故障自动转移，配置中心，客户端通知
4.redis sentinel架构说明
(1)redis sentinel架构流程
<1>redis节点同样是主从复制架构
<2>有很多redis sentinel节点，相当于redis进程，这个进程不会存储数据，作用是对redis的故障判断，故障转移的处理，通知客户端的一个过程
<3>对于客户端来说不会记录redis的地址，直接记录redis sentinel的地址，可以写入多个redis sentinel对master和slave进行监控
图：
(2)redis sentinel故障转移流程：
<1>多个sentinel发现并确认master有问题
<2>选举出一个sentinel作为领导。
<3>选出一个slave作为master
<4>通知其余slave成为新的master的slave.
<5>通知客户端主从变化
<6>等待老的master复活成为新的master的slave.
5.redis sentinel安装配置
(1)配置注意
<1>配置开启主从节点
<2>配置开启sentinel监控主节点。(sentinel是特殊的redis,默认端口26379，sentinel本身不存数据，支持的命令是非常有限的，作用主要完成监控故障转移和通知)
<3>实际应该多机器
<4>详细配置节点
(2)sentinel主要配置
#端口
port ${port}
#工作目录
dir ""
#日志名
logfile "${port}.log"
#监控主节点的名字是mymaster，IP和端口，2是两个sentinel觉得master有问题就会发动故障转移
sentinel monitor mymaster 127.0.0.1 7000 2
#对master进行监控如果30连接不通发动故障转移
sentinel down-after-milliseconds mymaster 30000
#当master宕机后，新的slave成为master后，其他老的slave节点会对新的master节点进行复制，1代表同时只能一个一个复制
sentinel parallel-syncs mymaster 1
#故障转移时间
sentinel failover-timeout mymaster 180000
(3)实现redis一主二从和三个sentinel架构配置
架构图：
图
<1>一主二从查看
master主节点7000端口
./redis-cli -p 7000 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=7001,state=online,offset=71,lag=0
slave1:ip=127.0.0.1,port=7002,state=online,offset=71,lag=0
master_repl_offset:71
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:70
slave第一个从节点7001端口
./redis-cli -p 7001 info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:7000
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:99
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
slave第二个从节点7002端口
./redis-cli -p 7002 info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:7000
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_repl_offset:113
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
<2>三个sentinel配置
sentinel-26379.conf配置：
port 26379
daemonize yes
logfile "26379.log"
dir "/home/redis/data"
sentinel myid acc04aeac2b3975cf9978bfd6a614552457f94f3
sentinel monitor mymaster 127.0.0.1 7000 2
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0

# Generated by CONFIG REWRITE
sentinel known-slave mymaster 127.0.0.1 7001
sentinel known-slave mymaster 127.0.0.1 7002
sentinel known-sentinel mymaster 127.0.0.1 26380 8657c962181bf648e0145949f5988ee4093e47d7
sentinel known-sentinel mymaster 127.0.0.1 26381 ba06e6e9368e8e546e7f890449def52497b6ebea

sentinel-26380.conf配置：
port 26380
daemonize yes
logfile "26380.log"
dir "/home/redis/data"
sentinel myid 8657c962181bf648e0145949f5988ee4093e47d7
sentinel monitor mymaster 127.0.0.1 7000 2
sentinel config-epoch mymaster 0

# Generated by CONFIG REWRITE
sentinel leader-epoch mymaster 0
sentinel known-slave mymaster 127.0.0.1 7002
sentinel known-slave mymaster 127.0.0.1 7001
sentinel known-sentinel mymaster 127.0.0.1 26381 ba06e6e9368e8e546e7f890449def52497b6ebea
sentinel known-sentinel mymaster 127.0.0.1 26379 acc04aeac2b3975cf9978bfd6a614552457f94f3
sentinel current-epoch 0

sentinel-26381.conf配置：
port 26381
daemonize yes
logfile "26381.log"
dir "/home/redis/data"
sentinel myid ba06e6e9368e8e546e7f890449def52497b6ebea
sentinel monitor mymaster 127.0.0.1 7000 2
sentinel config-epoch mymaster 0

# Generated by CONFIG REWRITE
sentinel leader-epoch mymaster 0
sentinel known-slave mymaster 127.0.0.1 7002
sentinel known-slave mymaster 127.0.0.1 7001
sentinel known-sentinel mymaster 127.0.0.1 26380 8657c962181bf648e0145949f5988ee4093e47d7
sentinel known-sentinel mymaster 127.0.0.1 26379 acc04aeac2b3975cf9978bfd6a614552457f94f3
sentinel current-epoch 0

启动三个sentinel：
./redis-sentinel ../data/sentinel-26379.conf
./redis-sentinel ../data/sentinel-26380.conf
./redis-sentinel ../data/sentinel-26381.conf

查看三个sentinel
登录第一个sentinel：./redis-cli -p 26379
127.0.0.1:26379> info
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:7000,slaves=2,sentinels=3

登录第二个sentinel：./redis-cli -p 26380
127.0.0.1:26380> info
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:7000,slaves=2,sentinels=3

登录第三个sentinel：./redis-cli -p 26381
127.0.0.1:26381> info
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:7000,slaves=2,sentinels=3

6.客户端连接
(1)请求响应流程
第一步：客户端获取所有sentinel的节点的集合遍历，获取一个可用的sentinel节点
第二步：在可以PING通的节点上执行sentinel api通过名字获取mastername,返回给客户端master节点的地址和端口
第三步：当客户端获取到master节点的时候执行role或role replication进行验证是否真是master节点

7.redis sentinel通过三个定时任务实现sentinel节点对于主节点，从节点，其余sentinel节点的监控
(1)每10秒每个sentinel对master和slave执行info
发现slave节点
确认主从关系
图

(2)每2秒每个sentinel通过master节点的channel交换信息(pub/sub)
通过__sentinel__:hello频道交互
交互对节点的“看法”和自身信息
图

(3)每1秒每个sentinel对其他sentinel和redis执行ping
心跳检测，失败判定依据
图


8.redis sentinel在对节点做失败判定时分为主观下线和客观下线
(1)主观下线：每个sentinel节点对Redis节点失败的“偏见”
(2)客观下线：所有sentinel节点对Redis节点失"达成共识"(超过quorum)

9.领导者选举
原因：只有一个sentinel节点完成故障转移
选举：通过sentinel is-master-down-by-addr命令都希望成为领导者
(1)每个主观显现的sentinel节点向其他sentinel节点发送命令，要求将它设置为领导者。
(2)收到命令的sentinel节点如果没有同意通过其他sentinel节点发送的命令，那么将同意该请求，否则拒绝
(3)如果该sentinel节点发现自己的票数已经超过sentinel集合半数且超过quorum，那么它将成为领导者。
(4)如果此过程有多个sentinel节点成为领导者，那么将等待一段时间重新进行选举。

10.故障转移(sentinel领导者节点完成)
(1)从slave节点中选出一个“合适的”节点作为新的master节点
<1>选择slave-priority(slave节点优先级)最高的slave节点，如果存在则返回，不存在则继续
<2>选择复制偏移量最大的slave节点(复制的最完整)，如果存在则返回，不存在则继续
<3>选择runId最小的slave节点。
(2)对上面的slave节点执行slaveof no one命令让其成为master节点
(3)向剩余的slave节点发送命令，让它们成为新master节点的slave节点，复制规则和parallel-syncs参数有关
(4)更新对原来master节点配置为slave,并保持着对其“关注”，当其恢复后命令它去复制新的master节点。

11.常见开发运维
(1)节点运维原因：
机器下线：列如过保等情况
机器性能不足：列如CPU，内存，硬盘，网络等
节点自身故障：列如服务不稳定等
(2)节点下线
1)主节点：手动故障转移，给任意一个sentinel执行，忽略主管下线客观下线，领导者选举
命令：sentinel failover<masterName>
2)从节点：临时下线还是永久下线，列如是否做一些清理工作。但是要考虑读写分离的情况
(3)节点上线
1)sentinel主节点上线：
命令：sentinel failover进行替换
2)sentinel从节点上线：slaveof即可，sentinel节点可以感知