工作场景中的Redis主从不一致

背景

某种类型页面的数据缓存时间是6分钟，上沙盒之后，发现在该类型页面下不同的实际页面的数据有些展现，有些不展现，此外，刚刚展现的同一个页面刷新后数据就不展现了，再刷新又展现了，这些情况持续了40分钟，然而上线后再验数据就没有任何问题，属实有点抽象。

思考

后面看别人提交的代码，发现他们把Redis的前缀key版本号改了，而我当时没有修改。通过修改前缀key版本号，读从节点就读不到缓存，会去读主。不过这会导致该key前缀的缓存全部失效，而且上线的时候也没有做缓存预热，还好流量不大且没有热点key，可以顶住，但存在着一定风险的。

仔细看了下，咱部门用的是云上Redis Cluster，版本4.0，有8个分片，一主一从，单机使用10G内存。为了提高性能，从节点支持读，存在主从不一致的问题。

不过，仔细想一想，其实改了版本号，只是能尽早看到效果，而不能解决主从延迟的问题。主从延迟会让slave读取到旧数据，因为同步是需要时间的。这也是为什么第二天在部分页面上，如果快速刷新几次，还是存在有时候展现数据，有时候不展现数据的情况。

解决方案：

• 优化主从节点间的网络环境
• 监控主从延迟（通过offset判断），如果slave延迟过大，强制读主

从节点同步落后于主节点的可能原因有两个：

1. 主从节点之间的网络延迟
2. 从节点接收到主节点的命令，但由于是单线程，前面正在处理一些耗时的命令（如pipeline批处理），无法及时进行同步。

pipeline批处理指的是，客户端将多个命令一起发送给服务器，等到服务器执行完所有命令，再一起返回给客户端，而不是发一条命令等待返回后再发送下一条命令。通过减少网络交互从而提升性能。

pipeline和lua脚本对比：

• 原子性：lua脚本具有原子性，而pipeline虽然将多个命令一次性传输到服务端，但在服务端执行时仍然是多个命令，不具有原子性。
• 使用场景：lua脚本适合简单的事务场景，pipeline更适合多个命令之间没有关系，不需要原子性，且需要提高程序响应速度的场景。

Redis三种集群都是带着主从的，所以主从延迟是规避不了的，只能尽量减少其影响。