redis主从复制

我们知道redis是一个key-value存储系统，他的存储和读取都是直接操作内存，所以会非常的快，给用户更好的体验。但是当我们的用户很多时，就意味着同一时间会有大量用户访问我们reids。这样我们的redis就会有压力。为了分担压力，我们会使用主从复制的模式。就像mysql的主从复制一样。
首先，我们有有一台主服务器来作为只接受增删改的操作(当然也可以进行查询，既然是为了分担压力，就不建议在主服务器中存在查询操作)，然后会有两台或两台以上从服务器，我们的查询操作都要去从服务器操作。这样就会比我们只有一台服务器去进行增删改查的操作压力要小很多。主服务器和各个从服务器之间必须要保持一致。也就是说当主服务器数据发生变化时，所有从服务器也要去变化，和主服务器保持一致。
redis主从复制可分为一主多从和上个从节点是下个从节点的主节点
一主多从模式

上个从节点是下个从节点的主节点
redis1是redis2的主节点，redis2是redis3的主节点

当我们使用第一种模式的时候，如果有大量的从机器都连接一台主服务器的话，在进行数据同步时，会有压力。当我们使用第二种模式时如果有大量的机器的话，这个类似于链的服务就会很长，造成从主服务器到最后一个节点的从服务器在同步数据时会用比较长的时间。所以两者可以结合使用，来解决上面的问题

主服务器和从服务器之间同步数据可分为全量复制和增量复制。他们之间是传输rdb文件来传送数据。所以我们要开启服务器的rdb持久化才可以。
Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：

• 从服务器连接主服务器，发送SYNC命令；
• 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
• 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
• 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
• 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
• 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
• 
  增量同步
  Redis增量同步是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
  增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。
  主机和从机因为网络原因断开一会也会增量复制，会将偏移量发送给主机，如果主机缓存区(1m) 被写满了之后，会按照先进先出的原则删除最先进来的数据，这个时候进行增量复制的话，会有数据丢失，从机传进来的偏移量会与主机的偏移量比较，去判断是否有数据丢失的情况，没有的话进行增量复制，有丢失就会进行全量复制
  注意

如果多个机器同一时间重启，在进行数据同步时可能会导致主机宕机
无盘复制
在上面的全量同步过程中，主机会将数据保存在rdb文件中然后发送给从机，但是如果master上的磁盘空间满了怎么办呢？那么此时全部同步对于master来说将是一份十分有压力的操作了。此时可以通过无盘复制来达到目的，由主机直接开启一个socket将rdb文件发送给从机。（无盘复制一般应用在磁盘空间有限但是网络状态良好的情况下）

在进行主从复制设置时，强烈建议在主服务器上开启持久化，当不能这么做时，比如考虑到延迟的问题，应该将实例配置为避免自动重启。
为什么不持久化的主服务器自动重启非常危险呢？
为了更好的理解这个问题，看下面这个失败的例子，其中主服务器和从服务器中数据库都被删除了。
设置节点A为主服务器，关闭持久化，节点B和C从节点A复制数据。
这时出现了一个崩溃，但Redis具有自动重启系统，重启了进程，因为关闭了持久化，节点重启后只有一个空的数据集。
节点B和C从节点A进行复制，现在节点A是空的，所以节点B和C上的复制数据也会被删除。
当在高可用系统中使用Redis Sentinel，关闭了主服务器的持久化，并且允许自动重启，这种情况是很危险的。
比如主服务器可能在很短的时间就完成了重启，以至于Sentinel都无法检测到这次失败，那么上面说的这种失败的情况就发生了。

主机宕机了之后，需要我们手动从从机中选择主机，其他的从机也要重新指定主机。这样使得我们的应用程序也要更改主机地址。所以就引入了哨兵模式。