饿了么MySQL多IDC架构设计

关于饿了么MySQL多IDC架构外面材料比较多,而且目前属于上线运行,运行比较好的业务,这里做一个记录。

分区依据: 把数据库首先分Zone,然后依赖于地区ID分布到不同Zone中,同一个Zone依赖于商户ID分布到不同分版中(shard)。每个Zone在不同IDC中进行互备。

底层数据同步依赖于自研的DRC进行数据同步。

使用上面的结构的好处就是两个IDC基本可以做到同时对外提供服务,不好的地方是,基本是原来的数据量直接翻倍的容量。

根据数据使用上不同,把Zone拆分为: 全局数据GlobalZone(单IDC写入,多IDC可读),多活架构(真正多活)。

全局数据GlobalZone

这种架构相于对简单,单节点写入, 容易控制数据的一致性。

多活架构(shardingZone):

数据分维度治理,每个单元的业务,都在自已的IDC中完成,不依赖于别的IDC。读和写都在本地IDC中完成, 正常情况下本地业务只需要本地机房的数据,对其它机房的数据无依赖,跨IDC数据延迟时无影响。

每个机房有独立一块区间的自增区间, 这块估计也是使用的自增的,1,3,5,… or 2,4,6,… 这种样子。 在业务设计上尽量让单个IDC接入的业务在单位IDC中完成,不依赖于其它IDC。 如果发生更新冲突,依赖于表里的DRC字段,判断谁是最新的数据,用最新数据覆盖旧数据。相当于主从复制处理中的1062错误(这块实现感觉并不严格),也是全程无锁设计,对于润秒时,可能有问题。

对于自增这块的,这块设计上,可以考虑用snowflake类似的算法,生成ID,可以让每个Zone保持某个特殊的数开头,这样会更清晰一点,但也要考虑顺序在里面,这也许是饿了么直接采用主建的原因。

饿了么在MySQL多IDC设计中遵循:

  1. 业务内聚,一个订单位的处理过程在一个机房中完成,减少可能的延迟。
  2. 可用性优先,优先保证系统可用,让用户可以下单吃饭,容忍暂时的数据不一致,事后修复。
  3. 保证正确性, 在确保可用的情况下,需要对数据做保护以避免错误
  4. 业务可感,业务团队修改逻辑,能够识别出业务单元的边界,只处理本单元的数据,打造强大的业务状态机,能发现和纠正错误。(这点我觉的才是核心,任何多idc,永远可用的业务,不能做到业务没感知,如果要求业务没感知的DB跨IDC设计都是扯蛋。)

 

如果你有其它感兴趣的内容,可以入群联系我。一同交流。

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.