标签：同步 slave Redis 主从 master 玩转 节点
前文回顾
建议前面文章没看过的同学先看下前面的文章：
「老司机带你玩转面试（1）：缓存中间件 Redis 基础知识以及数据持久化」
「老司机带你玩转面试（2）：Redis 过期策略以及缓存雪崩、击穿、穿透」
Redis 主从模式
在生产环境使用 Redis ，完全禁止使用单机模式，单机模式风险太高，一台机器出于某些原因挂掉，就会导致整个缓存服务死掉，所以，我们需要使用多台机器来保证 Redis 的高可用，同时也顺便提升了并发性。
对于 Redis 缓存而言，更常见的应用场景是支持读高并发，而写高并发的场景相对比较少（不能说没有，只能说相对读高并发比较少）。
因此，使用主从模式，一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。
经典的主从模式架构图如下：
主从同步策略：
master 和 slave 刚刚连接的时候，进行全量同步。全量同步结束后，进行增量同步。
当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。
全量同步：
master 执行 BGSAVE 命令，生成一个 RDB 文件， 发送给 slave ， slave 加载 RDB 文件达到与 master 维持一致。
- slave 连接 master 后，发送 SYNC 命令。
- master 接收到 SYNC 命名后，开始执行 BGSAVE 生成 RDB 文件，并使用缓冲区记录此后执行的所有写命令。
- master BGSAVE 执行完后，向所有 slave 发送快照文件，并在发送期间继续记录被执行的写命令。
- slave 收到快照文件后丢弃所有旧数据，载入收到的快照。
- master 快照发送完毕后开始向 slave 发送缓冲区中的写命令。
- salve 完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令。
- 第一次全量同步完成。
增量同步
Redis 增量复制是指 slave 初始化后开始正常工作时 master 发生的写操作同步到 slave 的过程。
增量复制的过程主要是 master 每执行一个写命令就会向 slave 发送相同的写命令，从服务器接收并执行收到的写命令。
心跳信息
主从节点互相都会发送心跳信息。
master 默认每隔 10 秒发送一次心跳信息，slave 每隔 1 秒发送一个心跳信息。
注意点：
- Redis 使用异步的方式将数据从 master 节点复制到 slave 节点，slave 会周期性地确认自己每次复制的数据量。
- slave 做复制的时候，不会 block master 正常工作。
- slave 做复制的时候，也不会 block 自己当前的查询工作，只是查询的时候依然会使用旧数据，等到复制完成后，需要删除老数据加载新数据的时候才会 block 当前的查询工作。
- slave 主要用来做横向扩容，提升读的吞吐量，一定程度上做到了读的高可用。
- slave 不一定要连接到 master ，也可以 slave 连接到 slave 。
- slave 不会处理过期 key ，只会等待 master 过期 key。如果 master 过期了一个 key，或者通过 LRU 淘汰了一个 key，那么会模拟一条 del 命令发送给 slave。
无磁盘化主从复制
master 节点可以在内存中直接创建 RDB 文件，然后将 RDB 文件直接发送给 salve 节点，不在自己本地落地到磁盘，这个操作只需要在配置文件中开启 repl-diskless-sync yes 。
但是这样做的风险会比较高，因此，强烈建议在 master 上开启持久化服务。
如果一定要在 master 节点上设置不开启持久化，请在确保 Redis 实例不会自动重启。
为啥要确保实例不会自动重启？
下面给大家分享一个案例，这是生产环境真实发生过的事情，都是血的教训。
一个主从结构的 Redis 集群，当 master 没有配置开启数据持久化，某个时间，突然 master 节点宕机，然后自动重启，当 master 节点自动重启后，由于没有开启数据持久化，这时的 master 节点中是无数据的，当 salve 节点进行数据同步的时候，会把 salve 节点的数据也做清空操作。这时，整个主从结构的 Redis 集群全都没有数据，大量的请求过来发现 Redis 没有数据，导致请求落到了 DB 上，结果是毁灭性的。
主从模式存在的问题是，它仅仅只做到了读高可用，如果一旦 master 节点挂掉了，就没办法写数据了，只剩下 slave 节点还能读数据，但是数据同步也没有了，只能靠人工干预进行恢复，这并不是我们想要的高可用。
我们还需要写高可用，这就引出了 Redis 的高可用架构：哨兵模式。
简单来讲，哨兵模式就是在 master 节点不可用后，可以自发的进行主备切换，或者叫做故障转移。
master 节点在发生故障后，整个集群可以自动检测，将某个 salve 自动切换成 master 节点，这种模式才算是实现了 Redis 真正意义上的高可用。
参考
https://www.cnblogs.com/daofaziran/p/10978628.html
标签：同步,slave,Redis,主从,master,玩转,节点 来源： https://www.cnblogs.com/babycomeon/p/13303612.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。