redis知识脑图

参与复制的主从节点都会维护自身的复制偏移量

主从节点维护自身的复制偏移量

复制积压缓冲区是保存在主节点上的一个固定长度的队列，默认大小为
1MB，当主节点有连接的从节点（slave）时被创建，这时主节点（master）
响应写命令时，不但会把命令发送给从节点，还会写入复制积压缓冲区

复制积压缓冲区是先进先出的队列，相关信息在主节点的replication中显示
127.0.0.1:6379> info replication
# Replication
role:master
...
repl_backlog_active:1 // 开启复制缓冲区
repl_backlog_size:1048576 // 缓冲区最大长度
repl_backlog_first_byte_offset:7479 // 起始偏移量，计算当前缓冲区可用范围
repl_backlog_histlen:1048576 // 已保存数据的有效长度

复制积压缓冲区

每个Redis节点启动后都会动态分配一个40位的十六进制字符串作为运
行ID。运行ID的主要作用是用来唯一识别Redis节点，比如从节点保存主节
点的运行ID识别自己正在复制的是哪个主节点。

可以通过info server查看运行id
127.0.0.1:6379> info server
# Server
redis_version:3.0.7
...
run_id:545f7c76183d0798a327591395b030000ee6def9

Redis关闭再启动后，运行ID会随之改变

命令格式：
psync {runId} {offset}
·runId：从节点所复制主节点的运行id。
·offset：当前从节点已复制的数据偏移量。

1、返回全量复制标记，从节点触发全量复制流程
2、返回部分复制标记，从节点触发部分复制流程
3、错误，可能是2.8以下版本不支持psync命令，从节点将发送sync触发全量同步

1、从节点发送psync -1

2、主节点解析发现是全量复制命令，则回复+FULLRESYNC响应

3、从节点接收响应数据并保存运行ID和偏移量offset

4、主节点开始执行bgsave保存RDB文件到本地

5、主节点发送RDB文件给从节点，从节点接收RDB文件并保存作为从节点数据文件

6、在从节点接收RDB快照期间，主节点可以继续响应读写命令，
主节点会把这期间的写命令保存在复制客户端缓冲区内
当从节点加载完RDB后，主节点再把缓冲区内的数据发送给从节点，保证主从之间数据一致性。

7、从节点接收完主节点传过来的全部数据的时候会清空自身旧数据

8、从节点清空数据后会进行加载RDB文件，对于较大的RDB文件这一步是比较耗时的

9、从节点成功加载完RDB后，如果当前节点开启了AOF持久化功能，则会立即开始做bgrewriteaof操作

全量复制是非常耗时费力的操作

子主题

具体步骤

问题：

其中最后cmd应该是说该客户端最后执行的命令

主节点根据replconf命令判断从节点超时时间，体现在info replication统
计中的lag信息中，lag表示与从节点最后一次通信延迟的秒数，正常延迟应
该在0和1之间。如果超过repl-timeout配置的值（默认60秒），则判定从节点
下线并断开复制客户端连接。

因为主从复制是异步操作，所以这是不可平避免的

解决方案：使用集群模式做水平扩展来规避从节点读操作

redis维护了两种过期数据删除策略

客户端维护redis节点列表进行故障切换,使用redis读写分离存在一定成本；
尽量在主节点上进行优化，当主节点优化空间不大时可以考虑使用redis集群模式，这样不止扩展了写性能同时也扩展了读性能

一个主节点挂了多个从节点，针对RDB快照redis做了优化会共享一份RDB文件，
但同时给多个从节点发送数据会加剧主节点机器的网络开销

解决方案

应该把主节点尽量分散在多台机器上，避免在单台机器上部署过多的
主节点。

当主节点所在机器故障后提供故障转移机制，避免机器恢复后进行密
集的全量复制。（比如哨兵模式或者集群模式）

阻塞当前Redis服务器，直到RDB过程完成为止，对于内存
比较大的实例会造成长时间阻塞，线上环境不建议使用。

Redis进程执行fork操作创建子进程，RDB持久化过程由子
进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

显然bgsave是对save命令的优化，save命令已经废弃