共计 1233 个字符，预计需要花费 4 分钟才能阅读完成。
为什么要有主从复制，使 redis 具备高可用性！
多机状况下主从复制
同步文件和同步命令
同步文件
- 客户端发送命令 slaveof 给从服务器
- 从服务器发送 sync 命令给主服务器，主服务器收到当前，会执行 bgsave 命令 生成 rdb 文件，同时会应用缓冲区保留从当初开始执行的所有命令
- 主服务器发送 rdb 文件给从服务器，从服务器同步状态，主服务器还会同步缓存区内的执行命令给从服务器
同步命令流传
当主从首次同步齐全量数据后，此时主从数据是统一的，然而主服务器是能够始终接受命令的，所以主服务器执行完本人的命令，也须要发送雷同的命令给从服务器的，来保障主从服务器的数据统一。
旧版，新版复制性能比照
旧版复制流程（redis2.8 版本之前）
首先复制分两种：首次复制和断线复制
首次复制没什么好说的，就是利用从服务器发送 sync 命令 拿到 rdb 文件来同步本身的数据库数据，因为首次复制，从服务器是没有任何数据的，这也是最快最无效的办法。
断线复制：能够设想下，当在执行命令流传时，因为网络的起因，流传失败，从服务器重连主服务器的过程中，如果主服务器有新的命令须要执行时，那从服务器必然会失落掉一些命令，也就是导致主从数据不统一的状况，而这时当从服务器重连胜利后，就会向主服务器发送 sync 命令去从新同步主服务器的数据，这样就能达到主从服务器数据统一了。
弊病
每次主从断连，主服务器都要执行 bgsave 命令保留快照数据，十分耗内存，而从服务器也要复原数据 cpu 也会回升。
新版复制流程
主服务器内会有一个数据的偏移量，当发送流传命令时，偏移量会随着发送的数据字节减少，而从服务器接管到命令后，之胜利后，也会将本身的偏移量减少，失常状况下主从服务器的偏移量是统一的。
最大的变动：断线重连后，会依据 offset 偏移量是不是处于复制积压缓冲区 ,runId 判断是否是局部复制还是全量复制，缩小复制的数据量。客户端发送的命令不是 sync，而是 psync.
局部同步性能的实现三个局部组成：
- 主从服务器的复制偏移量
- 主服务器的复制积压缓冲区 (固定长度的先进先出队列)
- 服务器的运行 id(runId)（服务器的惟一标识）
主从建设连贯的过程
心跳检测
从服务器会默认以每秒的频率，向主服务器发送命令 replconf ack <reolication_offset>
reolication_offset 是从服务器的复制偏移量
作用：
- 检测主从服务器的网络连接状态
- 辅助实现 min-slaves
- 查看命令失落
检测主从服务器的网络连接状态
命令 info replication 查看最近一次从服务器向主服务器发送 replconf ack 命令间隔当初过了多少秒
辅助实现 min-slaves
查看命令失落
小记
- 为什么要读写拆散？
防止资源竞争，减少开销
- 造成主从关系命令 (5.0 之后，replicaof;5.0 之前，salveof;）
- 主从级联模式分担全量复制时主库的压力
总结：学习主从连贯过程，以及主服务器通过什么条件来判断进行局部复制还是全量复制。
本文由 mdnice 多平台公布