饿了么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 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.