Redis集群
单点的Redis实例所能提供的能力和可靠性是有限的。虽然说，可以一直的增加内存，来解决，但是在硬件上是有上限，无法无限制的加这个内存，同时单点带来的问题就是不够安全，一旦宕机，服务没有高可用。
Redis主从
Redis的主从关系中，采用的是读写纹理的模式，主库承担写操作，主从之间采用基于长连接的命令传播，然后由主库把写操作，同步给所有的从库。当读到读的操作时，可以达到每一台实例上。
此时，如果拥有N个从库，那么主库在同步数据的上面，会感受到压力，可以叫做是“羊群效应”。这个现象在其他的很多编程中也会有出现，比如多个监听实例，监听zk中的同一个节点等等。
Redis的做法是，采用主从联模式分担全量复制事的主库压力，调整为主-从-主的模式，选其中一个从库，把部分的从库挂在这个从库下面，数据同步由这个从库来完成。
数据同步
Redis的持久化RDB，用来完成主从之间的数据同步。当一次，从库加入当集群中时，从库向主库建立连接，发送请求同步的命令。主库收到请求后，答应了，发送FULLRESYNC{runID}{offset}消息，此时采用了全量同步，把RDB文件传输过去，进行同步。runID 为实例ID,在后续的选举中有意义，offset 为偏移量，第一次穿-1，表示第一次复制。然后主库再发送RDB文件。最后一步，主库发送新写的命令给从库。到此主从已经完成。repl_buffer,中存放了新写入的操作。在同步时，采用repl_buffer里面的数据进行与从库的同步
这里选择RDB而不是AOF的原因
- RDB采用2进制存储文件，文件较小，在网络传输过程中比较快
- RDB的执行速度比AOF快
主从断开连接
首先主从断开连接后，Redis会有2种方式，增量复制和全量复制2个方式。
增量复制
增量复制，收集在主从断开的这段时间内，主库收到的新的命令操作，在和从库重新连接后，把这些增量的命令都同步给从库。
收集这些增量命令的是，repl_backlog_buffer 是一个环形缓冲区，在从库中也有一个这样的环形缓冲区，在正常情况下，主库收到一个新的操作，环形中的位置（master_repl_offset）+1，然后同步给从库，从库的位置（slave_repl_offset）+1，所以他们应该是相差不大的，甚至业务平稳的情况下，应该是一致的。
可以看到非常像，Mysql中的redo log,虽然2者的用法截然不同，这也提现了同一个数据结构设计可以呈现出不同的功能。看到上面在第一次同步是发送的offset参数，就可以理解这个参数是干嘛用的了
全量复制
有了repl_backlog_buffer 这么好的东西，但是Redis还是会发送全量复制，是因为他是环形的，当主从之间断开的时候大量的写操作进入时，这个环形就会绕过一圈，此时再用2者的offeset去增量复制已经不够准确了，所以主从之间需要重新来过，发送RDB文件执行同步。
