Redis集群模式1-主从复制+哨兵机制

单个Redis服务如果宕机的话，服务就不可用了，为了解决这种问题，redis也提供有集群服务。传统的Redis集群采用的主从复制模式，一般为一主多从，主节点有读写权限，但是从节点只有读的权限。主节点会定期将数据同步到从节点中，保证数据一致性的问题。这种集群方式在运行时存在一些问题：

Redis的哨兵机制就是解决主从复制存在缺陷（选举问题），解决问题保证我们的Redis高可用，实现自动化故障发现与故障转移。

要使用哨兵机制，除了启动Redis服务以外，还要启动哨兵服务来进行监控，会介绍详细步骤。哨兵服务的工作原理如下：

演示集群采用1主2从，采用伪集群，在一台虚拟机中启动，端口暂定6381、6382、6383，集群结构可以选择下面2种，因为数量较少，此次采用普通样式。

主节点配置文件和单机的时候一样，主要修改以下几点

基本和主节点差不多，但要加上 slaveof 配置和主节点账号密码。

哨兵配置文件是 sentinelconf ，因为有3个redis服务，所以启动3个哨兵服务，对应的配置文件分别为： sentinel_26381conf 、 sentinel_26382conf 、 sentinel_26383conf

Redis服务和哨兵服务都启动了，可以测试哨兵的自动选举了，将6381沙雕，等几秒，再查看6382,6382的主从信息

注意：这个时候如果去看redis的配置文件，会发现配置文件中已经自动改好了主节点为6383了；而且哨兵的配置文件中，也改了主节点为6383了。这些都是哨兵帮我们做的

因集群中已有了新主节点，所以6381再启动只能作为从节点。此时6381启动，需要在配置文件中加入主节点信息：

redis主从复制

redis主从配置比较简单，基本就是在从节点配置文件加上:slaveof 19216833130 6379

主要是通过master server持久化的rdb文件实现的。master server 先dump出内存快照文件，然后将rdb文件传给slave server，slave server 根据rdb文件重建内存表。

redis复制过程如下：

1、slave server启动连接到master server之后，salve server主动发送SYNC命令给master server

2、master server接受SYNC命令之后，判断，是否有正在进行内存快照的子进程，如果有，则等待其结束，否则，fork一个子进程，子进程把内存数据保存为文件，并发送给slave server

3、master server子进程进程做数据快照时，父进程可以继续接收client端请求写数据，此时，父进程把新写入的数据放到待发送缓存队列中

4、slave server 接收内存快照文件之后，清空内存数据，根据接收的快照文件，重建内存表数据结构

5、master server把快照文件发送完毕之后，发送缓存队列中保存的子进程快照期间改变的数据给slave server，slave server做相同处理，保存数据一致性

6、master server 后续接收的数据，都会通过步骤1建立的连接，把数据发送到slave server

需要注意：slave server如果因为网络或其他原因断与master server的连接，当slave server重新连接时，需要重新获取master server的内存快照文件，slave server的数据会自动全部清空，然后再重新建立内存表，这样会让slave server 启动恢复服务比较慢，同时也给master server

浅谈Redis主从复制

20130927 11:27:00 来源: 京东 作者:张成远 ( 0 条评论 )

Redis是一个开源的，遵守BSD许可协议的key/value缓存系统，并由其高效的响应速度以及丰富的数据结构而闻名。Redis在京东的使用也是非常普遍的，包括很多关键业务上的使用，由于Redis官方集群还未发布，在使用Redis的过程中需要面对Redis的单点问题，京东采用的是一种比较通用的解决方案即由主从备份再加相应的主从切换（在一些场景下可能进行读写分离），使主Redis出现失效的时候可以快速的切换到从Redis上。但Redis目前存在的一个问题是主从复制在遇到网络不稳定的情况下，Slave和Master断开（包括闪断）会导致Master需要将内存中的数据全部重新生成rdb文件（快照文件），然后传输给Slave。Slave接收完Master传递过来的rdb文件以后会将自身的内存清空，把rdb文件重新加载到内存中。这种方式效率比较低下，尤其是在数据量大的情况下，毕竟网络闪断未必丢数据或者说丢的数据只是少部分，但却要为此付出将整个内存数据都重新传输一次的代价。如果能够将闪断过程的更新数据传递给Slave，那么就不需要将Master内存中的所有数据都传递给Slave了。Redis作者在28的候选版（以下简称Redis28）中已经将这个部分复制的思路实现了。

