Redis主从复制
redis支持集群的架构。集群的节点有主节点和从节点之分，主节点叫master，从节点叫slave。slave会通过复制的技术，自动同步master的数据。
1 主从复制配置
Redis的主从配置非常的简单，只需要在配置文件里面添加一行配置就可以了。例如一主多从，186是主节点，在每个slave节点的redis.conf配置文件增加一行:
1 | |
从节点启动之后，就会自动连接到master节点，开始同步数据。如果master节点变了，比如原来的master宕机，选举出了新的master，这个配置会被重写。还有一种方式，就是在启动服务器时通过参数直接指定master节点：
1 | |
一个正在运行的节点，可以改变其他节点的从节点，这就是第三种方式，在客户端直接执行slaveof IP port，使该redis实例成为从节点。
1 | |
一个从节点也可以是其他节点的主节点，形成级联复制的关系。查看集群状态:
1 | |
从节点是只读的，不能执行写操作。执行命令会报错。在主节点写入后，slave会自动从master同步数据。把配置文件里面的replica of去掉重启，或者直接断开复制：
1 | |
此时从节点会变成自己的主节点，不再复制数据。MySQL的主从复制原理是依赖binlog，然后还有几个线程。
2 主从复制原理
Redis的主从复制分为两类，一种叫全量复制，就是一个节点第一次连接到master节点，需要全部的数据。第二种叫做增量复制，比如之前已经连接到master节点，但是中间网络断开，或者slave节点宕机了，缺失了一部分的数据。
2.1 连接阶段
slave节点启动时（或者执行slaveof命令时），会在自己本地保存master节点的消息，包括master node的host和ip。
slave节点内部有个定时任务replicationCron，每个一秒检查是否有新的master node要连接和复制。
如果发现有master节点，就跟master节点建立连接。如果连接成功，从节点就会连接建立一个专门处理复制工作的文件事件处理器负责后续的复制工作。为了让主节点感知到slave节点的存在，slave节点定时会给主节点发送ping请求。
2.2 数据同步阶段
如果是新加入的slave节点，那就需要全量复制。Master通过bgsave命令再本地生成一份RDB快照，将RDB快文件发给slave节点（如果超时会重连，可以调大repl-timeout的值）。
如果slave自己本来有数据，Slave节点首先需要清除自己的旧数据，然后用RDB文件加载数据。
master节点生成RDB期间，如果接收到写命令，开始生成RDB文件时，master会把所有新的写命令缓存在内存中，在slave节点保存了RDB之后，再将新的写命令复制给slave节点。（跟AOF重写rewrite期间接收到的命令的处理思路是一样的）。
第一次全量同步完了，主从已经保持一致了，后面就是持续把接收到的命令发送给slave节点。
2.3 命令传播阶段
master节点持续把写命令，异步复制给slave节点。总结起来非常的简单，前面同RDB文件，后面把命令发给slave节点，就实现了主从复制。注意，一般情况下不会用redis做读写分离，因为redis的吞吐量已经够高了，做集群分片之后并发的问题更少，所以不需要考虑主从延迟的问题。跟MySQL一样主从之间复制延迟是不可避免的，只能通过优化网络来改善。
第二种情况就是增量复制了。slave通过master_repl_offset记录偏移量。Redis的一个新特性，就是主从复制的无盘复制（从2.8.18版本开始支持无盘复制）。
1 | |
为了降低主节点的磁盘开销，redis支持无盘复制，master生成的RDB文件并不保存到磁盘而是直接通过网络发送给从节点。无盘复制适用于主节点所在机器磁盘性能较差但网络带宽较充裕的场景。
3 主从复制不足
Redis的主从复制解决了数据备份和一部分性能的问题，但是没有解决高可用的问题。在一主一从或者多主多从的情况下，如果主服务器挂了，对外提供的服务就不可用了，单点问题没有得到解决。跟mysql一样。如果每次都是手动把之前的从服务器切换到主服务器，然后再把剩余节点设置为它的从节点，这个比较费时费力，还会造成一定时间的服务不可用。