浅谈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上。这就是目前最常用的哨兵体系,很智能化~