那么Redis2416的全量复制与Redis28的部分复制是如何实现的呢如下图所示,这5个状态是Slave在主从复制过程涉及到的几个状态，其中REDIS_REPL_NONE是Redis启动时候默认的状态。图1-2所示的四个状态表示站在Master的角度来看，Slave所处于的状态，因为Slave在Master端看来就是一个特殊的client（同理Master在Slave端看来也是一个特殊的client）。

/ Slave replication state – Slave side /

Slave自身的状态

Master端的Slave状态

Redis在接收到“slaveof ip port”命令以后，首先会将自身的状态置为REDIS_REPL_CONNECT，表示需要与自己的Master连接，此时Slave并没有与Master做连接。Redis每隔100ms会调用serverCron()函数一次，每10次serverCron()的调用会调用replicationCron()一次，即每1s会调用一次replication()函数。在replication()函数中，会检查Slave的状态，如果是处于REDIS_REPL_CONNECT状态，就会建立syncWithMaster()的事件处理函数，并将Slave的状态改成REDIS_REPL_CONNECTING。syncWithMaster()函数主要是向Master发送sync命令，当该事件处理函数被触发以后会将Slave的状态改成REDIS_REPL_TRANSFER，表示Slave已经准备就绪要接收Master生成的rdb文件。

回到Master的角色，Master发现有一个Slave连接上来，如果此时的Master一个Slave都没有且没有后台快照进程，则启动一个后台进程将当前内存中的数据生成一个rdb文件，同时将Slave的状态置为REDIS_REPL_WAIT_BGSAVE_END状态，表示该Slave等待Master的快照进程结束。在后台进行生成rdb文件的时候，如果有对redis的更新命令，Master会将这些更新命令存到该Slave的buffer中，如果buffer满了会另外开辟list来存储这些更新命令。当后台快照进程结束，Master会将该Slave的状态改为REDIS_REPL_SEND_BULK，同时注册sendBulkToSlave()事件处理函数用于将生成的rdb文件传输给Slave。等rdb传输结束以后，sendBulkToSlave()事件函数会被删除，Slave的状态会被更改为REDIS_REPL_ONLINE，另外再注册sendReplyToClient()事件函数，将Master在快照内过程中的所有更新 *** 作（Slave的buffer里存的命令）发给Slave。

再回到Slave的角色，当Master向Slave传输完rdb文件以后，Slave自身会将状态改为REDIS_REPL_CONNECTED，表示复制已完成，处于与Master保持实时同步的状态。

上述描述的状态转换如图1-3所示，由图中可知，站在Slave角色看，当出现网络中断的时候不管Slave本身是处于REDIS_REPL_CONNECTING、REDIS_REPL_REPL_TRANSFER还是REDIS_REPL_CONNECTED，都会调用相应的处理函数使Slave进入REDIS_REPL_CONNECT状态，这就意味着Slave需要重新向Master发送sync命令，重新进行一次全量同步过程。图中的REDIS_REPL_WAIT_BGSAVE_START状态是在Slave连接上Master的时候（站在Master的角色看），当时Master刚好后台有快照进程且该快照进程生成的rdb不适合直接传给该Slave时出现的状态，则将Slave的状态置为REDIS_REPL_WAIT_BGSAVE_START。如果此时有快照进程且找到了另外的发起快照进程的Slave，只需要将另外的Slave的buffer内容拷贝到该Slave的buffer中，然后直接进入REDIS_REPL_WAIT_BGSAVE_END状态。如果此时没有后台快照进程，Slave直接进入REDIS_REPL_WAIT_BGSAVE_END状态，同时启动一个后台快照进程。

redis主从复制

和Mysql主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。下图为级联结构。

全量同步

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下： 

-  从服务器连接主服务器，发送SYNC命令； 

-  主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令； 

-  主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； 

-  从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； 

-  主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； 

-  从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

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

增量同步

Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写 *** 作同步到从服务器的过程。 

增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

Redis主从同步策略

主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

以上就是关于Redis集群模式1-主从复制+哨兵机制全部的内容，包括:Redis集群模式1-主从复制+哨兵机制、redis 如何判断是集群还是主从、浅谈Redis主从复制[转载]等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！