首页 » 设计与架构 » 正文

异地多活数据中心之随笔

昨天,支付宝的一个主要机房的光缆被挖断,支付宝的工程师们用了几个小时的时间切到了异地多活的其他机房,虽然,一直以来对支付宝的工程师们的技术水平非常的认可,但是几个小时的切换时间有些让人失望,因此,找到了几篇之前看过的异地多活的文章,重新温习了一下,看看为啥支付宝的大牛们遇到这类问题几个小时才能搞定呢?

下面两篇文章分别介绍淘宝和新浪微博的异地双活架构:

1. 专访阿里巴巴毕玄:异地多活数据中心项目的来龙去脉
2. 微博“异地多活”部署经验谈

通过阅读这两篇文章,我们可以总结一些基本的知识:

模式

1. 灾备 – 也就是冷备份,类似数据库的冷备份一样,每个在线的数据中心都对应一个冷备数据中心,无论是数据库,缓存,消息队列,以及前端机,都是需要冷备份,加入主数据中心发生灾难,可以完全切到备份数据中心。

优点是实现简单,缺点是资源利用率低,假如主数据中心按照平时峰值的2倍冗余流量预留的话,备数据中心按照峰值流量来预留,需要峰值的三倍容量,另外一个缺点是灾备中心年久失修,出问题是否能切过去,切过去是否能正常提供服务。

2. 异地双活(双机房)- 两个机房同时承载流量,需要进行数据同步,包括数据库,缓存,消息队列,CDN等的数据同步,有的时候核心服务做异地双活,其他小服务还是在部署在一个数据中心,因此有些服务还是需要进行跨机房的服务调用。

优点是可以同时扛流量,增加了资源的利用率,每个机房都按照峰值流量预估(每个机房承担峰值一般的流量),也就需要峰值两倍的容量,另外由于双机房一直都在服务用户,切换后能够确保第二数据中心可使用,因为第二数据中心也一直在使用。

3. 异地多活(多机房)

类似异地双活,但是增加了更多的节点,据说谷歌就是异地多活。

4. 阿里使用单元化,按照买家用户角度进行单元化,对于买家操作服务都在同一个机房内可完成,完成后同步数据到其他机房,对于卖家和商品维度,更新数据仍然需要按照买家维度来持久数据,所以买家的服务依赖的服务可能会散落在多个服务中心,服务操作仍然需要在多机房内完成,也就是必须有多机房内的服务调用,但是买家远远大于买家和商品数量,无论什么操作都需要在操作后同步数据,保证数据的一致性问题,据说阿里可以达到1秒以内的数据同步,阿里并没有公开是怎么做到的。

核心问题

1. 网络延迟问题,同一个城市网络延迟在一毫秒,多城市网络延迟在几十个毫秒,如果一个核心服务依赖多个核心服务,跨城市的机房调用,那将是在秒级别。

2. 数据同步问题(CDN, 缓存,消息队列,数据库),数据库本身的复制机制,应用层通过消息队列的复制机制,提取mysql bin log进行同步的机制(很难保证同一个操作对多个表的更改的时序问题)。

未完待续!