文章目录
- 一、概述
- 二、主从复制模拟说明
- 三、准备配置文件
- 四、启动Redis实例
- 五、主从复制配置
- 5.1 命令方式启用和取消主从复制
- 5.2 配置文件方式启用和取消主从复制
- 5.3 测试主从复制
- 5.4 有其主从复制的其他参数配置
- 六、Sentinel 配置
- 6.1 Sentinel 的作用
- 6.2 Sentinel 监控说明
- 6.3 Sentinel 配置文件
- 6.4 开启 Sentinel
- 6.5 测试
如果您对Redis的了解不够深入请关注本栏目,本栏目包括Redis安装,Redis配置文件说明,Redis命令和数据类型说明,Redis持久化配置。
一、概述
-
Redis 主从复制是 Redis 提供的一种数据复制机制,用于实现数据冗余和高可用性。在主从复制中,一个 Redis 节点(主节点)负责接收写操作并将数据复制到一个或多个从节点。从节点复制主节点的数据,并且在主节点发生故障时可以接管成为新的主节点,以保持服务的可用性。
-
通过主从复制,Redis 构建了一个具有冗余数据和自动故障切换能力的分布式系统,提高了系统的可用性和容错能力。此外,Redis 主从复制还允许根据业务需求动态添加或移除从节点,以适应负载变化和扩展需求。满足AKF软件架构概念,即可用性(Availability)、可扩展性(Scalability)和灵活性(Flexibility)。
-
Redis 主从复制在一定程度上牺牲了一致性。在主从复制的架构中,当主节点发生故障时,从节点会接管成为新的主节点,但在切换过程中可能会存在数据的不一致性。这是因为主从复制采用异步复制的方式,导致从节点的数据可能会有一段时间的延迟。这是一个分布式系统设计CAP理论,即一致性(Consistency)、可用性(Availability)和分区容错性(Partition Tolerance)。CAP 理论指出在一个分布式系统中,无法同时满足这三个属性,最多只能同时满足其中两个。
-
数据一致性有两种方式,即强一致性(所有节点阻塞直到数据全部一致)和最终一致性(异步方式)。因为强一致破坏了可用性,最终一致性会导致数据不一致。所以实使用时需结合实际情况选择。
二、主从复制模拟说明
- 在一台主机上开启3个Redis服务来模拟Redis主从复制。我这里配置端口6381为主,6382和6383为从。示意图如下:
三、准备配置文件
- 新建3个配置文件,分别为 redis_6381.conf、redis_6382.conf、redis_6383.conf(您也可以把原redis.conf直接复制三份,然后修改端口、数据目录和进程ID文件即可),有关配置项的详细解释请看Redis配置文件说明。
- redis_6381.conf
# 导入默认 redis 配置文件
include redis.conf
# 配置端口
port 6381
# 配置数据目录
dir /var/lib/redis/6381
# 配置进程ID文件
pidfile /var/run/redis_6381.pid
# 以下参数可选
# supervised no
# daemonize no
# logfile ""
# appendonly no
- redis_6382.conf
# 导入默认 redis 配置文件
include redis.conf
# 配置端口
port 6382
# 配置数据目录
dir /var/lib/redis/6382
# 配置进程ID文件
pidfile /var/run/redis_6382.pid
# 以下参数可选
# supervised no
# daemonize no
# logfile ""
# appendonly no
# replicaof 127.0.0.1 6381
- redis_6383.conf
# 导入默认 redis 配置文件
include redis.conf
# 配置端口
port 6383
# 配置数据目录
dir /var/lib/redis/6383
# 配置进程ID文件
pidfile /var/run/redis_6383.pid
# 以下参数可选
# supervised no
# daemonize no
# logfile ""
# appendonly no
# replicaof 127.0.0.1 6381
-
注意,配置完成后要检查以上配置目录是否存在,如果不存请手动创建,如下:
mkdir -p /var/lib/redis/6381 /var/lib/redis/6382 /var/lib/redis/6383
四、启动Redis实例
-
分别启3个Redis服务实例。
# 主节点,端口6381 redis-server redis_6381.conf # 从节点1,端口6382 redis-server redis_6382.conf # 从节点2,端口6383 redis-server redis_6383.conf
五、主从复制配置
5.1 命令方式启用和取消主从复制
- 启用主从复制
- 使用redis-cli分别连接6382、6383端口的Redis服务,然后使用 REPLICAOF 命令将自己作为从节点,加入到主节点6381中(旧版Redis中使用SLAVEOF命令)即完成主从复制的Redis配置。如下
REPLICAOF 127.0.0.1 6381
[root@yiqifu-redis ~]# redis-cli -p 6382
127.0.0.1:6381> REPLICAOF 127.0.0.1 6381
OK[root@yiqifu-redis ~]# redis-cli -p 6383
127.0.0.1:6381> REPLICAOF 127.0.0.1 6381
OK
- 取消主从复制
- 取消作为从节点,相当于把自己升为主节点
REPLICAOF no one
[root@yiqifu-redis ~]# redis-cli -p 6382
127.0.0.1:6381> REPLICAOF no one
OK
5.2 配置文件方式启用和取消主从复制
- 启用只需分别在redis_6382.conf、redis_6383.conf 配置文件中添加以下配置,然后重起Redis服务即可。
- 取消则把以下配置删除即可。
# replicaof <masterip> <masterport>
replicaof 127.0.0.1 6381
5.3 测试主从复制
-
完成后你可以在6381上添加数据,然后从6382和6383上读取数据
[root@yiqifu-redis conf]# redis-cli -p 6381
127.0.0.1:6381> set aaa 111
OK
127.0.0.1:6381>
[root@yiqifu-redis conf]# redis-cli -p 6382
127.0.0.1:6382> keys *
1) “aaa”
127.0.0.1:6382>
[root@yiqifu-redis conf]# redis-cli -p 6383
127.0.0.1:6383> keys *
1) “aaa”
127.0.0.1:6383>
5.4 有其主从复制的其他参数配置
- 根据业务情况选择
### 对于主机
# 在主从复制模式中,主机向从机同步数据时,是否直接通过网络发送,而不是先在磁盘建立RDB然后再同步。
# 也就是yes就是直接从网络发,no就是先存磁盘,然后再发
repl-diskless-sync no
# 在主从复制模式中,复制的缓存区大小。
# 太小可能会因为从机无法追赶上主服务的操作而导致复制延迟。太大又会占用更多空间
# repl-backlog-size 1mb
### 对于从机
# 在主从复制模式中,在从机同步主机数据过程中,是否暴露原数据。
# 也就是从机在同步主机数据的过程中,是否让应用程序可以访问从机的未同步前的数据
replica-serve-stale-data yes
# 在主从复制模式中,从机是否为只读模式
replica-read-only yes
### 对于 Sentinel
# 设置在执行写操作之前,Sentinel 要求的最少副本数量。
# 例如,如果你将 min-replicas-to-write 设置为3,那么在执行写操作之前,至少需要有3个从服务器(副本)是可用的,以确保数据的高可用性和一致性。
# 如果可用的从服务器数量低于配置的值,写操作将被拒绝,以确保数据的完整性。
# min-replicas-to-write 3
# 设置从服务器的最大复制延迟。
# 例如,如果你将 min-replicas-max-lag 设置为10,那么当从服务器的复制延迟超过10秒时,Sentinel不再将其视为可用的副本。
# 这是为了确保只有具有较低延迟的从服务器被认为是可用的,以防止可能导致数据不一致的情况。
# min-replicas-max-lag 10
六、Sentinel 配置
6.1 Sentinel 的作用
-
在前面的配置中当主节点挂掉以后,就没有主了,想要恢复只能手动。而Sentinel的的作用的就是监控这些Redis服务,当主节点挂掉以后会自动选一个可用的从节点升级为主机,保证服务的可用性。
-
具体来说,Redis 的 Sentinel 系统用于管理多个 Redis 服务器(instance),实现在Redis的高可用, 该系统执行以下三个任务:
-
监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
-
提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
-
自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。
-
6.2 Sentinel 监控说明
- 同样,我们也一台主机上开启3个Sentinel 服务来监控 Redis主从复制服务实例。我这里配置端口26381、26382和26383。
6.3 Sentinel 配置文件
-
新建3个配置文件,分别为 sentinel_26381.conf、sentinel_26382.conf、sentinel_26383.conf。分别用来监控Redis主从实例6381、6382和6383。
-
sentinel_26381.conf
port 26381
sentinel monitor mymaster 127.0.0.1 6381 2
- sentinel_26382.conf
port 26382
sentinel monitor mymaster 127.0.0.1 6381 2
- sentinel_26383.conf
port 26383
sentinel monitor mymaster 127.0.0.1 6381 2
6.4 开启 Sentinel
redis-sentinel sentinel_26381.conf
redis-sentinel sentinel_26382.conf
redis-sentinel sentinel_26383.conf
- 也可通过这种方式启动:redis-server sentinel_26381.conf --sentinel
6.5 测试
-
成功开启后如果Redis服务6381停止,Sentinel 会在 6382 和 6383 中选一台升级为主。当再次启动 6381 时,Sentinel 会把他作为从加入当前主中。以下是我测试时的日志:
Redis 6381 用户停止
6277:M 27 Oct 2023 15:53:23.922 # User requested shutdown…
6277:M 27 Oct 2023 15:53:23.922 * Saving the final RDB snapshot before exiting.
6277:M 27 Oct 2023 15:53:23.951 * DB saved on disk
6277:M 27 Oct 2023 15:53:23.951 * Removing the pid file.
6277:M 27 Oct 2023 15:53:23.951 # Redis is now ready to exit, bye bye…Redis 6382 被 Sentinel 选为主
6126:M 27 Oct 2023 15:53:54.391 * Discarding previously cached master state.
6126:M 27 Oct 2023 15:53:54.391 # Setting secondary replication ID to 00cd50f9815b69bcda4fc80abc782afc0a4785da, valid up to offset: 17475. New replication ID is f1aa0d5cb34adbf6d20f1bc8a3824e1b77304fa6
6126:M 27 Oct 2023 15:53:54.391 * MASTER MODE enabled (user request from ‘id=10 addr=127.0.0.1:58452 fd=8 name=sentinel-18226c99-cmd age=590 idle=0 flags=x db=0 sub=0 psub=0 multi=4 qbuf=188 qbuf-free=32580 obl=45 oll=0 omem=0 events=r cmd=exec user=default’)
6126:M 27 Oct 2023 15:53:54.392 # CONFIG REWRITE executed with success.
6126:M 27 Oct 2023 15:53:54.771 * Replica 127.0.0.1:6383 asks for synchronization
6126:M 27 Oct 2023 15:53:54.772 * Partial resynchronization request from 127.0.0.1:6383 accepted. Sending 156 bytes of backlog starting from offset 17475.Redis 6383 作为从跟随 6382
6153:S 27 Oct 2023 15:53:54.708 * REPLICAOF 127.0.0.1:6382 enabled (user request from ‘id=8 addr=127.0.0.1:57678 fd=10 name=sentinel-18226c99-cmd age=590 idle=0 flags=x db=0 sub=0 psub=0 multi=4 qbuf=329 qbuf-free=32439 obl=45 oll=0 omem=0 events=r cmd=exec user=default’)
6153:S 27 Oct 2023 15:53:54.709 # CONFIG REWRITE executed with success.
6153:S 27 Oct 2023 15:53:54.769 * Connecting to MASTER 127.0.0.1:6382
6153:S 27 Oct 2023 15:53:54.769 * MASTER <-> REPLICA sync started
6153:S 27 Oct 2023 15:53:54.769 * Non blocking connect for SYNC fired the event.
6153:S 27 Oct 2023 15:53:54.771 * Master replied to PING, replication can continue…
6153:S 27 Oct 2023 15:53:54.771 * Trying a partial resynchronization (request 00cd50f9815b69bcda4fc80abc782afc0a4785da:17475).
6153:S 27 Oct 2023 15:53:54.773 * Successful partial resynchronization with master.
6153:S 27 Oct 2023 15:53:54.773 # Master replication ID changed to f1aa0d5cb34adbf6d20f1bc8a3824e1b77304fa6
6153:S 27 Oct 2023 15:53:54.773 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization.Sentinel 26381 被 Sentinel 26382 和 26383 选举为 leader, 然后协调 Redis 6382 为 Master 和 Redis 6383 为 Slave 的过程日志
6214:X 27 Oct 2023 15:53:54.213 # +elected-leader master mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.213 # +failover-state-select-slave master mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.307 # +selected-slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.307 * +failover-state-send-slaveof-noone slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.390 * +failover-state-wait-promotion slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.628 # +promoted-slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.628 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:54.708 * +slave-reconf-sent slave 127.0.0.1:6383 127.0.0.1 6383 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:55.265 # -odown master mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:55.612 * +slave-reconf-inprog slave 127.0.0.1:6383 127.0.0.1 6383 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:55.612 * +slave-reconf-done slave 127.0.0.1:6383 127.0.0.1 6383 @ mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:55.664 # +failover-end master mymaster 127.0.0.1 6381
6214:X 27 Oct 2023 15:53:55.664 # +switch-master mymaster 127.0.0.1 6381 127.0.0.1 6382
6214:X 27 Oct 2023 15:53:55.665 * +slave slave 127.0.0.1:6383 127.0.0.1 6383 @ mymaster 127.0.0.1 6382
6214:X 27 Oct 2023 15:53:55.665 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6382
6214:X 27 Oct 2023 15:54:25.741 # +sdown slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6382