打开知乎和头条，b站又冲上了热榜，这次不是煽情怀旧的跨年晚会，也不是敲钟上市，而是“挂了”
b站的程序员跟进迅速，问题也得到了比较快的修复。
哈哈哈，上面是热点新闻，下面就是知识点了。 最近在学习分布式架构，刚好看到了“两地三中心”的高可用架构，我们云畅享一下，如果b站也用的是两地三中心的架构，还会挂掉不？这里先说明下两个概念：RPO和RTO
RTO (Recovery Time Objective，复原时间目标)是指灾难发生后，从IT系统故障导致业务停顿之时开始，到IT系统恢复至可以支持各部门运作、恢复运营之时，此两点之间的时间段称为RTO。比如说灾难发生后半天内便需要恢复，RTO值就是十二小时；
RPO (Recovery Point Objective，复原点目标)是指从系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作，恢复得来的数据所对应时的间点。如果现时企业每天凌晨零时进行备份一次，当服务恢复后，系统内储存的只会是最近灾难发生前那个凌晨零时的资料。
啥是两地三中心
两地三中心架构，即生产数据中心、同城灾备中心、异地灾备中心的高可用容灾方案。在这种模式下，两个城市的三个数据中心互联互通，如果一个数据中心发生故障或灾难，其他数据中心可以正常运行并对关键业务或全部业务实现接管。相比同城多中心方案，两地三中心具有跨城级高可用能力，可以应对城市级自然灾害。
两地三中心是高可用架构的一种实现方式，它是以整个应用系统为单位，一般来说会分为应用和数据库两部分。
应用部分通常是无状态的，这个无状态就是说应用处理每个请求时不需要从本地加载上下文数据。这样启动多个应用服务器就没有什么额外的成本，应用之间没有上下文依赖，所以很容易做到多活。
数据库需要最终持久化数据，所有的业务都要基于已有数据，数据内容在不断发生变化，数据库服务有逻辑很重的上下文。因此数据库的多活难度就大多了。
目前针对数据库双活的解决方案有很多种。总的来说分为两大类：分布式数据库多活方案以及传统数据库的双活方案。
传统数据库方案
传统数据库如Oracle, DB2，Informix等。由于这些数据库本身并没有在原生状态下考虑双活问题。因此双活方案都是在原生体系外面通过附加解决方案来构建的。这类解决方案基本上也都是在解决一个问题：就是如何将多块部署在不同数据中心上的数据盘（数据块）逻辑上merge成一个。 从接替思路上基本上有两种： 方法1：通过存储设备层实现。如EMC的vplex解决方案，IBM的SVC解决方案，IBM的HyperSwap解决方案，浪潮存储双活方案等。都是通过存储层来实现的。 方法2：通过分布式文件系统实现。例如GPFS解决方案，就是属于这一类。通过GPFS分布式文件系统的Failure Group功能，将另一份双活数据同步地写到另一个数据中心去。 更多细节可以看这里 https://www.zhihu.com/question/48728378/answer/1385829459
分布式数据库
目前新型的分布式NewSQL数据库OceanBase、TiDB、MemFireDB等，在系统设计方面就充分考虑到了多活的需求。因此原生满足。
分布式数据库两地三中心建设架构基于 Raft或Paxos 算法，保证了集群数据一致性和高可用。raft或paxos算法都是多数派协议，两地是同城、异地，同城双中心指在同城或临近城市建立独立数据中心，双中心通过高速链路实时同步数据，网络延迟相对较小，另外一个数据中心在异地城市。在这种场景下，同城的两个中心超过半数完成提交，这样就不会因为与异地机房通讯时间长而推高数据库的操作延时。
如果同城机房有一个不可用，异地机房节点的投票就会发挥作用，那么数据库的服务仍然可以正常运行，数据也未发生丢失，此时RTO=0，RPO=0。但是如果同城发生了自然灾害，两个机房均不可用，此时数据库服务无法提供服务，数据也会丢失，RPO就不为零了。在此基础上还可以升级到三地三中心无副本，提供城市级别容灾，在邻近城市实现RPO为零。
