浅谈Redis主从复制，读写分离（二）
一.前期回顾
上一期我们对主从复制有了大致的了解
https://blog.csdn.net/weixin_43262188/article/details/90478080
大概如图，一个主库可以连接多个从库，但这样中心化较严重。
二。“薪火相传”
本期我们仍然用6379,6380,6381这三个终端来演示（如果不了解请看上一篇）。
现在我们让6381 slaveof 6380，即认6381认6380为主库。这样一来就是 6379—>6380---->6381这样一种连接模式.
在6379库set一个字符串，6381也一样能通过同步6380来获得这个值。6380不用说当然也会存在k6.
三.反客为主
为了方便演示，我们将6381重新从属于6379.
反客为主字面意思很好理解，就是脱离被奴役的关系，自己成为主人。
首先我让6379先退出了，并在6381执行 Slaveof no one，再次查看 info replication发现 6381变成Master, 6380仍然是在等待6379重新上线。
让6380执行 slaveof 6381 ，这样就形成了反客为主。
四.哨兵模式(目前最流行的)
在说哨兵模式之前我们先来回顾一下复制的原理：
总的来说就是，第一次会全复制一遍，后续的都是增量复制。（重连也会全部复制）
为了方便演示，我们继续实行一主二仆的模式，以6379为主。
顾名思义，哨兵模式类似于监控的意思。实际上就是反客为主的自动版，假设现在6379终端死掉了，用反客为主的方法需要我们人为的将6380 或者6381 设置成主库。但这样有个缺点就是，如果白天大家都上班出现这种问题还好，要是半夜凌晨三点 主库突然死掉了，其他从库只能等待。而“哨兵模式”采用一种类似投票的模式，会自动在这些从库之中决出一个主库担当Master。
具体操作：
在安装目录下新建一个文件 名字为 ：sentinel.conf （名字尽量和我的一致，避免不必要的错误）
sentinel monitor [主机名（自己起）][IP地址] [端口号] [票数]
通过该命令启动sentinel.conf文件.
可以看到哨兵正在对6380,6381巡逻。现在我们让6379这台主机挂掉。
过了10秒钟再看哨兵的控制台，很明显 6381已经成为了Master!!!，6380已经认6381为主了
思考：此时我再让6379重新上线会发生什么呢？？
很明显，6379修复好再次上线后被哨兵发现了，于是他也需要将6381认作主库！（老领导过气了23333…）最后 6380 和 6379 都挂在了 6381上。这就是目前最常用的哨兵体系，很智能化~