点击上方“JavaEdge”，关注公众号
1 重启和故障转移后的部分重同步
Redis 4.0 开始，当一个实例在故障转移后被提升为 master，它仍能与旧 master 的 Replica 进行部分重同步。为此，Replica 会记住旧 master 的旧 replication ID 和复制偏移量，因此即使询问旧的 replication ID，也可以将部分复制缓冲提供给连接的 Replica 。
但升级的 Replica 的新 replication ID 将不同，因为它构成了数据集的不同历史记录。例如，master 可以返回可用，并且可以在一段时间内继续接收写命令，因此在被提升的 Replica 中使用相同的 replication ID 将违反 一对复制标识和偏移对只能标识单一数据集 规则。
Replica 在关机并重启后，能够在 RDB 文件中存储所需信息，以便与 master 进行重同步。这在升级的情况下很有用。当需要时，最好使用 SHUTDOWN 命令执行 Replica 的保存和退出操作。
2 主从数据不一致
很显然，这是由于主从网络延时。
2.1 主多从少
部分重同步。可通过命令 PSYNC master_run_id offset 执行。
2.2 主少从多
全量复制，覆盖。这种情况是因为 Replica 是读写模式，因此：
关闭 Replica 的读写模式
或删除 Replica 的数据，重新从 Master 全量复制
3 数据延迟
编写外部程序监听主从节点的复制偏移量，延迟较大时发出报警或通知客户端，切换到 Master 或其他节点。
设置 Replica：
slave-serve-stale-data = no除 INFO 和 SLAVOF 命令之外的任何请求都会返回一个错误“SYNC with master in progress”。
当 Replica 失去与Master 的连接时或仍在进行复制时，Replica 可以如下方式起作用：
若
replica-serve-stale-data为 yes（默认值），则 Replica 仍会回复客户端请求，可能带有过期数据，或者说，若这是第一次同步，则数据集可能只是空的![]()
若将
replica-serve-stale-data设为no，则该 Replica 将对除以下信息以外的所有命令返回错误“SYNC with master in progress”：INFO，REPLICAOF，AUTH，PING，SHUTDOWN，REPLCONF，ROLE，CONFIG ，SUBSCRIBE，UNSUBSCRIBE，PSUBSCRIBE，PUNSUBSCRIBE，PUBLISH，PUBSUB，COMMAND，POST，HOST和LATENCY
4 脏数据
4.1 脏数据产因
4.1.1 Redis 删除策略
因为读到了过期数据，而读到过期数据就是 Redis 删除策略所导致的：
惰性删除
Master 每次读取命令时都会检查K是否超时，若超时，则执行 del 命令删除K，之后异步把 del 命令同步给 Replica，即可保证数据复制的一致性。切记 Replica 永远不会主动去删除超时数据。
定时删除
Redis 的 Master 在内部有定时任务，会循环采样一定数量的K，当发现采样K过期，会执行 del，之后再同步给每个 Replica。
主动删除
当前已用内存超过 maxmemory 限定时，触发主动清理策略。主动设置的前提是设置了 maxMemory 的值 注：如果数据大量超时，master 节点采样速度跟不上过期的速度，而且 master 节点没有读取过期键的操作，那 slave 节点是无法收到 del 命令的，这时从节点上读取的数据已经是超时的了。
4.1.2 从节点可写
如果从节点（默认读模式）是读写模式，可能误写入从节点的数据，后期就会成为脏数据。
4.2 解决方案
4.2.1 忽略
比如 12306 查余票、双十一秒杀的库存，你会发现经常就是前后不一致的数据。因为你查询时得到的数据，就是需要允许写错误。
4.2.2 选择性强制读主
但是真正下单扣库存时，你就必须确保数据的正确性 选择强制读 master，slave间接变为备份服务器（某个业务）。
4.2.3 从节点只读
防止 slave 写入脏数据。
4.2.4 Redis自身优化
Redis3.2 版本解决了 Redis 删除策略导致的过期数据，在此版本中 slave 读数据前，会检查K过期时间，以决定是否返回数据。
5 数据安全性
5.1 关闭主节点持久化
为提升Redis性能，一般会关闭 Master 持久化的功能（这样所有数据都会持久化在 slave），因为主从同步时，Master 都会 bgsave rdb。但这样也会带来复制的安全性问题。
在使用 Redis 复制功能时的设置中，推荐在 master 和在 slave 中启用持久化。当不可能启用时，例如由于非常慢的磁盘性能而导致的延迟问题，应该禁用主节点自动重启功能。
风险场景
关闭 Master 的持久化设置，Replica1 和 Replica2 从 Master 复制数据。Master 只有内存数据，没有磁盘数据了。
当 Master 宕机，由于自动重启机制重启了，但重启后由于持久化被关闭了，Master数据集为空！
重启后的 Master，发现 runId 发生变化，也会重新和从节点建立连接，两个从节点会发起复制请求，从Master 复制数据，但 Master 此时数据集为空，因此复制的结果是它们会销毁自身之前的数据副本而变成空数据集。
![]()
5.1.1 解决方案
牺牲性能，开启 Master 的持久化功能。
为了性能，依旧选择关闭，那就让主节点不自动重启，比如不要有Docker或脚本等自动重启机制。
往期推荐
目前交流群已有 800+人，旨在促进技术交流，可关注公众号添加笔者微信邀请进群
喜欢文章，点个“在看、点赞、分享”素质三连支持一下~
本文分享自微信公众号 - JavaEdge（Java-Edge）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。