专注收集记录技术开发学习笔记、技术难点、解决方案
网站信息搜索 >> 请输入关键词:
您当前的位置: 首页 > 数据库

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

发布时间:2010-05-20 14:01:29 文章来源:www.iduyao.cn 采编人员:星星草
饿了么异地双活数据库实战

点击有惊喜


阿里云幸运券分享给你,用券购买或者升级阿里云相应产品会有特惠惊喜哦!把想要买的产品的幸运券都领走吧!快下手,马上就要抢光了。

 

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

主要分享以下五点:

1、多活当中的难点

2、多活的架构

3、数据库改造

4、DBA 挑战

5、收益与展望

一、多活当中的难点

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

19b1a88821da12bf8a98e8a17a52e8e34ba9cbe6

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

7af8e707ae0b3c47019a3ade7fdd5235edbfb04a

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

我们挑几个点讲一下:

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

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

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

07c44eb334520775555c48d60d10587084b5362c

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

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

32c272d328f3f56cc24f717a7228abcdbcfbda4f

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

我们采取了一些措施:

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

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

e8eb9f5095583b66b562065a1d99c437c267bc1e

  • 在服务划分这一层怎么定义业务调用的边界,还有我们基于什么对流量和用户做划分的呢,目前根据我们的业务特点使用的是地理围栏(POI),用户、商户、骑手当前所在的地理位置是我们入口流量划分的依据。
  • 再看看路由控制这一块,除了入口流量这一层做了机房的划分,还在内部使用了虚拟的Shardingkey,ShardingKey会把全国流量分成多个部分,并且与POI标签绑定,这样就可以把逻辑ShardingKey和物理位置对应起来,切换的时候访问就可以随ShardingKey分流到不同的机房。APIRouter就是为了完成这个工作的,它会根据配置的规则把Shardingkey对应的流量分到对应的机房。
  • 脏写预防方面,为防止数据冲突,我们也需要业务配合做一些多活规则的改造,这些规则对业务还是有一些侵入性的。另外SOA-Route就是内部跨业务调用的访问路由。还有一个DAL,就是数据库的代理层。
  • 业务访问在我们多层的路由控制下,理论上应该能正确路由到合适的机房,如果超越规则或者没有按规则改造的意外流量真正穿透到DAL这一层的时候我们是强制拒绝的,因为底层认为这个访问是属于异常的调用,流量走错了机房,这时候就会拒绝。所以我们宁愿让他失败也不能让控制之外的数据进来,这样才能保障规则和数据的可控性。
  • 数据一致性方面我们有一个重要的DRC数据同步组件,数据库这块有一些自增的控制,DBA还研发了一个数据一致性校验的工具(后面会介绍)。

二、多活的架构

fb6514b9ec94fc44697a7411a02bae7287e5f6f4

粗略过了多活的一些难点和我们的应对方案后,我们现在来看一下整个多活的架构。这个上面是我们从入口流量、分流控制、数据多机房同步,包括各个重要组件的架构等。还有里面有globol zone这一项,它是我们刚刚讲的需要全局依赖的业务会把它放在globol zone里面。

d0664009a9e817545e6cc39f34a128e3ced73167

DRC这是做多活时相当重要的组件,主要解决数据在多个机房当中的同步复制。我们从北京机房写入的数据,会同步到上海的机房。上海的机房写入的数据也会通过DRC这个组件同步到北京的机房。大家可以看它其实包含三块服务,Replicator、Applier和Manager,一个收集变更数据、一个将变更数据写入到另一个机房,另外一个是做管理控制。

e978a6f04c1f48971be737c1fe04e671a64bb383

DB架构这块我们有两类(准确讲还有一类是多推的,比较少),第一类是ShardingZone,不管是数据写入还是访问都是本机房提供,出问题的时候也只是流量的切换,并不涉及到底层的变动,这个是真正多活的架构。

还有一种是刚刚讲的,有些没有办法做业务分区的,是globolZone的架构,写是集中在一个机房,读在本地机房完成。大家可能会想到globalzone这种架构会天然面临一些刚刚讲的数据延迟的问题,所以这块我们的定义是一些写入量不大,访问量大,对数据延时是不那么敏感的业务就可以放到这里面来。

三、数据库改造

 

点击有惊喜

 

友情提示:
信息收集于互联网,如果您发现错误或造成侵权,请及时通知本站更正或删除,具体联系方式见页面底部联系我们,谢谢。

其他相似内容:

热门推荐: