Redis 主从复制

  随着项目访问量的增加，对Redis服务器的操作也越加频繁，虽然Redis读写速度都很快，但是一定程度上也会造成一定的延时，那么为了解决访问量大的问题，通常会采取的一种方式是主从架构Master/Slave，Master 以写为主，Slave 以读为主。

1. 主从复制原理

• Redis 一般是使用一个 Master 节点来进行写操作，而若干个 Slave 节点进行读操作，Master 和 Slave 分别代表了一个个不同的 Redis Server 实例。

• 定期的数据备份操作也是单独选择一个 Slave 去完成，这样可以最大程度发挥 Redis 的性能，为的是保证数据的弱一致性和最终一致性。

• Master 和 Slave 的数据不是一定要即时同步的，但是在一段时间后 Master 和 Slave 的数据是趋于同步的，这就是最终一致性。

• 全同步过程如下：

  • Slave 发送 Sync 命令到 Master。

  • Master 启动一个后台进程，将 Redis 中的数据快照保存到文件中。

  • Master 将保存数据快照期间接收到的写命令缓存起来。

  • Master 完成写文件操作后，将该文件发送给 Slave。

  • 使用新的 RDB 或 AOF 文件替换掉旧的 RDB 或 AOF 文件。

  • Master 将这期间收集的增量写命令发送给 Slave 端。

• 增量同步过程如下：

  • Master 接收到用户的操作指令，判断是否需要传播到 Slave。

  • 将操作记录追加到 AOF 文件。

  • 将操作传播到其他 Slave：对齐主从库；往响应缓存写入指令。

  • 将缓存中的数据发送给 Slave。

2. 主从复制配置

下面我们来搭建一主双从的 Redis 集群

2.1 一主双从

准备三台虚拟机，配置好主机名、IP地址和Redis环境。本教程中为了演示方便，在一台虚拟机中配置三个Redis实例。

• 创建目录：根目录下创建 rediscluster 目录

mkdir /rediscluster

• 复制配置文件：把 redis.conf 复制到这个目录中

cp /etc/redis.conf /rediscluster/redis.conf

• 创建三个文件：在rediscluster目录下分别创建三个文件： redis-6379.conf、redis-6380.conf 和 redis-6381.conf。

vim redis-6379.conf

# 文件内容如下：
include /rediscluster/redis.conf
# 修改端口号
port 6379
# 修改pid文件名
pidfile "/var/run/redis_6379.pid"
# 修改持久化文件名
dbfilename "dump_6379.rdb"
dir "/rediscluster"

# 同样的方式创建另外两个文件并做相应的修改。

• 启动服务：分别启动三台 Redis 服务器：

rediscluster]# redis-server redis-6379.conf
rediscluster]# redis-server redis-6380.conf
rediscluster]# redis-server redis-6381.conf

• 验证服务

rediscluster]# ps -ef | grep redis

• 连接服务：分别使用 redis-cli 来连接这三台服务（三个窗口）：

rediscluster]# redis-cli -p 6379
rediscluster]# redis-cli -p 6380
rediscluster]# redis-cli -p 6381

• 进行复制：客户端连接上后，执行如下命令：

127.0.0.1:6379> info replication
127.0.0.1:6380> info replication
127.0.0.1:6381> info replication

• 从图中可以发现，这三台都是 master，也就是都是主服务器。

• 配置主从：假设我们希望 6379 是主服务器，而 6380 和 6381 是从服务器，则需要做如下配置。

# 命令格式：slaveof <ip> <port>

# 我们分别在 6380 和 6381 客户端中执行如下命令：

127.0.0.1:6380> slaveof 127.0.0.1 6379
OK
127.0.0.1:6381> slaveof 127.0.0.1 6379
OK

# 注意：

	# 1. 在 redis-cli 客户端中执行 slaveof 命令只会对当前环境生效，重启后失效。要想永久生效，需要在 redis.conf 配置文件中添加 `slaveof <masterip> <masterport>` 配置。

	# 2. 在 Redis 5.0 后，新增了 replicaof 命令，作用与 slaveof 命令效果一致。

# 再次执行 `info replication` 命令查看，可以发现已经变为了从机了。

• 集群测试：在 6379 中添加如下数据：

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK

# 然后在从机上查询：

127.0.0.1:6380> get k1
1) "v1"
127.0.0.1:6381> get k1
1) "v1"

# 发现数据已经同步了。

注意：

1. 如果我们在从服务器中添加数据，则会报错。因为从服务器只能读。

2. 如果从机宕机了，重启后会变为主服务器，需要重新执行 slaveof <ip> <port> 命令。

如果主机宕机了，重启后一切正常。

2.2 主从切换

• 当一个 master 宕机后，后面的 slave 可以立刻升为 master，其后面的 slave 不用做任何修改。

• 用 slaveof no one 将从机变为主机。

• 假设主机 6379 宕机了，我们可以在 6380 上执行如下命令来切换为主机：

127.0.0.1:6380> slaveof no one

• 查看 6380，已经变为主机了。

3. 哨兵模式

3.1 什么是哨兵模式

  哨兵也叫 sentinel，它的作用是能够在后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

3.2 配置哨兵

首先停止三台 Redis 服务。

redis-cli shutdown

• 然后再重新启动三台 Redis 服务器，并实现一主双从。

• 最后在 /rediscluster 目录下新建 sentinel.conf 文件，文件名称不能写错，必须叫这个名称。

rediscluster]# vim sentinel.conf

• 内容如下：

sentinel monitor redismaster 127.0.0.1 6379 1

参数说明：

• monitor：监控

• redismaster：为监控对象起的服务名称

• 1：为至少有多个个哨兵同意迁移的数量

3.3 启动哨兵

执行如下命令来启动哨兵

rediscluster]# redis-sentinel sentinel.conf

3.4 验证哨兵

• 把主服务器停止：

127.0.0.1:6379> shutdown

•  这时，哨兵就会介入，并进行选举，然后把选举成功的从面切换为主机。

• 如果我们把 6379 重新启动，则它会变为从机。

127.0.0.1:6379> info replication

4. 复制延时

   由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

4.1 选举策略

• 选择优先级靠前的服务器。优先级的配置在 redis.conf 文件中的 replica-priority 配置，默认为 100，值越小优先级越高。

• 选择偏移量最大的。偏移量是指获得原主机数据最全的。

• 选择 runid 最小的从服务器。每个redis实例启动后都会随机生成一个40位的runid。