饿了么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设计中遵循：
业务内聚，一个订单位的处理过程在一个机房中完成，减少可能的延迟。
可用性优先，优先保证系统可用，让用户可以下单吃饭，容忍暂时的数据不一致，事后修复。
保证正确性， 在确保可用的情况下，需要对数据做保护以避免错误
业务可感，业务团队修改逻辑，能够识别出业务单元的边界，只处理本单元的数据，打造强大的业务状态机，能发现和纠正错误。（这点我觉的才是核心，任何多idc，永远可用的业务，不能做到业务没感知，如果要求业务没感知的DB跨IDC设计都是扯蛋。）
特别声明： 本文是虢国飞 在 DTCC2018分享的《饿了么异地双活数据库实战》的一些总结。 其中的可能有错字， 有强迫症的见谅。