怎么让b站不挂

打开知乎和头条，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功能，将另外一份双活数据同步地写到另外一个数据中心去。 更多细节能够看这里 www.zhihu.com/question/48…

分布式数据库

目前新型的分布式NewSQL数据库OceanBase、TiDB、MemFireDB等，在系统设计方面就充分考虑到了多活的需求。所以原生知足。

分布式数据库两地三中心建设架构基于 Raft或Paxos 算法，保证了集群数据一致性和高可用。raft或paxos算法都是多数派协议，两地是同城、异地，同城双中心指在同城或临近城市创建独立数据中心，双中心经过高速链路实时同步数据，网络延迟相对较小，另一个数据中心在异地城市。在这种场景下，同城的两个中心超过半数完成提交，这样就不会由于与异地机房通信时间长而推高数据库的操做延时。

若是同城机房有一个不可用，异地机房节点的投票就会发挥做用，那么数据库的服务仍然能够正常运行，数据也未发生丢失，此时RTO=0，RPO=0。可是若是同城发生了天然灾害，两个机房均不可用，此时数据库服务没法提供服务，数据也会丢失，RPO就不为零了。在此基础上还能够升级到三地三中心无副本，提供城市级别容灾，在邻近城市实现RPO为零。

引用

• community.memfiredb.com/topic/28/me…
• www.zhihu.com/question/48…
• blog.itpub.net/26736162/vi…