[Redis][哨兵][下]具体讲解
1.安装部署(基于Docker)1.编排Redis主从节点
[*]编写docker-compose.yml
[*]创建/root/redis/docker-compose.yml，同时cd到yml所在⽬录中
[*]分析：docker中可以通过容器名字作为ip地址，进⾏相互之间的访问
version: '3.7'
services:
master:
image: 'redis:5.0.9'
container_name: redis-master
restart: always
command: redis-server --appendonly yes
ports:
- 6379:6379
slave1:
image: 'redis:5.0.9'
container_name: redis-slave1
restart: always
command: redis-server --appendonly yes --slaveof redis-master 6379
ports:
- 6380:6379
slave2:
image: 'redis:5.0.9'
container_name: redis-slave2
restart: always
command: redis-server --appendonly yes --slaveof redis-master 6379
ports:
- 6381:6379
[*]启动所有容器：docker-compose up -d
[*]查看运行日志：docker-compose logs
2.编排Redis-Sentinel节点
[*]分析：可以把redis-sentinel放到和上⾯的Redis的同⼀个yml中进⾏容器编排，但此处分成两组，主要是为了两⽅⾯：
[*]观察⽇志⽅便
[*]确保Redis主从节点启动之后才启动redis-sentinel
[*]假如先启动redis-sentinel的话，可能触发额外的推举过程，混淆视听
[*]不是说先启动哨兵不⾏，⽽是观察的效果可能存在⼀定随机性
[*]编写docker-compose.yml
[*]创建/root/redis-sentinel/docker-compose.yml ,同时cd到yml所在⽬录中
version: '3.7'
services:
sentinel1:
image: 'redis:5.0.9'
container_name: redis-sentinel-1
restart: always
command: redis-sentinel /etc/redis/sentinel.conf
volumes:
- ./sentinel1.conf:/etc/redis/sentinel.conf
ports:
- 26379:26379
sentinel2:
image: 'redis:5.0.9'
container_name: redis-sentinel-2
restart: always
command: redis-sentinel /etc/redis/sentinel.conf
volumes:
- ./sentinel2.conf:/etc/redis/sentinel.conf
ports:
- 26380:26379
sentinel3:
image: 'redis:5.0.9'
container_name: redis-sentinel-3
restart: always
command: redis-sentinel /etc/redis/sentinel.conf
volumes:
- ./sentinel3.conf:/etc/redis/sentinel.conf
ports:
- 26381:26379
networks:
default:
external:
name: redis-data_default
[*]创建配置文件：创建sentinel1.conf、sentinel2.conf、sentinel3.conf，三分文件的内容是完全类似的，都放在/root/redis-sentinel/⽬录中bind 0.0.0.0
port 26379
sentinel monitor redis-master redis-master 6379 2
sentinel down-after-milliseconds redis-master 1000
[*]理解sentinel monitor：
[*]主节点名：这个是哨兵内部⾃⼰起的名字
[*]主节点ip：部署redis-master的设备ip
[*]此处由于是使⽤docker，可以直接写docker的容器名，会被⾃动DNS成对应的容器ip
[*]法定票数：哨兵需要判定主节点是否挂了，但是有的时候可能由于特殊情况
[*]⽐如主节点仍然⼯作正常，但是哨兵节点⾃⼰⽹络出问题了，⽆法访问到主节点了
[*]此时就可能会使该哨兵节点以为主节点下线，出现误判
[*]使⽤投票的⽅式来确定主节点是否真的挂了是更稳妥的做法
[*]需要多个哨兵都以为主节点挂了，票数 >= 法定票数之后，才会真的以为主节点是挂了
sentinel monitor 主节点名 主节点 ip 主节点端⼝ 法定票数
[*]理解sentinel down-after-milliseconds：
[*]主节点和哨兵之间通过⼼跳包来进⾏沟通
[*]假如⼼跳包在指定的时间内还没回来，就视为是节点出现故障
[*]既然内容类似，为啥要创建多份配置⽂件?
[*]redis-sentinel在运⾏中可能会对配置进⾏rewrite，修改⽂件内容
[*]假如⽤⼀份⽂件，就可能出现修改混乱的情况
[*]启动所有容器：docker-compose up -d
[*]查看运行日志：docker-compose logs
2.重新推举
1.redis-master宕机之后
[*] 哨兵发现了主节点sdown，进⼀步的由于主节点宕机得票到达 2 / 3 2/3 2/3，到达法定得票，于是master被判定为odown
[*]主观下线(Subjectively Down，SDown)：哨兵感知到主节点没⼼跳了，判定为主观下线
[*]客观下线(Objectively Down，ODown)：多个哨兵告竣⼀致意⻅，才能以为master确实下线了
https://i-blog.csdnimg.cn/direct/9b21ef23d0ed46a9b22a4bab6868c76c.png
[*] 接下来，哨兵们挑选出了⼀个新的master，上图中，是172.22.04:6379这个节点
https://i-blog.csdnimg.cn/direct/3402d80957a34d2c97303bd6cd1e8072.png
[*] 此时，对于Redis来说仍然是可以继续利用的
2.redis-master重启之后
[*]哨兵日志：刚才新启动的redis-master被当成了slave
https://i-blog.csdnimg.cn/direct/6e79cff9f6cf443aba3f44a8e44e41b7.png
3.总结
[*]Redis主节点假如宕机，哨兵会把其中的⼀个从节点，提拔成主节点
[*]当之前的Redis主节点重启之后，这个主节点被加⼊到哨兵的监控中，但是只会被作为从节点使⽤
3.推举原理
[*]假定生产环境如下
https://i-blog.csdnimg.cn/direct/2d406f662b6c448e8ab37cd9c233808e.png
[*]主观下线：
[*]当redis-master宕机，此时redis-master和三个哨兵之间的⼼跳包就没有了
[*]此时，站在三个哨兵的⻆度来看，redis-master出现严峻故障，因此三个哨兵均会把redis-master判定为主观下线(SDown)
[*]客观下线：
[*]此时，哨兵sentenal1, sentenal2, sentenal3均会对主节点故障这件事变进⾏投票
[*]当故障得票数 >= 配置的法定票数之后，意味着redid-master故障这个事变被坐实，此时触发客观下线(ODown)sentinel monitor redis-master 172.22.0.4 6379 2
[*]推举出哨兵的leader
[*]接下来需要哨兵把剩余的slave中挑选出⼀个新的master，这个⼯作不需要所有的哨兵都参与，只需要选出个代表(称为leader)，由leader负责进⾏slave升级到master的提拔过程
[*]这个推举过程涉及到Raft算法，假定一共三个哨兵节点S1，S2，S3
[*]每个哨兵节点都给其他所有哨兵节点，发起⼀个"拉票请求"
[*]S1 -> S2, S1 -> S3, S2 -> S1, S2 -> S3，S3 -> S1, S3 -> S2
[*]收到拉票请求的节点，会回复⼀个 “投票响应”，响应的效果有两种可能, 投or不投
[*]例如：S1给S2发了个投票请求，S2就会给S1返回投票相应
[*]S2是否要投S1，取决于S2是否给别人投过票了(每个哨兵只有一票)
[*]假如没投过(S1是第一个向S2拉票的)，S2就会投给S1，否则则不投
[*]一轮投票完成之后，发现得票超过半数的节点，主动成为leader
[*]假如出现平票，则重新再投一次即可
[*]这也是为啥发起哨兵节点设置成奇数个的原因，假如为偶数个，则增大了平票的概率，带来了不须要的开销
[*]leader节点负责挑选⼀个slave成为新的master，当其他的sentenal发现新的master出现了，就分析推举结束了
[*]综上，Raft算法的核心就是”先下手为强”，谁率先发出了拉票请求，谁就有更大的概率成为leader
[*]决定因素：网络延时，其本身就带有一定的随机性
[*]具体选出的哪个节点是leader不重要，重要的是能选出一个节点
[*]leader挑选出合适的slave成为新的master
[*]挑选规则：
[*]比力优先级，优先级高(数值小的)的上位
[*]优先级是配置文件中的配置项slave-priority或者replica-priority
[*]比力replication offset，谁复制的数据多，高的上位
[*]**比力run id**，谁的id`小，谁上位
[*]即：大小全凭缘分，选谁都可以，随便挑一个
[*]当某个slave节点被指定为master之后
[*]leader指定该节点执行slave no one，成为master`
[*]leader指定剩余的slave节点，都依附于这个新master
4.总结
[*]上述过程，都是"⽆⼈值守"，Redis ⾃动完成的，这样做就解决了主节点宕机之后需要⼈⼯⼲预的问题，提⾼了体系的稳定性和可⽤性
[*]留意事项：
[*]哨兵节点不能只有一个，否则哨兵节点挂了也会影响体系可用性
[*]分布式体系中，应该制止利用“单点”，应该有冗余
[*]哨兵节点最好是奇数个，方便推举leader，得票更轻易超过半数
[*]大部分情况下，3个就充足了
[*]哨兵节点不负责存储数据，仍然是Redis主从节点负责存储
[*]哨兵节点可以利用一些配置不高的机器来部署
[*]哨兵 + 主从复制解决的问题是”提高可用性”，不能解决”数据极端情况下写丢失”的问题
[*]哨兵 + 主从复制不能提高数据的存储容量，当需要存的数据靠近或者超过机器的物理内存，这样的结构就不能胜任了
[*]为了能存储更多的数据，就引入了集群
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]