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 全量复制 INFO 和 SLAVOF 命令之外的任何请求都会返回一个错误“SYNC with master in progress”。
当 Replica 失去与Master 的连接时或仍在进行复制时,Replica 可以如下方式起作用:
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 查余票、双十一秒杀的库存,你会发现经常就是前后不一致的数据。因为你查询时得到的数据,就是需要允许写错误。
-
若 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
(编辑:厦门站长网)
【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!
|