【Redis高手修炼之路】④主从复制

主从复制

就是 redis集群的策略
配从（库）不配主（库）：小弟可以选择谁是大哥，但大哥没有权利去选择
小弟读写分离：主机写，从机读

一主二仆

准备三台服务器，并修改redis.conf

bind 0.0.0.0

启动三台redis，并查看每台机器的角色，都是master

[root@VM-4-2-centos bin]# redis-server /opt/redis-5.0.4/redis.conf 
[root@VM-4-2-centos bin]# redis-cli

127.0.0.1:6379> info replication   # 查看角色

在这里插入图片描述

开始测试，将三个机器全都清空，并给第一台添加值

127.0.0.1:6379> set name tom
OK

其余两台机器，复制（找大哥）

127.0.0.1:6379> slaveof 110.42.142.191 6379

第一台再添加值

127.0.0.1:6379> set age 20
OK

思考1： slave之前的name是否能拿到？
可以获得，只要跟了大哥，之前的数据也会立刻同步
思考2： slave之后的age是否能拿到？
可以获得，只要跟了大哥，数据会立刻同步
思考3： 同时添加gender，结果如何？
主机（master）可以添加成功，从机（slave）失败，从机只负责读取数据，无权写入数据，这就是“读写分离”
思考4： 主机shutdown，从机如何？
从机仍然是slave，查看他们的角色信息显示他们的master已离线
思考5： 主机重启，从机又如何？
从机仍然是slave，并显示他们的master已上线
思考6： 从机死了，主机如何？从机归来身份是否变化？
主机没有变化，只是显示少了一个slave
主机和从机没有变化，而重启归来的从机自立门户成为了master，不和原来的集群在一起了

血脉相传

一个主机理论上可以多个从机，但是这样的话，这个主机会很累；我们可以使用java面向对象继承中的传递性来解决这个问题，减轻主机的负担，形成祖孙三代。

127.0.0.1:6379> slaveof 110.42.142.191 6379     # 200从机跟随191

127.0.0.1:6379> slaveof 192.168.52.200 6379 	# 另一个从机跟随200

谋权篡位

1个主机，2个从机，当1个主机挂掉了，只能从2个从机中再次选1个主机

手动选老大
模拟测试：1为master，2和3为slave，当1挂掉后，2篡权为master，3跟2

思考： 当1再次回归，会怎样？
2和3已经形成新的集群，和1没有任何的关系了。所以1成为了光杆司令

复制原理

完成上面几个步骤后就完成了从服务器数据初始化的所有操作，从服务器此时可以接收来自用户的读请求

全量复制：Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份slave接收到数据文件后，存盘，并加载到内存中；（步骤1234）
增量复制：Slave初始化后，开始正常工作时主服务器发生的写操作同步到从服务器的过程；（步骤56）
但，只要是重新连接master，一次性（全量复制）同步将自动执行；
Redis主从同步策略：主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。
redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

哨兵模式

自动版的谋权篡位！
有个哨兵一直在巡逻，突然发现！！！！！老大挂了，小弟们会自动投票，从众小弟中选出新的老大
Sentinel是Redis的高可用性解决方案：
由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求
模拟测试

1主，2和3从
每一台服务器中创建一个配置文件sentinel.conf，名字绝不能错，并编辑sentinel.conf
启动服务的顺序：主Redis --> 从Redis --> Sentinel1/2/3
将1号老大挂掉，后台自动发起激烈的投票，选出新的老大
查看最后权利的分配
3成为了新的老大，2还是小弟
如果之前的老大再次归来呢？
1号再次归来，自己成为了master，和3平起平坐
过了几秒之后，被哨兵检测到了1号机的归来，1号你别自己玩了，进入集体吧，但是新的老大已经产生了，你只能作为小弟再次进入集体！