一年又一年，字节跳动 Lark（飞书） 研发团队又双叒叕开始招新生啦！
【内推码】：GTPUVBA
【内推链接】：https://job.toutiao.com/s/JRupWVj
【招生对象】：20年9月后~21年8月前 毕业的同学
【报名时间】：6.16-7.16（提前批简历投递只有一个月抓住机会哦！）
【画重点】：提前批和正式秋招不矛盾！面试成功，提前锁定Offer；若有失利，额外获得一次面试机会，正式秋招开启后还可再次投递。
章节目录
Redis详解1.安装及使用
Redis详解2.数据结构
Redis详解3.发布订阅
Redis详解4.事务
Redis详解5.数据持久化
Redis详解6.主从模式
Redis详解7.哨兵模式
Redis详解8.Cluster模式
1 简介
参考资料来源
Redis进阶实践之十 Redis哨兵集群模式
Redis Sentinel机制与用法（一）
Redis Sentinel机制与用法（二）
哨兵模式
上一章讲解了Redis主从模式的实现，主从模式的配置简单，Master节点不需要修改，只需要修改Slave节点即可。在主从模式下如果Master宕机，需要手动重启Master节点或者手动切换主节点来完成系统恢复，这在生产环境中是有问题的。Redis在2.6版本开始提供的了哨兵模式，到Redis的2.8版本以后该模式正式稳定。Sentinel（哨兵）进程监控Redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用。
哨兵
- 哨兵（Sentinel）是一个分布式系统，你可以在一个架构中运行多个哨兵进程，这些进程使用流言协议（Gossip Protocols）来接收关于Master主服务器是否下线的信息，并使用投票协议（Agreement Protocols）来决定是否执行自动故障迁移，以及选择哪个Slave作为新的Master。
- 主观宕机：每个哨兵（Sentinel）进程会向其它哨兵、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定配置时间内未得到回应，则暂时认为对方已掉线，也就是所谓的主观宕机（Subjective Down，SDOWN）。
- 客观宕机：当“哨兵群”中的多数Sentinel进程在对Master主服务器做出SDOWN的判断，并且通过SENTINEL is-master-down-by-addr命令互相交流之后，得出的Master Server下线判断，这种方式就是客观宕机（Objectively Down， 简称 ODOWN）。
- 投票：当客观宕机后，哨兵可以通过一定的Vote算法，从剩下的Slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改相关配置，并开启故障转移（failover）。
哨兵进程的作用：
- 监控：哨兵会不断地检查你的Master和Slave是否运作正常。
- 提醒：当被监控的某个Redis节点出现问题时，哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
- 自动故障迁移：当一个Master不能正常工作时，哨兵会开始一次自动故障迁移操作，它会将失效Master的其中一个Slave升级为新的Master，并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。
Sentinel进程的工作方式
- 每个Sentinel进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel进程发送一个 PING 命令。
- 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被Sentinel进程标记为SDOWN。
- 如果一个Master主服务器被标记为SDOWN，则正在监视这个Master主服务器的所有 Sentinel进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态。
- 当有足够数量的Sentinel进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了SDOWN， 则Master主服务器会被标记为客观下线ODOWN。
- 在一般情况下， 每个Sentinel进程会以每10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送INFO命令。
- 当Master主服务器被Sentinel进程标记为ODOWN时，Sentinel进程向下线的Master主服务器的所有Slave从服务器发送INFO命令的频率会从 10 秒一次改为每秒一次。
- 若没有足够数量的Sentinel进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若Master主服务器重新向Sentinel进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。
2 配置
Redis-Server配置
Redis-Server的配置和主从模式配置是一致的，此处不再介绍。
Redis-Sentinel配置
# sentinel的固定配置格式sentinel <option_name> <master_name> <option_value>
# 配置sentinel监控的master
# sentinel监控的master的名字叫做mymaster，地址为127.0.0.1:6380
# sentinel在集群式时，需要多个sentinel互相沟通来确认某个master是否真的死了；
# 数字1代表，当集群中有1个sentinel认为master死了时，才能真正认为该master已经不可用了。
sentinel monitor mymaster 127.0.0.1 6380 1
# sentinel会向master发送心跳PING来确认master是否存活
# 如果master在“一定时间范围”内不回应PONG或者是回复了一个错误消息
# 那么这个sentinel会主观地认为这个master已经不可用了（SDOWN）
# 而这个down-after-milliseconds就是用来指定这个“一定时间范围”的，单位是毫秒。
sentinel down-after-milliseconds mymaster 5000
# 在发生failover主备切换时，这个选项指定了最多可以有多少个slave同时对新的master进行同步
# 这个数字越小，完成failover所需的时间就越长
# 但是如果这个数字越大，就意味着越多的slave因为replication而不可用。
# 可以通过将这个值设为 1 来保证每次只有一个slave处于不能处理命令请求的状态。
sentinel parallel-syncs mymaster 1
# 实现主从切换，完成故障转移的所需要的最大时间值。
# 若Sentinel进程在该配置值内未能完成故障转移的操作，则认为本次故障转移操作失败。
sentinel failover-timeout mymaster 60000
# 指定Sentinel进程检测到Master-Name所指定的“Master主服务器”的实例异常的时候，所要调用的报警脚本。
sentinel notification-script mymaster <script-path>
启动Sentinel
方式1：redis-sentinel redis-sentinel.conf
方式2：redis-server sentinel.conf --sentinel
3 测试主从切换
启动Sentinel
36849:X 14 Feb 2019 12:56:29.190 # Sentinel ID is 72e957adcddf731147b659392ef51c25549c71bc
36849:X 14 Feb 2019 12:56:29.190 # +monitor master mymaster 127.0.0.1 6380 quorum 1
36849:X 14 Feb 2019 12:56:29.191 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 12:56:29.192 * +slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6380
查看Redis集群信息
127.0.0.1:6380> INFO Replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=3033,lag=0
slave1:ip=127.0.0.1,port=6382,state=online,offset=3033,lag=1
查看进程信息
# ps -l | grep "redis"
501 36818 34208 4006 0 31 0 4374192 2572 - S+ 0 ttys000 0:00.12 redis-server 127.0.0.1:6380
501 36819 34237 4006 0 31 0 4384432 2596 - S+ 0 ttys001 0:00.11 redis-server 127.0.0.1:6381
501 36822 34274 4006 0 31 0 4383408 2552 - S+ 0 ttys002 0:00.11 redis-server 127.0.0.1:6382
501 36849 34951 4006 0 31 0 4333232 2540 - S+ 0 ttys003 0:00.15 redis-sentinel *:26379 [sentinel]
kill掉Master节点
kill 36818
Sentinel日志
# sdown掉原Master节点
36849:X 14 Feb 2019 13:00:11.190 # +sdown master mymaster 127.0.0.1 6380
# odown掉原Master节点
36849:X 14 Feb 2019 13:00:11.190 # +odown master mymaster 127.0.0.1 6380 #quorum 1/1
36849:X 14 Feb 2019 13:00:11.190 # +new-epoch 1
36849:X 14 Feb 2019 13:00:11.190 # +try-failover master mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:11.191 # +vote-for-leader 72e957adcddf731147b659392ef51c25549c71bc 1
36849:X 14 Feb 2019 13:00:11.191 # +elected-leader master mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:11.191 # +failover-state-select-slave master mymaster 127.0.0.1 6380
# 6381选举为主节点
36849:X 14 Feb 2019 13:00:11.245 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:11.245 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:11.337 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:11.943 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:11.943 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:12.006 * +slave-reconf-sent slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:12.994 * +slave-reconf-inprog slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:12.994 * +slave-reconf-done slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6380
36849:X 14 Feb 2019 13:00:13.050 # +failover-end master mymaster 127.0.0.1 6380
# 切换6381为新的主节点
36849:X 14 Feb 2019 13:00:13.050 # +switch-master mymaster 127.0.0.1 6380 127.0.0.1 6381
# 6382作为6381的Slave节点
36849:X 14 Feb 2019 13:00:13.050 * +slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6381
36849:X 14 Feb 2019 13:00:13.050 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
36849:X 14 Feb 2019 13:00:43.064 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
新的主节点
# 6381日志
Setting secondary replication ID to 2cc46e6225022394b9277c3c1031299ffa61301c, valid up to offset: 12806. New replication ID is e76568505649a7bdf3f8aaadb2c3bb853d288395
36819:M 14 Feb 2019 13:00:11.337 * Discarding previously cached master state.
36819:M 14 Feb 2019 13:00:11.337 * MASTER MODE enabled (user request from 'id=4 addr=127.0.0.1:50356 fd=8 name=sentinel-72e957ad-cmd age=222 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=140 qbuf-free=32628 obl=36 oll=0 omem=0 events=r cmd=exec')
36819:M 14 Feb 2019 13:00:11.339 # CONFIG REWRITE executed with success.
36819:M 14 Feb 2019 13:00:12.607 * Replica 127.0.0.1:6382 asks for synchronization
36819:M 14 Feb 2019 13:00:12.607 * Partial resynchronization request from 127.0.0.1:6382 accepted. Sending 289 bytes of backlog starting from offset 12806.
查看主节点
# 6381变成主节点
127.0.0.1:6381> INFO Replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6382,state=online,offset=24504,lag=0
配置文件的变化
# 6381变成主节点
# redis移除了配置文件redis_slave1.conf中slaveof这行配置
slaveof 127.0.0.1 6380
# 6382变成6381的从节点
# redis移除配置文件redis_slave2.conf中原来的slaveof配置，增加下面这行配置
replicaof 127.0.0.1 6381
4 哨兵模式的优缺点
优点
- 哨兵集群模式是基于主从模式的，所有主从的优点，哨兵模式同样具有。
- 主从可以切换，故障可以转移，系统可用性更好。
- 哨兵模式是主从模式的升级，系统更健壮，可用性更高。
缺点
- Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。
- 实现哨兵模式的配置也不简单，甚至可以说有些繁琐
