Redis的主从复制
概述
与mysql的主从复制思想类似，主服务器数据更新后根据配置和策略自动同步到从服务器上。Master以写为主，Slave以读为主。
主从复制可以实现数据的读写分离以及数据的容灾恢复(若master节点崩溃，可根据slave节点的rdb文件恢复数据)
原理
slave启动成功后连接到master后会发送一个sync命令，master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，master将传送整个文件到slave，以完成一次完全同步。
而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中(这是一次全量复制)。master继续将新的所有收集到的修改目录依次传给slave，完成同步(增量复制)。
只要是重新连接master，首先会自动执行一次全量复制
使用
原则：配从(库)不配主(库)
配置方式：
- 在从服务器上输入命令 slaveof 主库ip 主库端口。但是每次与master端开连接之后，都需要重新连接。
- 直接配置到redis.conf中。比如我使用的redis版本中，配置文件中不存在slaveof，取而代之的是replicaof。配置方式一样：replicaof <masterip> <masterport>
info replication查看主从复制信息，默认每个redis节点都是一个master节点
127.0.0.1:6379> INFO REPLICATION
# Replication
role:master
connected_slaves:0
master_replid:cde1187a5488fe33a59dced3537a8d2c44c1e6d1
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
演示1主2从的主从复制的配置操作
主 redis配置名称 redis6379.conf，端口6379，pid文件名称 /var/run/redis_6379.pid，log名称 redis6379.log,rdb文件名称 dump6379.rdb
1从 redis配置名称 redis6380conf，端口6380，pid文件名称 /var/run/redis_6380.pid，log名称 redis6380.log,rdb文件名称 dump6380.rdb
另一从 redis配置名称 redis6381.conf，端口6381，pid文件名称 /var/run/redis_6381.pid，log名称 redis6381.log,rdb文件名称 dump6381.rdb
配置完毕后，分别启动这三个服务，如
可以看到初始情况下，各个节点默认都是master节点。
下面将6380端口服务、6381端口服务设置为6379端口服务的从节点。
6380服务：
slaveof 127.0.0.1 6379
6381服务:
REPLICAOF 127.0.0.1 6379
命令执行均ok，但是通过info replication查看主从信息时 发现master节点中**connected_slaves:0,而slave节点中master_link_status:down。**这意味着主从配置似乎没成功，查看slave6380的日志，发现端倪：
报错信息NOAUTH Authentication required似乎与密码认证有关。突然想到我们的master节点设置了登录密码。通过排查，只需要在slave节点的配置文件中添加配置：masterauth 123456(我的master登录密码是123456)。
随后重启从节点，重新执行slaveof命令，运行成功：
因此，如果master不设置密码，那么直接在slave服务器配置slaveof/replicaof即可;master设置密码的情况下同步数据,我们只要让slave能连上master就可以了,即我们在slave的配置文件中加上"masterauth 密码"即可。
演示主从复制的基本使用
现在我们模拟的三台服务已具备主从关系
正常使用
主节点写入两个key，从节点立刻可以读到数据
疑问
-
切入点问题。从节点6380、6381是从master的头开始复制数据还是只复制这两个节点成为为从节点时刻后之后的数据呢？
针对这个问题，这里6379节点先设置三个字符串值，分别是k1-v1,k2-v2,k3-v3。然后6380节点和6381节点才成为6379节点的从节点。然后立刻在从节点中获取k1/k2/k3的值，如果获取到旧说明是从头开始复制的
结论：从头开始复制
2.主节点可读可写，那么从节点是否可以写呢？
## 在从节点上执行写操作 报错
127.0.0.1:6380> set k4 v4
(error) READONLY You can't write against a read only replica.
通过报错信息可知，从节点只读。
3.主节点宕机了，从节点是什么都不做，还是会从众多从节点中重新选出一个主节点呢？
这里使用shutdown来模拟，主节点宕机
可以发现，从节点什么都没做，主节点还是指向127.0.0.1:6379。由于master宕机了，从节点只是显示与主节点未连接master_link_status:down
结论：从节点什么都不做
4.原主节点重新启动后，在主节点上新增记录，从节点还能成功同步吗？
重新启动原6379主节点
当主节点启动成功后，新增一条记录，该记录迅速地在从节点被获取到。
这个时候，通过info replication 查看从节点master_link_status:up,也从侧面印证成功连上主节点
结论:还能成功同步
5.一台从节点宕机了之后情况如何？
模拟从节点6380宕机，将其shutdown
6380节点机器重启后，通过info replication查看此时它为master节点，应该是还没与其他节点建立主从关系
重新让6380节点成为6379节点的从节点，发现以前在master上的数据，一个不落的全同步到当前节点了。
注意：为了排除rdb文件的影响，这次6380节点时将dump6380.rdb文件删除后才启动的。这些key确实由主节点同步而来
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
127.0.0.1:6380> keys *
1) "k4"
2) "k2"
3) "k3"
4) "k1"
总结
这种主从复制关系类似于下图:
这种方式无疑是加剧了主节点的写压力，而且以主节点为中心，也无法做到高可用，如果主节点宕机，那么就会有很多数据丢失。
因此可以去中心化
去中心化的主从配置
思想：上一个slave节点是下一个slave节点的master，slave节点可以接收其他slave节点的连接和同步请求。同时该slave作为了链路中下一个的master节点，也可以有效减轻master的写压力。
举例
以6379节点作为主节点，以6380节点作为从节点，以6381节点作为6380节点的从节点。
因此，只需要在6381节点上执行命令
SLAVEOF 127.0.0.1 6380
查看主从关系
可以看到，6380节点同时是6379节点的从节点，也是6381节点的父节点。注意：这里6380节点的role角色仍然是slave，所以还是不能写入数据举例如下图
可以看出，在master上设置k6-v6，在6380节点和6381节点均能读取到。想当于对数据做了接力续传一样，使从节点不都从主节点获取数据，降低了主节点的压力。
手动从节点–>master节点
前提：根据我们之前的认知，主从复制中如果主节点崩溃，那么从节点只是静默什么都不做。
如果主节点长时间恢复不了，可以使用slaveof no one命令，将某个从节点手动设置为主节点，将其他的从节点作为指向当前新主节点。
slaveof no one命令，使当前数据库停止与其他数据库的同步，转为成为主数据库。
我们把服务恢复成一主二从的情况，主节点6379，从节点6380，6381。
模拟主节点宕机，从节点上位
主节点宕机后，将6380节点设置为新的主节点，将6381节点作为6380节点的从节点，组成6380节点-6381节点的新的主从关系。
6381节点如果此时不做操作，那么等待原主节点恢复后，仍然可以组成6379节点-6381节点的主从。
这个时候，6380节点与6381节点就可以完成主从复制了，而原主节点启动后，也与这两个节点没关系了。
主从复制的缺点
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
哨兵模式
概述
可以自动地进行master节点的选举，它能够在后台监控主节点是否故障，如果故障了根据投票数，将投票数都的从节点转为新的主节点。
配置与启动
redis安装包下有sentinel.conf的配置，这里我备份了sentinel.conf，重新建一个sentin.conf，只进行少量的配置，重在演示结果。
把服务恢复成一主二从的情况，主节点6379，从节点6380，6381。
sentinel.conf
# Generated by CONFIG REWRITE
port 26379
dir "/Users/wojiushiwo/test_redis"
sentinel monitor redis6379 127.0.0.1 6380 1
sentinel down-after-milliseconds redis6379 15000
sentinel failover-timeout redis6379 900000
## 主节点设置了密码 所以这里需要配上认证密码
sentinel auth-pass redis6379 123456
其中，
sentinel monitor <master-name> <ip> <redis-port> <quorum>
## <master-name> 自己给主节点设置的名称
## ip 主节点的ip地址
## redis-port 主节点的端口号
如这里配置的是sentinel monitor redis6379 127.0.0.1 6380 1，其中最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机
启动哨兵：
sudo /usr/local/bin/redis-sentinel ~/redis/sentinel.conf
可以从启动日志可以看出，哨兵一启动就监控到了从节点
演示主节点挂了后，能否选出新主节点
先在主节点上执行shutdown操作
先从哨兵服务日志看
可以看出6380节点是主节点了，并且把还活着的6381节点也作为了自己的新从节点，甚至把宕机的6379节点也作为了自己的新子节点
从info replication来看
确实如我们所说，6380节点变成主节点了，6381节点变成6380节点的从节点了。
重启原主节点，看是否如我们所说，它真的变成了6380节点的从节点了。
确实，它变成了从节点
