VMware|Redis高可用方案—主从（masterslave）架构 centos

文章图片

文章图片

文章图片

只有一个redis节点提供服务会存在一个很明显的问题，这台redis挂了怎么办？那就会导致所有的请求全都被打到数据库，降低系统的性能。所以，我们需要部署多个redis节点来保证高可用性。 redis最常见的保证高可用的方案有三种：主从（master-slave）模式、哨兵模式和集群。本篇文章主要介绍主从复制模式的原理及搭建。
什么是主从模式主从复制模式就是，部署多台redis节点，其中只有一台节点是主节点（master），其他的节点都是从节点（slave），也叫备份节点（replica）。只有master节点提供数据的事务性操作（增删改）， slave节点只提供读操作。所有slave节点的数据都是从master节点同步过来的。该模式的架构图如下：

该图只是最简单的一种主从结构方式，所有的slave节点都挂在master节点上，这样做的好处是slave节点与master节点的数据延迟较小；缺点是如果slave节点数量很多， master同步一次数据的耗时就很长。针对这一问题，可以使用下图中的主从架构：

master下面只挂一个slave节点，其他的slave节点挂在这个slave节点下面，这样， master节点每次只需要把数据同步给它下面的那一个slave节点即可，后续slave节点的数据同步由这个slave节点完成。这样做虽然降低了master节点做数据同步的压力，但也导致slave节点与master节点数据不一致的延迟更高。
主从模式原理从主从模式的架构图可以看出，主从模式的核心就是master节点与slave节点之间的数据同步。需要注意的是， Redis和大部分中间件的主从模式中的数据同步都是由slave节点主动发起的，原因是主从模式中只有一个master节点，剩余的全是slave节点，如果由master节点主动推送数据到各个slave节点，首先维护成本太大， master节点上要维护所有slave的地址信息，而且在增加slave节点的时候，也要同步维护到master上，这样master才能将数据同步到所有的slave上面；其次master性能受影响，节点之间同步数据肯定要通过网络传输数据，由master节点建立所有slave节点的连接会对master的性能产生较大影响。而由slave发起数据同步则避免了上述问题，只需在每个slave中维护一个master的地址即可。
Redis中主从节点数据同步有两种方式：全量数据同步和增量数据同步。
全量数据同步全量数据同步一般发生在slave节点初始化阶段，需要将master上的所有数据全部复制过来。全量同步的流程图如下：

slave节点根据配置的master节点信息，连接上master节点，并向master节点发送SYNC命令；
master节点收到SYNC命令后，执行BGSAVE命令异步将内存数据生成到rdb快照文件中，同时将生成rdb文件期间所有的写命令记录到一个缓冲区，保证数据同步的完整性；
master节点的rdb快照文件生成完成后，将该rdb文件发送给slave节点；
slave节点收到rdb快照文件后，丢弃所有内存中的旧数据，并将rdb文件中的数据载入到内存中；
master节点将rdb快照文件发送完毕后，开始将缓冲区中的写命令发送给slave节点；
slave节点完成rdb文件数据的载入后，开始执行接收到的写命令。

以上就是master-slave全量同步的原理，执行完上述动作后， slave节点就可以接受来自用户的读请求，同时， master节点与slave节点进入命令传播阶段，在该阶段master节点会将自己执行的写命令发送给slave节点， slave节点接受并执行写命令，从而保证master节点与slave节点的数据一致性。
增量数据同步Redis2.8版本之前，是不支持增量数据同步的，只支持全量同步。增量数据同步是指slave节点初始化完成后， master节点执行的写命令同步到slave节点的过程。该过程比较简单， master节点每执行一个写命令后就会将该命令发送给slave节点执行，从而达到数据同步的目的。