从github超24小时的故障看异地多活全局设计的重要性

我们先来回顾一下github这次事故： 2018年10月21日，github 在更换网络设备时，引发了美国东海岸网络中心和东海岸数据中心的网络链接发生了40秒的中断，最终导致多个mysql的主集群由Orchestrator 自动选举切换到了美国西海岸数据中心对应的集群，由此引发了数据不一致，直接导致了超过24小时的服务降级，最后仍然还有少量数据需人工排查修复的悲剧。

事件的整个过程参考https://blog.github.com/2018-10-30-oct21-post-incident-analysis/ 这篇文章，在这里不详细说明，我们来直接看导致事件的根本原因。

根本原因：缺失异地数据中心之间数据一致性的保障机制

github数据库做的是本地主备+跨区域数据中心的容灾方案，主数据库集群和其他数据中心的集群是异步同步的，当物理网络发生中断后，对于github这样全球性的，大量用户访问的系统，时时刻刻都有数据变更，刚刚提交的数据还没有来得急同步过去，这时按照Orchestrator的机制，必然会重新选举出新的数据库写入主节点。在没有确定数据全局一致性的情况，就这么一切，两边数据就没法一致同步了，更悲剧的是等网络40s后恢复后，在Orchestrator没有将原有的数据库主节点置为从节点之前，东海岸本地的应用还在往本地数据库集群写数据，加剧了数据的不一致，发生了脑裂现象。除了数据不一致的问题外，还有个比较严重的后果，github 除了数据库主节点负责单点写外，其他区域数据中心的数据库节点负责读，把东海岸的应用数据库切都西海岸，会有60ms的网络消耗，就这点耗时，导致很多应用出现了服务超时不可用，对于很多web应用&