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

本文根据 GOPS2017·上海站演讲《饿了么异地双活数据库实战》整理发布

作者简介：

虢国飞，饿了么 DBA负责人

从事数据库行业10+年，专注于MySQL、PgSQL、MSSQL等数据库领域的管理、研究和平台的研发等工作，目前负责饿了么数据库团队的管理和数据库维护方面的工作。

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

主要分享以下五点：

1、多活当中的难点

2、多活的架构

3、数据库改造

4、DBA 挑战

5、收益与展望

一、多活当中的难点
我们先来看一下多活的第一个难点：要考虑做多活到底是同城的多活还是异地的多活，跨地域网络延时是现阶段很难突破的点，因为饿了么面临的是异地的多活，所以我们需要基于延时这个前提来考虑方案。

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

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

我们挑几个点讲一下：

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

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

在可扩展性方面如果做的是异地多活的话，你的可扩展性理论上来说没有太多的边界。我们做同城多活只能在上海机房里面选，如果是异地多活，可能是全国甚至是全球都可以选。

还有一个比较难的问题，就是怎么保证数据的安全。多活数据可能面临多个写入点，可能会错乱、会冲突、循环复制、数据环路等问题，这种情况下怎么保障一致性。如果这些没有考虑好之前，你是不能上多活方案的，多点写入的风险对数据的考验是很大的。

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

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

我们采取了一些措施：

1、尽量把业务做成类聚的，让一个用户的访问落在同一个地方。

2、不是所有的业务都有多活特性的，还可以有全局使用的业务（比方用户数据），所以需要做业务类型划分。

在服务划分这一层怎么定义业务调用的边界，还有我们基于什么对流量和用户做划分的呢，目前根据我们的业务特点使用的是地理围栏（POI），用户、商户、骑手当前所在的地理位置是我们入口流量划分的依据。

再看看路由控制这一块，除了入口流量这一层做了机房的划分，还在内部使用了虚拟的Shardingkey，ShardingKey会把全国流量分成多个部分，并且与POI标签绑定，这样就可以把逻辑ShardingKey和物理位置对应起来，切换的时候访问就可以随ShardingKey分流到不同的机房。APIRouter就是为了完成这个工作的，它会根据配置的规则把Shardingkey对应的流量分到对应的机房。

脏写预防方面，为防止数据冲突，我们也需要业务配合做一些多活规则的改造，这些规则对业务还是有一些侵入性的。另外SOA-Route就是内部跨业务调用的访问路由。还有一个DAL，就是数据库的代理层。

业务访问在我们多层的路由控制下，理论上应该能正确路由到合适的机房，如果超越规则或者没有按规则改造的意外流量真正穿透到DAL这一层的时候我们是强制拒绝的，因为底层认为这个访问是属于异常的调用，流量走错了机房，这时候就会拒绝。所以我们宁愿让他失败也不能让控制之外的数据进来，这样才能保障规则和数据的可控性。

数据一致性方面我们有一个重要的DRC数据同步组件，数据库这块有一些自增的控制，DBA还研发了一个数据一致性校验的工具（后面会介绍）。

二、多活的架构

粗略过了多活的一些难