饿了么异地多活技术实现（三）GZS&DAL

饿了么技术团队花了1年多的时间，实现了业务的整体异地多活，能够灵活的在多个异地机房之间调度用户，实现了自由扩容和多机房容灾的目标。本文介绍这个项目的中五大核心基础组件中的DAL与GZS，关于项目整体介绍以及其它组件的实现细节可以参考本系列的其它文章。

 

GZS （Global Zone Service：全局状态协调器）

背景

多活改造的一个核心是多活流量路由，来源主要包括三个方面:

• 从ezone外部发起的请求。比如用户下订单，商户添加菜品等等。这个部分的请求由API Router路由到正确的ezone。详情请参考https://zhuanlan.zhihu.com/p/32587960
• 非多活业务调用多活业务。当非多活业务调用多活业务时，需要通过SOA Proxy从ezone内部路由到正确ezone。
• job发起的请求。典型的场景是补偿job，通常是批量拉取符合条件的数据进行业务操作。这种情况需要业务方筛选出本ezone需要处理的数据，各个ezone的job服务只处理自己ezone负责的业务数据。

不仅基础组件依赖多活路由，一些特定的业务也需要获得多活路由，因此必须有一个专门的组件来统一管理多活路由，并且在多活切换时能协调各个模块的工作。

 

多活路由设计

多活路由由三个部分组成，ezone，shardingid，shardingkey。通过这三层路由关系的调整实现了多活的灵活资源调度以及failover。

• ezone，代表的是一个可独立支持完整关键业务的逻辑机房，一般来说应该是在一个物理机房内。
• shardingid，代表的是按地理位置划分出来的逻辑业务分组。一个shardid的业务会被路由到同一个ezone处理。
• shardingkey，代表的是可以被路由的业务相关id，包括商户id，订单id等等。为了减少多活改造对业务的侵入，我们采用了使用自己业务相关id进行多活路由的策略，由GZS来维护这层路由关系。

下图是一个简单的路由例子

一般来说ezone与shardid的关系是比较固定的，而shardingkey会是一个一直变化的状态。shardingkey的路由规则主要由3种类型

• 计算型：比如经纬度。GZS根据地理位围栏计算出所属的shardid，来找到目标ezone。这种类型的shardingkey会有一定的cpu消耗。
• 映射型：比如城市id。每个城市id基本上也是与地理位置绑定的，GZS通过记录一张城市id与shardid的映射表来路由。这种类型的shardingkey会有一定的内存消耗。映射型中有些shardkey总量是不断增长的如商户id。GZS必须实时维护路由关系，保证秒级别的更新。
• 嵌入型：这种类型的shardingkey几乎是最理想的，GZS可以直接根据预先定义的解析方式从shardingkey中得到shardid来做路由。

多活shard切换协议设计

多活切换的原则是：

• 可用性优先：当发生故障切换机房时，优先保证系统可用，首先让用户可以下单吃饭，容忍有限时间段内的数据不一致，再事后修复。每个 ezone 都会有全量的业务数据，当一个 ezone 失效后，其他的 ezone 可以接管用户。用户在一个ezone的下单数据，会实时的复制到其他ezone。
• 保证数据正确：在确保可用的情况下，需要对数据做保护以避免错误，在切换和故障时，如果发现某些订单的状态在两个机房不一致，会锁定该笔订单，阻止对它进行更改，保证数据的正确。

 

shard切换协议如下：

1. GZS将shard1状态从“ACTIVE”转化为“BLOCK”，并路由推送到订阅用户（DAL ApiRouter soaproxy e.g.）
   1. DAL阻止在所有机房相应的shard的所有操作 (直接返回操作失败：1036)
   2. API Router阻止相应shard的全部操作 （相应shard全部不可用）（返回固定错误码：530）
2. GZS将shard1状态从“BLOCK”转化为“RESHARD”，shard1对应ezone从“ezoneA”改变为“ezoneB”，“reshard_at”域为当前时间
   1. DAL阻止在目的机房相应的shard的老数据的更新操作 （update 操作增加一个时间戳的判断条件 created_at > reshard_at）
   2. DAL在其它机房保持阻止
   3. 订阅用户根据新shard-ezone映射路由。
3. GZS 开始倒计时。倒计时结束 或者DRC 通知同步时间到达reshard_at
4. GZS 状态从“RESHARD”转化为“ACTIVE”
   1. DAL解除阻止

下面是一个简单的例子，将shard 1 的下单流量从ezone1切换到ezone2。

设计实现

GZS的设计是紧密联系业务特性的产物。

 

为什么SDK使用订阅推送

由于多活路由查询对于其它多活组件（DAL，APIRouter，soaproxy）来说是个高频操作，远程查询显然不能够胜任。同时对于计算型的shardingkey也不适合在GZS Server做。因此需要把路由信息推送到SDK，来保证查询的高效。

 

路由订阅是全量更新还是增量更新

GZS定义了一套增量更新的协议，适用于所有的多活路由类型。对于映射型的shardingkey使用增量更新，而对于其它类型的shardingkey直接使用全量更新的策略。

 

如何考虑一致性与可用性

如前文介绍的，多活路由是三层结构，对于一致性其实有着不同的要求。对于Sharding Id这层路由有着强一致性的要求，我们一组多活切换步骤来保证一致性。整个过程我们是牺牲可用性的。而对于逻辑Sharding key，嵌入型以及计算型的一致型是和Sharding Id一致的是绑定的。我们唯一需要考虑的是映射型的Sharding Key，对于这种类型主要采用BASE的思想来设计，不强调实时高一致性，而是要求一定时间内达到最终一致性。以店铺ID为例子，当新的店铺添时，GZS保证秒级同步映射关系，中间不同步的状态通过业务使用地理位置路由等方式绕开。

 

GZS 拓扑图

 

DAL（Data Access Layer：数据访问）

背景

DAL是proxy型的数据库中间件，支持mysql协议，在多活项目启动前已经承载了饿了么全部生产mysql流量。在多活项目中，DAL责无旁贷扮演起保护数据正确性最后一道防线的角色。

 

多活DAL兜底

在前文我们提到了多活流量来源，来自ezone外的可以统一通过API Router收口。而来自ezone内部的流量，我们很难确认多活改造是否完成。因此需要在DAL层做兜底，防止多活数据错乱。

DAL多活兜底主要体现在两个部分

Global ezone

多活业务场景中，存在全局配置性的数据，呈现大量读，少量写的特性。针对这种业务，我们提供了global ezone这种解决方案。

这是一种跨机房的读写分离机制。查询走本机房的数据库salve，写全部走一个Master，对业务方来说DB的配置透明的。

DAL可以方便的把业务在各个ezone的服务指向同一个master。当发生failover时，通过DB的主备切换，就可以把mysql的master从一个ezone迁移到另一个ezone。

 

未来的展望

多活切换目前是人工操作的，每次多活切换的决策总要耗费不少的时间。未来我们要把多活切换的过程做到智能化，自动化。

 

文献引用

https://yq.aliyun.com/articles/57715

https://coolshell.cn/articles/10910.html

https://en.wikipedia.org/wiki/CAP_theorem

https://zhuanlan.zhihu.com/p/32009822

https://zhuanlan.zhihu.com/p/32587960

 

作者介绍

林静 ，2011毕业于浙江大学，2015年加入饿了么，现任饿了么框架工具部架构师。