mysql 异地双活_饿了么异地双活数据库实战

我今天的分享是饿了么在数据库和多活数据库这块的实战经历，供大家参考。

主要围绕以下五点进行分享：

多活当中的难点

多活的架构

数据库改造

DBA 挑战

收益与展望

多活当中的难点

我们先来看一下多活的第一个难点：要考虑做多活到底是同城的多活还是异地的多活。

跨地域网络延时是现阶段很难突破的点，因为饿了么面临的是异地的多活，所以我们需要基于延时这个前提来考虑方案。

从北京到上海中间有 30 毫秒的延迟，这个会带来什么问题？我们接下来会讲。

上图是同城和异地多活不同的点，复杂性和可拓展性对架构的影响方面会有很大的不同。

我们挑几个点讲一下：

如果只是做同城多活的话，像 30 毫秒的延时不需要考虑，因为同城的延时通常只有几毫秒，跟同机房相差不大。

如果是异地 30 毫秒的延时就需要重点考虑了，因为如果是反复调用的应用，放大的时间就不只是 30 毫秒了，可能是 300 毫秒、500 毫秒，对很多应用来说是不可接受的。

在可扩展性方面如果做的是异地多活的话，你的可扩展性理论上来说没有太多的边界。

我们做同城多活只能在上海机房里面选，如果是异地多活，可能是全国甚至是全球都可以选。

还有一个比较难的问题，就是怎么保证数据的安全？多活数据可能面临多个写入点，可能会错乱、会冲突、循环复制、数据环路等问题。

这种情况下怎么保障一致性？如果这些没有考虑好之前，你是不能上多活方案的，多点写入的风险对数据的考验是很大的。

综合考虑下来我们选择了异地多活，所以这些问题我们都需要克服，也意味着会面临很多的系统改造。

如何解决跨机房延时对业务的影响，包括各种抖动甚至是断网的问题；怎样有效区分我们访问的流量，最大限度地保障用户的访问落在正确的机房，这个都是需要解决的难点。

我们采取了一些措施，如上图：

尽量把业务做成类聚的，让一个用户的访问落在同一个地方。不是所有的业务都有多活特性的，还可以有全局使用的业务(比方用户数据)，所以需要做业务类型划分。

在服务划分这一层，怎么定义业务调用的边界，还有我们基于什么对流量和用户做划分的呢？

目前根据我们的业务特点使用的是地理围栏(POI)，用户、商户、骑手当前所在的地理位置是我们入口流量划分的依据。

再看看路由控制这一块，除了入口流量这一层做了机房的划分，还在内部使用了虚拟的 Shardingkey，ShardingKey 会把全国流量分成多个部分，并且与 POI 标签绑定。

这样就可以把逻辑 ShardingKey 和物理位置对应起来，切换的时候访问就可以随 ShardingKey 分流到不同的机房。

APIRouter 就是为了完成这个工作的，它会根据配置的规则把 Shardingkey 对应的流量分到对应的机房。

脏写预防方面，为防止数据冲突，我们也需要业务配合做一些多活规则的改造，这些规则对业务还是有一些侵入性的。

另外 SOA-Route 就是内部跨业务调用的访问路由；还有一个 DAL，就是数据库的代理层。

业务访问在我们多层的路由控制下，理论上应该能正确路由到合适的机房，如果超越规则或者没有按规则改造的意外流量真正穿透到 DAL 这一层的时候我们是强制拒绝的。

因为底层认为这个访问是属于异常的调用，流量走错了机房，这时候就会拒绝，所以我们宁愿让他失败也不能让控制之外的数据进来，这样才能保障规则和数据的可控性。

数据一致性方面，我们有一个重要的 DRC 数