构建跨地域数据迁移之路：Redis异地多活的发展变迁与实践经验分享

为了更好的做好容灾保障，使业务能够应对机房级别的故障，滴滴的存储服务都在多机房进行部署。本文简要分析了 Redis 实现异地多活的几种思路，以及滴滴 Redis 异地多活架构演进过程中遇到的主要问题和解决方法，抛砖引玉，给小伙伴们一些参考。

Redis 异地多活的主要思路

业界实现 Redis 异地多活通常三种思路：主从架构、Proxy双写架构、数据层双向同步架构。

主从架构

主从架构的思路：

1. 各机房的 Redis 通过 Proxy 对外提供读写服务，业务流量读写本机房的 Redis-proxy

2. 主机房里的 Redis-master 实例承担所有机房的写流量

3. 从机房里的 Redis-slave 实例只读，承担本机房里的读流量

主从架构的优点：

• 实现简单，在 Proxy 层开发读写分流功能就可以实现

• Redis 层使用原生主从复制，可以保证数据一致性

主从架构的缺点：

• 从机房里的 Redis-proxy 需要跨机房写，受网络延时影响，业务在从机房里的写耗时高于主机房

• 主机房故障时，从机房的写流量也会失败，需要把从机房切换为主机房，切换 Redis-master

• 网络故障时，从机房的写流量会全部失败，为了保障数据一致性，这种场景比较难处理

Proxy 双写架构  

Proxy 双写架构的思路：

1. 各机房的 Redis 通过 Proxy 对外提供读写服务，业务流量读写本机房的 Redis-proxy

2. 不区分主从机房，每个机房都是独立的 Redis 集群

3. 各机房的读写流量都是访问本机房的 Redis 集群

4. Proxy 层在写本机房成功后，将写请求异步发送到对端机房

Proxy 双写架构的优点：

• 实现简单，在 Proxy 层开发双写功能就可以实现

• 一个机房故障时，其他机房的流量不受影响

• 网络故障时，各机房内部的流量也不受影响

Proxy 双写架构的缺点：

• 不能保证数据一致性，Proxy 异步 write 请求可能会失败，失败丢弃请求后，导致双机房数据不一致

• 假设机房-A的集群先上线，机房-B 后上线，Proxy 双写架构不能支持把机房-A的存量数据同步到机房-B

• 网络故障时，异步 write 会失败后丢弃，网络恢复后，之前失败的数据已经丢弃，导致双机房数据不一致

  <