大众点评账号业务异地双活方案

异地多活

除了柔性可用，还有一种思路可以来延长不出故障的时间，那就是做冗余，冗余的越多，系统的故障率就越低，并且是呈指数级降低。不管是机房故障，还是存储故障，甚至是网络故障，都能依赖冗余去解决，比如数据库可以通过增加从库的方式做冗余，服务层可以通过分布式架构做冗余，但是冗余也会带来新的问题，比如成本翻倍，复杂性增加，这就要衡量投入产出比。

目前美团的数据中心机房主要在北京上海，各个业务都直接或间接的依赖账号服务，尽管公司内已有北上专线，但因为专线故障或抖动引发的账号服务不可用，间接导致的业务损失也不容忽视，我们就开始考虑做跨城的异地冗余，即异地多活。

3.1 方案设计

首先我们调研了业界比较成熟的做法，主流思路是分set化，优点是非常利于扩展，缺点是只能按一个维度划分。比如按用户ID取模划分set，其他的像手机号和邮箱的维度就要做出妥协，尤其是这些维度还有唯一性要求，这就使得数据同步或者修改都增加了复杂度，而且极易出错，给后续维护带来困难。考虑到账号读多写少的特性（读写比是350:1），我们采用了一主多从的数据库部署方案，优先解决读多活的问题。

Redis如果也用一主多从的模式可行吗？答案是不行，因为Redis主从同步机制会优先尝试增量同步，当增量同步不成功时，再去尝试全量同步，一旦专线发生抖动就会把主库拖垮，并进一步阻塞专线，形成“雪崩效应”。因此两地的Redis只能是双主模式，但是这种架构有一个问题，就是我们得自己去解决数据同步的问题，除了保证数据不丢，还要保证数据一致。

另外从用户进来的每一层路由都要是就近的，因此DNS需要开启智能解析，SLB要开启同城策略，RPC已默认就近访问。

总体上账号的异地多活遵循以下三个原则：

1. 北上任何一地故障，另一地都可提供完整服务。
2. 北上两地同时对外提供服务，确保服务随时可用。
3. 两地服务都遵循BASE原则，确保数据最终一致。

最终设计方案如下：

异地多活架构图

3.2 数据同步

首先要保证数据在传输的过程中不能丢，因此需要一个可靠接收数据的地方，于是我们采用了公司内部的MQ平台Mafka（类Kafka）做数据中转站。可是消息在经过Mafka传递之后可能是乱序的，这导致对同一个key的一串操作序列可能导致不一致的结果，这是不可忍受的。但Mafka只是不保证全局有序，在单个partition内却是有序的，于是我们只要对每个key做一遍一致性散列算法对应一个partitionId，这样就能保证每个key的操作是有序的。

但仅仅有序还不够，两地的并发写仍然会造成数据的不一致。这里涉及到分布式数据的一致性问题，业界有两种普遍的认知，一种是Paxos协议，一种是Raft协议，我们吸取了对实现更为友好的Raft协议，它主张有一个主节点，其余是从节点，并且在主节点不可用时，从节点可晋升为主节点。简单来说就是把这些节点排个序，当写入有冲突时，以排在最前面的那个节点为准，其余节点都去follow那个主节点的值。在技术实现上，我们设计出一个版本号（见下图），实际上是一个long型整数，其中数据源大小即表示节点的顺序，把版本号存入value里面，当两个写入发生冲突的时候只要比较这个版本号的大小即可，版本号大的覆盖小的，这样能保证写冲突时的数据一致性。

写并发时数据同步过程如下图：

这种同步方式的好处显而易见，可以适用于所有的Redis操作且能保证数据的最终一致性。但这也有一些弊端，由于多存了版本号导致Redis存储会增加，另外在该机制下两地的数据其实是全量同步的，这对于那些仅用做缓存的存储来说是非常浪费资源的，因为缓存有数据库可以回源。而账号服务几乎一半的Redis存储都是缓存，因此我们需要对缓存同步做优化。

账号服务的缓存加载与更新模式如下图：

我们优化的方向是在缓存加载时不同步，只有在数据库有更新时才去同步。但是数据更新这个流程里不能再使用delete操作，这样做有可能使缓存出现脏数据，比如下面这个例子：

我们对这个问题的解决办法是用set（若key不存在则添加，否则覆盖）代替delete，而缓存的加载用add（若key不存在则添加，否则不修改），这样能保证缓存更新时的强一致性却不需要增加额外存储。考虑到账号修改的入口比较多，我们希望缓存更新的逻辑能拎出来单独处理减少耦合，最后发现公司内部数据同步组件Databus非常适用于该场景，其主要功能是把数据库的变更日志以消息的形式发出来。于是优化后的缓存模式如下图：

从理论变为工程实现的时候还有些需要注意的地方，比如同步消息没发出去、数据收到后写失败了。因此我们还需要一个方法来检测数据不一致的数量，为了做到这点，我们新建了一个定时任务去scan两地的数据做对比统计，如果发现有不一致的还能及时修复掉。

项目上线后，我们也取得一些成果，首先性能提升非常明显，异地的调用平均耗时和TP99、TP999均至少下降80%，并且在一次线上专线故障期间，账号读服务对外的可用性并没有受影响，避免了更大范围的损失。