Redis -- 复制的原理及优化
Redis主从复制
-
什么是主从复制
-
主从复制配置
-
全量复制和部分复制
-
故障处理
-
开发运维常见问题
Redis单机问题
-
机器故障
-
容量瓶颈
-
QPS瓶颈
主从复制的作用
-
数据副本
-
扩展读性能(读写分离)
主从复制限制
-
主从复制限制一个master(主)可以有多个slave(从)
-
一个slave只能有一个master
-
数据流向是单向的,master到slave
_______________________________________________________________________________________________
两种实现方式
主从复制是不会在一台机子上的
1.slaveof命令
2.配置
1.slaveof命令 (异步的)
取消复制
2.配置
两种方式对比
方式 |
命令 |
配置 |
优点 |
无需重启 |
统一配置 |
缺点 |
不便于管理 |
需要重启 |
主从复制其实依赖RDB文件
___________________________________________________________________
全量复制:
全量同步的工作细节:
master 开启一个后台保存进程,以便于生产一个 RDB 文件。同时它开始缓冲所有从客户端接收到的新的写入命令。当后台保存完成时, master 将数据集文件传输给 slave, slave将之保存在磁盘上,然后加载文件到内存。再然后 master 会发送所有缓冲的命令发给 slave。这个过程以指令流的形式完成并且和 Redis 协议本身的格式相同。
—–Redis中文官方文档
全量复制开销:
1. bgsave时间
2. RDB文件网络传输时间
3. 从节点清空数据时间
4. 从节点加载RDB的时间
5. 可能的AOF重写时间
部分复制:
由于网络抖动等原因主从之间丢失连接,期间存在部分数据的不同步,主节点会将这期间的数据写入一个缓冲队列中,当从节点重新连接上主节点后,主节点判断从节点的offset偏移量是否在该缓冲中,然后将从偏移量开始到队列结束的数据同步给slave (数据丢失最简单的方式是再做一次全量复制,但这么做开销特别大。这在2.8版本之前都是这么做的)
无需磁盘参与的复制
正常情况下,一个全量重同步要求在磁盘上创建一个 RDB 文件,然后将它从磁盘加载进内存,然后 slave以此进行数据同步。
如果磁盘性能很低的话,这对 master 是一个压力很大的操作。Redis 2.8.18 是第一个支持无磁盘复制的版本。在此设置中,子进程直接发送 RDB 文件给 slave,无需使用磁盘作为中间储存介质。
–redis官方文档http://www.redis.cn/topics/replication.html
_________________________________________________________________________________________
故障处理
自动故障转移
slave故障:一主多从的情况,客户端迁移 (从一个slave到另一个slave)
master故障:选择slave成为新的master,客户端迁移
主从复制没有解决真正的故障自动转移
—-> 高可用—->Redis sentinel
开发与运维中的问题
1. 读写分离
master负责写,slaves负责读
可能问题:
- 数据复制的延迟
- 读到过期的数据(master过期数据,slave未同步,redis3.2解决)
- 从节点故障
2. 主从配置不一致
比如maxmemory不一致会产生数据的丢失,从内存小于主内存,淘汰机制丢失数据,
数据结构优化参数:主节点有,从节点没有,造成内存不一致
3. 规避全量复制(带来的开销)
- 第一次全量复制不可避免,,夜间运行,分片。。
- 节点运行ID不匹配(主节点重启等)
- 复制积压缓冲区不足–>增大复制缓冲区配置rel_backlog_size
4. 规避复制风暴
大量的主从复制。
- 单主节点重启
- 单机器复制,机器上有多个节点
主节点分散到多个机器
采用高可用的架构,slave晋升机制