Redis 异地双活实战

本文主要讲述异地双活方案redis的热备、双写、双向同步的区别和优劣势。并且说明了双写同步方案中redis集群主从数据同步的过程，以及中间件方案遇到的部分问题点，说明最终方案的实现思路和方案。

redis的双活方案无非有以下三种：热备，双写，双向同步。下文会说明三个方案的区别，并着重讲解双向同步的方案。

热备

其中，热备由于备用redis集群平时不会被使用，只有双活故障切换才会使用，且该方案redis备机需要实时数据同步，则切换后的稳定性较低、并且需要同时维护两套集群，成本也不低。两个IDC同连一个redis集群，假如某个IDC距离过大，则必然至少有一个IDC和redis集群距离过大，则该方案的延迟相比原生redis会大大增加（该延迟同redis双写的延迟）。因此在异地双活中基本不会考虑，可做为前期的同城双活方案的过度方案，本文不会详细说明。

双写

双写，顾名思义就是两个机房同时写入，即在双活项目中，一个redis的命令写入本机房redis集群的同时，会同时写入另外一个机房的redis集群。保证两个机房redis数据是一致的。如下图所示：

在我理解中，双写主要分为以下四个方式：同步双写、异步双写、redis集群维度同步双写、redis集群维度异步双写。

同步双写

同步双写，指的是同个redis命令同时写入两个机房，是同步执行的。 

例如：用户发了一个顺风车乘客订单，该订单被路由到中心机房（HZUNIT），且发单成功在业务上需要缓存订单数据到redis中，则该订单会先在中心机房（HZUNIT）写入一条缓存数据，同时会同步写入一条数据到异地的单元机房（SHUNIT）。

该方案存在以下几个问题：

维护成本

假如双写需要在业务代码层面维护，那代码侵入性会非常大。假如双写有个配置页面，配置需要双写的key，由中间件SDK实现双向，则每次新增或者修改双写的key都要去配置页面配置，后期维护中漏配风险非常大。

回滚问题

无论双写是在业务代码层面维护还是中间件SDK维护，那么当本机房操作成功，异地机房操作失败后，业务代码或者中间件代码需要考虑回滚逻辑，是跳过，还是回滚之前的命令，还是重试异地机房写入命令。如果选择重试，那一直失败如何处理，怎么保证数据一致性都是比较大的问题。

延迟

延迟是最致命的，众所周知redis的写入速度是非常高的，通常一个redis命令的写入是1ms以内，但是假如同步双写，则写入异地机房的时长会由两机房的物理距离决定，根据饿了么双活的测算，北京-上海的延迟大约为30ms，那这个异地的延迟是30倍，假设业务原先写入该redis命令的时间是1ms，那双写后变为31ms，显然这是无法接受的。

异步双写

异步双写，指的是同个redis命令写入两个机房，对本机房是同步写入的，对异地机房是异步写入的。 

例如：用户发了一个顺风车乘客订单，该订单被路由到中心机房（HZUNIT），且发单成功在业务上需要缓存订单数据到redis中，则该订单会先在中心机房（HZUNIT）写入一条缓存数据，同时会异步写入一条数据到异地的单元机房（SHUNIT）。

该方案同样存在以下几个问题：

维护成本

与同步双写方案问题一致。

回滚问题

大部分与同步双写方案问题一致，且由于异步，一致性更无法保证。

延迟

该方案由于异地机房是异步写入，因此延迟问题影响几乎没有。（如数据要求强一致，则不适合用异步双写）