Redis跨机房双活实战分享，配置细节和遇到的坑总结

这次分享主要基于我们公司实际做Redis跨机房双活的经历，我们有两个数据中心，一个在北京，一个在上海，最开始，业务都在北京，上海是备用的，数据从北京同步过去，有延迟，后来上海的业务也发展起来了，需要能直接在上海读写数据，所以才决定搞双活,就是两个机房都能读写。

技术选型和核心配置

我们调研后，选择了Redis Cluster + 自研代理网关的方案，没有用Redis官方的Redis Cluster跨机房方案，主要是因为官方方案在网络分区（比如机房之间网络断了）时的表现不太符合我们的需求,怕丢数据。

核心配置细节：

1. Redis集群搭建： 我们在北京和上海两个机房各自独立部署了一套Redis Cluster，也就是说，每个机房内部有完整的主从节点，保证单个机房内部的高可用,这是基础。
2. 关键点：双向数据同步。 这是双活的核心，我们使用了阿里云开源的 RedisShake 工具（来源：阿里云开源项目RedisShake），它就像一个数据搬运工，可以实时监听一个Redis实例的变更，然后几乎实时地同步到另一个Redis实例。
   • 配置方式： 我们部署了两条单向同步链路，一条“北->上”链路，监听北京集群的写操作，同步到上海集群；另一条“上->北”链路，监听上海集群的写操作，同步到北京集群,这样就成了双向同步。
   • RedisShake 是基于Redis的复制协议解析的，所以支持各种命令（SET, DEL, HSET等）,能保证数据最终一致。
3. 应用如何读写：双活代理网关。 应用不能直接连接任意一个Redis集群，因为那样会乱套，我们自研了一个轻量的代理网关（类似一个简单的Redis代理服务器），部署在每个机房。
   • 写规则： 应用的所有写请求，都发给本机房的网关，网关收到后，首先写入本机房的Redis集群，然后由RedisShake负责同步到对端机房。核心原则是“本机房写优先”,避免跨机房写带来的高昂延迟。
   • 读规则： 应用的读请求也发给本机房网关，网关直接读取本机房的Redis集群,这样读的性能最好。
4. 数据冲突处理： 双活最大的难题就是冲突，同一个key，在北京和上海被同时修改了，听谁的？
   • 我们的策略： 我们采用了“最后写入胜利”的策略。RedisShake 在同步数据时，会覆盖对端机房的老数据，这意味着，哪个机房的写命令后到达同步工具，哪个机房的数据就是最终值，这可能会丢数据，但对我们的业务来说，可以接受，为了减少冲突，我们在业务设计上做了规避，比如用户数据按地域划分，北方用户的数据主要由北京机房处理，南方用户的数据主要由上海机房处理,从源头上减少同时写一个key的概率。

遇到的坑和总结

1. 网络抖动导致同步延迟堆积（最大的坑）： 机房之间的专线网络不是100%稳定的，偶尔会有抖动，比如延迟突然从20ms飙升到500ms，甚至短暂断开几秒，这时候，RedisShake 的同步速度就会跟不上北京的写入速度，导致待同步的数据在缓冲区里越积越多，一旦堆积起来，即使网络恢复了，追数据也要花很长时间,这段时间两个机房的数据不一致会非常严重。

   • 解决办法： 我们加强了监控，对RedisShake的同步延迟和堆积量设置了尖锐告警，一旦发现延迟变大，立即排查网络问题，我们优化了RedisShake的部署和参数，比如加大缓冲区，提高并发同步线程数，让它能更快地“追”上数据。

2. 循环同步的陷阱： 刚开始测试时，我们差点掉进这个坑，想象一下：北京写了一条数据，同步到上海；上海的RedisShake监听到这条新数据（以为是上海本地产生的），又把它同步回北京…… 这就死循环了！

   • 解决办法： 幸好RedisShake有这个功能，我们在配置同步任务时，启用了“伪客户端”过滤功能（来源：RedisShake文档），简单说，就是让RedisShake能识别出哪些数据变更是由另一个同步任务产生的，如果是，就忽略掉，不进行同步,从而切断了循环链。

3. 故障切换的复杂性： 当某个机房真的整体宕机时，切换流程并不简单，比如上海机房全挂了,我们需要：

   • 立刻切断“北->上”的同步链路,防止北京集群因为同步失败而受影响。
   • 修改代理网关的配置，让所有流量（包括原本上海机房的流量）都指向北京的网关和Redis集群。
   • 这个过程需要自动化脚本和严格的人工检查，否则容易出错,我们进行了多次演练。

4. 监控变得极其重要： 双活之后，监控维度多了很多，不仅要监控每个Redis集群本身的CPU、内存、慢查询，更要重点监控：双向同步的实时延迟（毫秒级）、同步状态（是否正常）、网络质量（丢包率、延迟），任何一个指标异常,都可能意味着数据不一致正在发生。

Redis跨机房双活能显著提升业务的容灾能力和异地用户的访问体验，但它不是一个“开箱即用”的功能，背后有很高的复杂度和运维成本，核心在于解决好双向同步和数据冲突，最大的挑战往往不是Redis本身，而是网络以及运维这套复杂系统的能力，上马之前，一定要评估业务是否真的需要,并做好充分的技术储备和测试演练。