“怎么不使GitHub那样断网43秒瘫痪 24 个小时？”

本篇文章833字，读完约2分钟

今天，github技术负责人jason warner的技术深度解析稿成为了it圈的爆款。 在本文中，jason坦率地叙述了10月21日100g光缆设备故障后，github服务降级的应急过程和反思总结。

从jason warner的副本可以看出，互联网瘫痪43秒全天候的原因是数据库。 因为部署在两个数据中心的数据库群集没有实时同步。 在发生意外情况时，github工程师担心数据丢失，无法迅速安全地将主数据库切换到东海岸的备份数据中心。

程序员们在名为github的忏悔下留言，表达对数据库集群的哀悼。 但是，越来越多的it人员关心的问题是，不让这种灾害降临到自己的企业，而是自己维持的系统。

蚂蚁金服oceanbase分布式数据库专家认为，此次github是典型的城市级障碍。 如果系统使用高可用性的三地五中心处理方案，则可以自由应对。

一个月前，在今年的杭州云栖大会上，蚂蚁金服副cto胡喜现场模拟切断了支付宝( Alipay )近一半的服务器光缆。 仅仅26秒钟，模拟环境的“支付宝”( Alipay )就完全恢复了正常。 其背后是oceanbase城市级障碍的自我修复能力。

原来，github如银行使用的那样，传达了2个地区的3个中心模式:主库(主机房) +同城热备盘(同城热备室) +异地灾害恢复库(异地灾害恢复室) 在这种方式中，一般只有主机室的服务器可以提供写入服务。 在主城市发生城市级故障的情况下，灾难恢复城市的数据库可以运行，但由于没有同步的最新数据，该灾难恢复库中的数据已损坏。

但是，在三地五中心的部署中，即使单个城市发生故障，oceanbase也不会停止服务，数据也不会丢失。

github先生说，为了保证数据的完整性，必须牺牲恢复时间。 其实，这个问题如果使用三地五中心方案的话，会得到更好的应对。 如果城市发生故障，oceanbase只要能够在活的两个城市的三个机房的两个之间进行通信，就可以正常服务，也不会有数据丢失。