redis replication完整流运行程

1.master全量复制过程

1. 配置文件保存了master的host和ip
2. slave内部定时任务，每秒check是否有master要连接，有就发起socket连接
3. master如果配置了requirepass,slave需要发送masterauth过去来验证身份
4. master全量复制
5. 每次master收到新数据异步发送给slave

2.master run_id的作用

slave保存了master的run_id,当master的runid由于故障恢复产生了变化，slave检测到变化后，放弃增量复制和异步复制，而是重新全量复制。因为这个时候主从大量的数据是不一致的。

某刻，master发现了错误，于是使用了10小时前的冷备代替了现有数据，数据量改为了80w条。
完成替换之后，master的run_id也发生了变化，slave不能再在现有基础上同步数据，offset也没有意义了。
于是只能全量复制。

3.offset和backlog

master 和 slave 中都一直记录着对方的offset，才能知道互相之间的数据不一致的情况。
backlog是防止给slave全量复制过程中 中途网络中断，为了断点续传，在复制rdb时也会写入backlog一份。

4.psync

slave使用psync从master节点复制，发送命令 psync run_id offset
master会根据自身情况返回响应，run_id不一致则全量复制，fullResync run_id offset
run_id一致则触发增量复制， continue

5.全量复制

1.master bgsave 生成rdb文件，同时所有的写命令缓存到内存中.
    当内存缓冲区超过一定限额，说明此时写频繁，不适合全量复制主从同步，因此会复制失败。
2.master给slave发送rdb文件，同时slave保存了rdb之后，缓冲区的写命令也发送过来。
3.slave收到rdb时写入磁盘，此时仍用旧数据对外提供服务，接着将rdb加载进内存，旧数据清空。
    若开起了AOF，则立即基于当前内存重写aof,BGREWRITEAOF

6.增量复制

全量复制过程中，master-slave网络如果中断，slave重连，触发增量复制。
通过slave发送来的offset,从自己的backlog中找到应该断点续传的数据，发送给slave。

7.heartbeat

master和slave之间互相发送心跳确认存活。
master每10秒发送一次，slave每秒发送一次。

8.异步复制

master每次收到写命令，先在内部写入data,然后异步发给salve.