Redis集群系列二 —— 主从架构

主从复制原理

从节点向主节点发送 sync 命令，获取主服务器的数据，主服务器收到 sync 命令后，则生成 RDB 快照文件并发送给从从节点。

Redis 的复制分为两部分操作：同步 和 命令传播。

• 同步：用来将从节点的状态更新到和主节点一致。
• 命令传播：在主节点数据被修改后，为了让从节点保持和主节点状态一致，而做的命令传播。

为什么需要同步和命令传播的两种复制操作？

因为在做同步操作的时候，从节点向主节点发送 sync 命令时候，主节点在生成 RDB 快照文件时候，会不断收到客户端的命令修改数据状态，这时如果不能传达给从节点，那么就会出现主从数据不一致的问题。

这时候就出现了命令传播，主节点收到从节点的 sync 命令后，生成 RDB 快照文件同时，将此段时间内收到的命令缓存起来，然后使用命令传播的操作发送从节点，以此来达到主从数据一致。

准备实例和配置

由于设备限制原因，在当前用例中配置的是一主两从。结构如图：

首先在同一台虚拟机开启3个实例，必须先准备三份不同的配置文件。如图：

 


 

开启主从关系

现在三个实例还没有任何关系，要配置主从可以使用 replicaof 或者 slaveof（5.0以前）命令。

开启主从模式有临时和永久两种模式。

临时

• 使用 redis-cli 客户端连接到 redis 服务，执行 replicaof 命令。

永久

• 修改配置文件，在redis.conf中添加一行配置：replicaof <masterip> <masterport>

为了方便学习，使用了临时的方式。

通过 redis-cli 命令连接 6379 节点，并打开实时日志。

[root@localhost utils]# redis-cli -p 6379
127.0.0.1:6379>

再次通过 redis-cli 命令连接 6380，执行下面命令：

[root@localhost utils]# redis-cli -p 6380
127.0.0.1:6380> replicaof 127.0.0.1 6379
OK
127.0.0.1:6380> 

说明主从配置成功。

通过执行以下命令查看状态

127.0.0.1:6380> info replication

 再次打开 6379 节点输出的日志，可以看到以下信息：

 从日志中可以看出 6380 节点已经配置成功。

上边使用的是启动后配置主从关系，接下来启动 6381 节点时就指定主从关系

redis-server /etc/redis/6381.conf --replicaof 127.0.0.1 6379

再次打开 6379 节点输出的日志，可以看到以下信息： 

 到此，主从就配置完成了。

再次进入到 6379 节点为中查询状态，如图：

测试

执行下列操作以测试：

使用 redis-cli 分别连接 6379、6380、6381，执行 set k1 test 命令，只有 6379 才可以执行成功，其余两个节点为在做添加的时候出现：(error) READONLY You can't write against a read only replica。

Redis 集群优缺点

优点

• 实现扩容
• 分摊压力
• 无中心配置相对简单

缺点

• 多键操作是不被支持的
• 多键的Redis事务是不被支持的。lua脚本不被支持
• 由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

总结

主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。故障恢复无法自动化，写操作无法负载均衡，存储能力受到单机的限制。

以上操作虽然完成了主从集群搭建，实现了数据横向扩展，但还存在一个非常严重的问题，当主节点挂了整个服务就会嗝屁。