说明网站建设岗位工作职责,个人网站如何做支付功能,山东济南网站制作,钢材技术支持东莞网站建设Redis 主从复制 读写分离1. Redis 主从复制 读写分离介绍1.1 从数据持久化到服务高可用1.2 主从复制1.3 如何保证主从数据一致性#xff1f;1.4 为何采用读写分离模式#xff1f;2. 一主两从环境准备2.1 配置文件2.2 启动 Redis3. 主从复制原理3.1 全量同步3.1.1 建立连接3…
Redis 主从复制 读写分离1. Redis 主从复制 读写分离介绍1.1 从数据持久化到服务高可用1.2 主从复制1.3 如何保证主从数据一致性1.4 为何采用读写分离模式2. 一主两从环境准备2.1 配置文件2.2 启动 Redis3. 主从复制原理3.1 全量同步3.1.1 建立连接3.1.2 主库同步数据给从库3.1.3 发送新写命令到从库3.2 增量同步3.2.1 主从网络断开之后的同步方式3.2.2 repl_backlog_buffer3.2.3 基于长连接的命令传播1主 - 从PING2从 - 主REPLCONF ACK4. 总结1. Redis 主从复制 读写分离介绍
1.1 从数据持久化到服务高可用
Redis 的数据持久化技术可以解决机器宕机数据丢失的问题并没有从根本上解决 Redis 的可用性。我们需要的是解决 Redis 的高可用减少甚至避免 Redis 服务发生宕机的可能来从根本上解决数据丢失问题。
如果对 Redis 如何进行数据持久化不是很了解的同学可以读一下Redis 数据持久化AOF和RDB
1.2 主从复制
目前实现Redis高可用的模式主要有三种 主从模式、哨兵模式、集群模式。这篇文章我们来一起学习主从模式。
Redis 提供的主从模式是通过复制的方式将主服务器上的 Redis 的数据同步复制一份到从 Redis 服务器这种做法很常见MySQL 的主从也是这么做的。
主节点的 Redis 我们称之为 master从节点的 Redis 我们称之为 slave主从复制为单向复制只能由主到从不能由从到主。可以有多个从节点比如1主2从甚至n从从节点的多少根据实际的业务需求来判断。
1.3 如何保证主从数据一致性
采取读写分离的模式 读操作主、从库都可以执行一般是在从库上读数据对实时性和准确性有100%高真要求的部分业务可以谨慎评估之后读主库 写操作只在主库上写数据写完之后将写操作指令同步到从库。 1.4 为何采用读写分离模式
你可以设想一下不管是主库还是从库都能接收客户端的写操作。那么一个直接的问题就是如果客户端对同一个数据例如 k1前后修改了三次每一次的修改请求都发送到不同的实例上在不同的实例上执行那么这个数据在这三个实例上的副本就不一致了分别是 v1、v2 和 v3。在读取这个数据的时候就可能读取到旧的值。
如果我们非要保持这个数据在三个实例上一致就要涉及到加锁、实例间协商是否完成修改等一系列操作但这会带来巨额的开销当然是不太能接受的。
而主从库模式一旦采用了读写分离所有数据的修改只会在主库上进行不用协调三个实例。主库有了最新的数据后会同步给从库这样主从库的数据就是一致的。
那么主从库同步是如何完成的呢主库数据是一次性传给从库还是分批同步要是主从库间的网络断连了数据还能保持一致吗下面我们来一起学习。
2. 一主两从环境准备
2.1 配置文件
创建目录
mkdir -p /data/redis/master/data
mkdir -p /data/redis/slave1/data
mkdir -p /data/redis/slave2/data主配置文件
bind 0.0.0.0
port 6379
daemonize yes
requirepass 123456
logfile /usr/local/redis/log/redis1.log
dbfilename pointer1.rdb
dir /usr/local/redis/data
appendonly yes
appendfilename appendonly1.aof
masterauth 123456两个从配置文件
bind 0.0.0.0
port 6380
daemonize yes
requirepass 123456
logfile /usr/local/redis/log/redis2.log
dbfilename pointer2.rdb
dir /usr/local/redis/data
appendonly yes
appendfilename appendonly2.aof# 从本机 6379 的 redis 实例复制数据Redis 5.0 之前使用 slaveof
replicaof 8.129.113.233 6379
# 从节点开启只读模式默认
replica‐read‐only yes
# 从节点访问主节点的密码和 requirepass ⼀样
masterauth 123456bind 0.0.0.0
port 6381
daemonize yes
requirepass 123456
logfile /usr/local/redis/log/redis3.log
dbfilename pointer3.rdb
dir /usr/local/redis/data
appendonly yes
appendfilename appendonly3.aof# 从本机 6379 的 redis 实例复制数据Redis 5.0 之前使用 slaveof
replicaof 8.129.113.233 6379
# 从节点开启只读模式默认
replica‐read‐only yes
# 从节点访问主节点的密码和 requirepass ⼀样
masterauth 1234562.2 启动 Redis
# 启动主
./redis-server /data/redis/master/data/redis.conf
# 启动从
./redis-server /data/redis/slave1/data/redis.conf
# 启动从
./redis-server /data/redis/slave2/data/redis.conf3. 主从复制原理
主从复制分两种主从刚连接的时候进⾏全量同步全量同步结束后进⾏增量同步。 全量同步 - 首次配置完成主从库连接之后 增量同步 - 全量同步结束后 准实时同步 - 主从正常运行期间Append增量数据 准实时同步 - 主从库间网络断开重连。
3.1 全量同步
主从库第一次复制过程大体可以分为 3 个阶段准备阶段即建立连接准备、主库同步数据到从库阶段、发送同步期间增量指令到从库的阶段。
3.1.1 建立连接
这个阶段的主要作用是建立主从之间的连接连接成立之后才能够做数据全量同步。主要包含如下步骤 从节点的配置文件中的 replicaof 配置项中配置了主节点的 ip 和 port 配置完成之后从节点就知道要跟哪个主节点进行连接 当连接成功之后从库开启 replicaof 操作同时发送 psync 指令告诉主库我准备开始同步了。命令包含了主库的 runID 和 复制进度 offset 两个参数 runID每个 Redis 实例启动都会自动生成一个唯一标识 ID第一次主从复制还不知道主库 runID所以参数会默认设置为?offset因为第一次复制没有偏移量所以默认设置为 -1这样就默认从第1条指令开始复制 主库收到 psync 命令后根据参数启动复制使用 FULLRESYNC 响应命令同时带上两个参数主库 runID 和主库目前的复制进度 offset返回给从库 从库收到响应后记录下这两个参数。
3.1.2 主库同步数据给从库 master 执行 bgsave 命令生成 RDB 文件并将文件发送给从库从库收到 RDB 文件后保存到磁盘清空当前 Redis 库中的数据再将 RDB 文件数据加载到内存中。 同时主库为每一个 slave 开辟一块 replication buffer 缓冲区记录用于记录主库生成 RDB 文件后那段时间那段时间的产生的写命令没有被记录到 RDB 文件中但是主库又会源源不断的接收到新的请求指令记录缓冲区是为了保证数据不丢失产生的所有写指令。
3.1.3 发送新写命令到从库 在 主库同步数据给从库 整个初始化工作完成之后继续执行从 replication buffer 缓冲区发送过来的数据避免数据断层。 主数据同步到从库的过程中主库不会被阻塞可以正常处理其他任意操作这也是 Redis 保证高性能的必备条件。 replication buffer 缓冲区创建在 master 主库上存放的数据是下面三个时间内 master 数据的所有写操作。 master 执行 bgsave 生产 rdb 的期间的写操作master 传输 rdb 文件到 slave 期间的写操作slave 加载 rdb 文件将数据初始化到内存期间的写操作。 三个步骤完成了 Redis 主从的全量复制。这边需要注意的是Redis 中的通信无论是主库跟从库之间还是与客户端之间的数据交互。本质上都是通过分配内存 buffer 来进行的Master 会先把数据写到 buffer 中再通过网络发送出去从而完成数据交互。
RDB 文件作为二进制文件无论是网络传输还是写入时的磁盘IO效率都要比 AOF 高很多。同样的从库进行数据恢复的时候效率也会高一些。所以我们会选择 RDB 文件做同步而不是 AOF 模式。
3.2 增量同步
3.2.1 主从网络断开之后的同步方式
在网络断开之后或者从实例服务故障恢复之后主从库会采用增量复制的方式继续同步而不是全量同步的模式这样会大大降低开销提升效率。
增量复制 就是指网络中断或者从库重启等情况后的复制只将中断期间主节点执行的写命令发送给从节点与全量复制相比更加高效。
3.2.2 repl_backlog_buffer
主从库重新连接之后可以实现增量复制。关键就在 repl_backlog_buffer 缓冲区上面。
因为 master 会将写指令操作记录在 repl_backlog_buffer 缓冲区中并使用 master_repl_offset 记录 master 写入的位置偏移量slave 则使用 slave_repl_offset 记录读的偏移量。master 新增写操作的时候偏移量则会增加。从库持续执行同步的写指令后slave_repl_offset 也会不断增加。一般情况下这两个偏移量会保持同步如下图左。
但是网络断开或者从库故障期间主实例 Redis 一般会收到新的写操作命令但从实例则暂停执行所以 master_repl_offset 会大于 slave_repl_offset。如下图右。 需要注意的是 repl_backlog_buffer 并不是如图中显示的貌似无限队列的模式而是一个类似环形数组如果数组内容满了就会从头开始覆盖前面的内容因为给到的内存空间是有限的。 在主从之间重新连接之后slave 会先发送 psync 命令给 master同时将自己的 {runID,slave_repl_offset} 两个参数发送给 master。master 只需要把 master_repl_offset 与 slave_repl_offset 之间的命令同步给从库即可。增量复制的流程类似如下 在配置repl_backlog_buffer 的时候需要综合考虑各种因素太大了会导致增量执行周期比较长还不如RDB全量覆盖。太小了有可能从库还没读取到就被 Master 的新写操作覆盖了那样也只能执行全量复制。
所以我们需要给出一个合理缓冲区size。一般有如下的计算公式共参考repl_backlog_buffer_size seconds * write_size_per_second seconds正常情况下从库断开到重连主库所需的平均时间秒为单位。 write_size_per_second主库平均每秒产生的写命令数据量大小。
如主服务器大约每秒产生 0.5MB 的写指令数据而断开到重连一般需要 30s那么缓冲区的大小就是 0.5 * 30s 15 MB。
但是我们一般会保留一点buffer比如预留 0.5 倍那就是 1.5 * 15 MB 22.5 MB 。
3.2.3 基于长连接的命令传播 上面的工作都是为了完成完整复制那在完成全量复制之后主从开始进入正常有序的同步了具体应该怎么做呢 主从完成全量复制之后他们之间需要保持连接。当主库收到操作指令的时候通过这个连接同步给从库这个过程称之为基于长连接的命令传播。
为了保证传播的有效性和稳定性从节点采用心跳机制进行侦测发送命令PING 和 REPLCONF ACK。
1主 - 从PING
每隔指定的时间比如 1 分钟可配置主节点会向从节点发送 PING 命令侦测从节点有无超时来判断从节点的健康情况。
2从 - 主REPLCONF ACK
命令执行传播的阶段从服务器默认会以每秒一次的频率向主服务器发送命令将复制的偏移量发送过去。
REPLCONF ACK replication_offset
replication_offset 的属性指的是当前从实例服务器的复制偏移量。 从实例发送 REPLCONF ACK 命令对于主要实例主要有以下作用 检测主从服务器的网络通路是否正常。 辅助实现 min-slaves 选项使用 Redis 的 min-slaves-to-write少于n个从实例时拒绝执行写命令 和 min-slaves-max-lag主从延迟大于等于n秒时拒绝执行写命令两个选项可以防止主服务器在不安全的情况下执行写命令。 检测命令丢失, 从节点发送了 slave_replication_offset主节点会对比 master_replication_offset 如果不一致说明从节点数据缺失主节点会从 repl_backlog_buffer 缓冲区中找到并推送缺失的数据。
4. 总结
主从复制的作用一个是为分担读写压力均衡负载另一个是为了保证部分实例宕机之后服务的持续可用性所以 Redis 演变出主从架构和读写分离。
主从复制的步骤包括建立连接的阶段、数据同步的阶段、基于长连接的命令传播阶段。
数据同步可以分为全量复制和部分复制全量复制一般为第一次全量或者长时间主从连接断开。
命令传播阶段主从节点之间有 PING主到从的的探测 和 REPLCONF ACK从到主的ack应答 命令这种互相确认心跳的模式保证数据同步的稳定性。
主从模式是比较低级的可用性优化要做到故障自动转移异常预警高保活还需要更为复杂的哨兵或者集群模式。
