0 开场词
大家晚上好，欢迎大家观看kingbase数据库直播，我是本次主讲人growdu，目前在kingbase主要负责数据库集群高可用的研发设计。今天由我来给大家讲解KES集群高可用——两地三中心方案，分享一下如何做到数据不丢，服务不停。本次分享呢尽量从宏观层面来讲解两地三中心集群，尽量讲解通用的技术，希望对观看直播的大家都能有所收获。
本次内容主要从以下四个方面讲解：方案概述、方案实现、方案实例以及未来发展。
1 方案概述
下面我们先来看下方案概述：
大家都知道对于数据库来说，数据至关重要，对数据进行备份，保证数据不丢，保障服务不停成为我们必须要处理的三个问题。
而kingbase的两地三中心方案就是围绕着这三点来展开实现的。包括后面我们的所有内容也都是围绕着三点来展开讲解。
针对以上三点呢，业界常用的方案就是多地域多副本，并由此衍生出了多个方案。下面是方案的大致演化工程：
- 首先是单机时代，这个时候呢可用性较低，节点挂了就无法提供服务了；
- 然后为解决单机故障问题，衍生出了主备集群，这个时候一个节点挂了另外一个节点还能够提供服务；但简单主备集群无法处理地域性故障或者网络分区，很容易出现双主，导致数据不一致；
- 为了解决地域性问题以及应对自然灾害演化出了同城双中心方案和两地三中心方案；
- 后来觉得两个地域还是不够稳妥，进一步又衍生出了三地五中心方案；
kingbase数据库也是按照这样的历程走过来的，从单机到主备，再到当前的同城双中心和两地三中心，在不久的将来kingbase还会发展到三地五中心。本次直播呢，我们会重点讲解同城双中心和两地三中心的方案实现和技术原理。
正如之前提到方案的重点就是多副本，涉及到多副本的话就不得不考虑分布式系统里面要面临的一个关键问题——CAP理论。
这里的CAP分别指的是一致性、可用性、分区容错性，
- 一致性指的是所有节点上的数据保持同步，随着副本多起来后这个是比较困难的，
- 可用性指的是服务在正常响应时间内一直可用，
- 分区容错性是指在遇到节点故障或者网络分区的时候，仍能对外提供一致性或可用性的服务。分区容错的一个反例就是出现网络隔离，分割成多个分区，各个分区各自对外提供服务，导致数据不一致。
而CAP理论呢指的是我们最多只能满足一致性（C）、可用性（A）、分区容错性（P）这三项中的两项。
简单来说就是，服务不停、多个分区提供服务、多个分区数据一致是存在矛盾的，kingbase两地三中心方案就是要在保证可用性和一致性的前提下，尽量提升分区容错性。后面我们会讨论到多数派原则、选主、少数派自fence、第三方仲裁投票都是为了做这个事情的。到时候会对这部分再进行详细的说明，CAP理论是我们后续技术方案实现的技术理论基础。
除了从我们技术或者实际业务场景出发演化出的两地三中心方案外，国家标准和金融标准也针对两地三中心方案出台了相应用的规范和标准，用于指导信息系统的开发建设。
尤其是在金融行业，商业银行监管要求更是对两地三中心方案进行了细化，两地三中心方案列成为了银行信息系统的监管标准。
这里列出了从06年到现在的规范要求，主要包括这么几个方面：
- 06年的时候提出了大型银行应同时采用同城和异地灾难和备份恢复，这个就是现在两地三中心方案的基本的轮廓。这里的两地就是同城和异地。
- 07年的时候对两地三中心的灾难恢复进行了量化，使用RPO、RTO对灾难恢复进行分级，使两地三中心的架构可衡量
- 08年进一步对信息系统按重要程度进行了划分
- 10年的时候标准规定商业银行可以先设立生产中心，再设立灾备中心，这里其实就是说明了两地三中心架构的可扩展性
- 11年明确了RTO和RPO的要求
- 到了12年呢则是提出切换演练的要求，要支持故障切换功能
- 而到了2020年的时候，则是使用可用性将两地三中心进一步量化了，要求可用性至少达到99%
这个就是两地三中心方案的一个基本背景和基本要求，kingbase的两地三中心方案就是在这个背景和要求上做进一步的设计开发和完善的，同时在设计的时候还会考虑到之前提到的在保证可用性和一致性的前提下，尽量提升分区容错性。
下面呢根据前面提到的概念进行详细的介绍。
首先我们先看下RPO和RTO，这个是衡量两地三中心方案的重要指标，也是用户层面能看到的最直观的东西（数据丢多少、就是服务停多久、），我们的方案靠不靠谱就看两个参数。
RPO呢被称作恢复点目标，是指业务系统所允许的在灾难过程中的最大数据丢失量，用来衡量容灾系统的数据冗余备份能力。RPO通俗来说就是我能丢多少数据。
RTO呢是指恢复时间目标，是指信息系统从灾难状态恢复到可运行状态所需的时间，用来衡量容灾系统的业务恢复能力。
其实RTO就是服务能停多久，或者说服务出现非预期故障后，多久可以恢复过来。
有了RTO和RPO后就可以根据RTO和RPO的时长来对灾难恢复能力进行等级划分，国家标准根据RTO和RPO的时长不同将灾难恢复能力分为6级，灾难恢复能力等级越高，可用性就越高，当然实现难度越大。
对于两地三中心来说，灾难恢复能力至少应达到5级，即RTO=数分钟到2天，RPO=0到30分钟，这个是两地三中心的基本目标，或者说是最低要求。
这里要求其实还是比较宽松的，比如RTO=数分钟到2天，意味着最长可以在2天内恢复数据库访问，这其实在实际系统里是不能接受的。
2天不服务客户，客户早就跑了。
而RPO=0到30分钟就更不能接受了，这意味着最多可以丢30分钟的数据，这要是负债数据丢了这么多，客户不得笑死。
所以呢，金融规范里增加了可用性的概念，同时对灾难恢复等级提出了更高的要求。
这里我们还是重点看5级灾难恢复能力，可以看到RTO应该小于30分钟，RPO呢应该尽量等于0，用可用性来说呢就是可用性应该达到99.99%。
用我们之前的话说，就是服务不能停，数据不能丢，要停的话不能超过30分钟。对于客户来说，几分钟内不可用，勉强还是可以接受的。
这个呢也是kingbase两地三中心方案的基本能力要求，当然kingbase两地三中心方案是奔着RPO=0，RTO=0去的，也就是服务不停，数据不丢。
我们前面聊到了方案的发展历程、方案的技术难点、方案的标准规范以及方案的衡量标准，到这里对两地三中心方案就有了一个大致的认识，下面我们来看下两地三中心具体是什么样的。
先来看看两地三中心的定义，顾名思义，两地是指不同的城市，比如北京和上海，三中心是指生产中心、同城灾备中心、异地灾备中心。生产中心主要负责对外提供服务，同城灾备中心一般采用同步的方式和生产中心同步备份数据，异地灾备中心内一般采用异步的方式备份数据。
这个就是两地三中心的基本形式。
根据两地三中心的基本形式可以扩展衍生出多个方案，两地三中心并不要求一步定位，一下子就部署好三个中心。
它可能是先部署生产中心，再部署灾备中心，最后才演变成两地三中心，它是可以扩展的。
下面我们来看一下每种架构的区别和特点，首先来看下kingbase的同城双中心是如何设计的。
同城双中心采用大集群+小集群的架构方式来进行设计，每个中心是一个小集群，确切的说是一个一主多备集群。这里的中心呢也叫可用区，比如这里的AZ1，先启动的中心叫作生产中心，生产中心启动后，中心内会选举出一个主节点负责对外提供服务。同中心内的节点采用同步的方式与主节点连接进行数据传输备份。
后启动的中心内叫做同城灾备中心，也就是这里的可用区2。同城灾备中心与生产中心类似，只是同城灾备中心内选举出来的节点被称为伪主节点。伪主节点与生产中心主节点采用同步的方式传输数据。这里的同异步是针对主节点来说的，因为同城灾备中心只有伪主节点和主节点以同步方式直连，所有同城灾备中心内的其他节点数据同步方式为异步。
kingbase会增加一个中心间仲裁observer，与生产、同城组成一个大的集群，用于在一个中心故障或者中心间出现网络故障时辅助投票，并进行中心间切换。
当前业界一般采用的是两个中心作为一个大的集群的架构，这种架构会带来一个问题就是作为大集群，两个中心间的故障会互相造成干扰。比如采用多数派原则作为服务依据时，生产中心节点节点部分存活，而同城灾备中心节点全部挂死的时候，会导致生产中心也无法提供服务。kingbase采用大集群+小集群的架构主要是为了避免中心间互相造成干扰，同时通过选择主节点的方式减少同城灾备中心到生产中心主节点的传输压力。
这个就是kingbase同城双中心的一个基本架构，这里只做一个简单介绍，后面第二章讲解方案实现的时候会做详细说明。接下来我们再来看看异地双中心。
其实异地双中心与同城双中心基本一致，唯一的区别就是异地中心和生产中心部署在不同城市的不同机房，同时由于距离因素产生的网络延迟，一般呢会把异地中心伪主节点到生产中心主节点的数据同步方式设置为异步。
了解了同城双中心和异地双中心后，再看来两地三中心就比较简单了，两地三中心其实就是前面两者的结合。我们有三个可用区，分别位于两个城市的三个机房，依然采用的是大集群+小集群的架构，每个中心是一个小集群。然后生产、同城、异地选出来的主节点或者伪主节点与observer组成了一个大的集群。
介绍了kingbase两地三中心的基本架构后，我们再来看下kingbase两地三中心方案的基本功能，如要是以下几个方面：
- RTO=0，RTO≈0，达到灾难恢复等级6级
- 支持故障切换演练，包括手动切换和自动切换（恢复、故障转移、备升主、主降备、自fence）
- 部署运维管理
- 以及备份并且在发送各种故障后服务不能停
到这里相信大家对两地三中心方案有了一定的认识，前面介绍了两地三中心方案的演进过程、面临的关键问题、方案的标准规范、方案的衡量标准、kingbase两地三中心方案的架构、kingbase两地三中心的功能，有了这些基础之后，我们再来看下kingbase的两地三中心方案具体是怎么实现的。
2. 方案实现
之前有提到过，kingbase采用的是大集群+小集群的方案，方案实现讲解呢采用从局部到整体的方式来进行讲解，并且我们会重点以同城双中心为例来进行讲解说明，因为异地双中心和两地三中心与同城双中心比起来，整体机制和实现上并没有太大的区别。
2.1 单中心
我们先来看下单个中心的架构，这里将单个中心内的组件按照分层逻辑列了出来，从业务层出发，依次是驱动层，比如jdbc、odbc之类的，使用过数据库编程的朋友应该了解，这个主要是在编程时进行数据库访问的，驱动层之下呢是实例层，这里的实例层就是数据库，实例层之下呢就是高可用服务，kingbase的高可用服务分为三层：高可用代理、高可用管理、集群资源管理。高可用代理是负责数据库节点的启动运行和流复制关系以及中心内切换，高可用管理主要是负责集群元信息的读取和存储，集群资源管理主要是将中心内的各节点组成一个分布式集群，处理节点多数派和分布式通信。
当有业务请求到达数据库后，需要所有同步节点均确认数据库的日志写入磁盘后才能将请求成功的响应返回给客户端。
整个中心的运行机制是这样的：多数派原则、少数派fence。最底层组件DCS会通过各个节点之间的心跳，判断节点是否处于多数派，处于多数派的节点会进行选举投票，获得多数节点投票的节点被选举为主节点对外提供服务（这里的多数节点指的是半数以上节点，比如三个节点就需要获得2个节点的投票）。而处于少数派的节点无法提供服务，会被自fence，所谓的自fence其实就是停掉数据库。
当故障的节点恢复后呢，若节点处于多数派，则高可用管理服务会自动启动并将高可用代理服务拉起，由高可用代理启动数据库并恢复。
业界大多数产品都是这样设计的，就是利用冗余来保证一致性和分区容错性，但因为少于半数节点无法提供服务牺牲了一定的可用性，也就是前面提到过的CAP理论。kingbase为了解决少数节点存活无法提供服务引入了多种机制，比如这里提到的使用一个额外的节点来辅助仲裁，以及后面会重点讲解的网络仲裁和共享存储仲裁，都能够使少数节点存活仍能提供数据库服务，提升可用性。这些都是kingbase两地三中心方案的亮点，在后面会重点讲解。
2.2 同城双中心基础架构
同城双中心是由前面提到的两个单中心架构组成的，只是这两个中心作为两个可用区，部署在同一城市的不同机房。而将两个中心整合起来作为同城双中心，主要要处理的就是两个中心之间如何同步数据，以及当其中一个中心故障时，如何切换到另外一个中心。
同城灾备中心，也就是这里的AZ2会通过中心内选举，选出一个伪主节点，由伪主节点代表同城灾备中心与生产中心采用同步的方式同步数据，而同城灾备中心的其他节点与伪主节点进行数据同步。
当生产中心的主节点故障后，会优先选择生产中心内的备节点提升为主节点继续提供服务。只有在整个生产中心故障后，主节点才会从生产中心切换到同城灾备中心。
同城双中心基础架构有如下特点：
- 降低主节点的压力
- 中心内优先升主
- 中心间数据不丢
- 简单故障无需人工干预
- 组合故障半人工干预
下面我们通过几幅图来详细了解一下多数派原则。
在第一幅图中，三节点的集群，按照多数派原则，至少存活2个节点才能继续提供服务。当单个节点故障时，主节点仍然能继续提供服务，因为还剩下2个节点，此时若再挂死一个节点，主节点就会因为不满足多数派原则而无法提供服务。
然后我们再来看另外一种情况，同样是3节点集群，当其中一个节点因为网络故障被隔离时，因为该节点处于少数派，将会触发自动fence机制，停止数据库，此时主节点仍能正常服务。
再来看另外一种情况，如果是主节点被单独网络隔离了，除了会触发自fence之外，还会触发自动故障切换，主节点将会切换到备节点上。
这个呢是同城双中心的基础架构，业界大多数产品都是采用的这种架构，这个架构就会面临前面提到的CAP三者这可以满足两者的问题。
比如三节点集群只剩下最后一个节点时就无法提供服务，因为不满足多数派原则，无法保证数据一致性。
再比如五节点集群，当挂掉3个节点后，因为剩下的两个节点不满足多数派原则也无法提供服务，因为无法保证数据一致性。但实际上还剩下两个节点却无法提供服务是不能允许的。
kingbase针对这种情况做了改进和完善，设计了同城双中心网络仲裁架构和同城双中心共享存储架构，专门用来支持最后一个节点存活仍能提供服务，以及少于半数节点仍能提供服务，以提升两地三中心集群的可用性。
2.3 同城双中心网络仲裁架构
下面我们来看下同城双中心网络仲裁架构，看下它是如何解决最后一个节点存活和少于半数节点存活仍能提供服务的。
网络仲裁架构在原来的同城双中心的基础上引入了中心内的网络仲裁，网络仲裁会给每一个节点投票。并且网络仲裁投给节点的票数为集群节点个数减1，这样就能够保证即使只有一个节点存活，只要能获取到网络仲裁的投票，该节点的票数就满足多数派规则继续提供服务。比如三节点的集群，每个节点1票，仲裁集群是3-1=2票，总共是5票，多数派的票数是3。这个时候只剩下一个节点，该节点还能获取到自己的1票和仲裁的2票，总共是3票，仍然能提供服务。
网络仲裁架构还能有效处理网络分区，特别是对预防脑裂非常有用。
不仅如此，网络仲裁可以是单个节点，也可以是一个集群（可用性更高），而且网络仲裁还可以被多个集群共用，这在多套集群的场景下尤其有用。
最后一个节点存活提供服务、少数派节点提供服务、防脑裂以及多集群共享仲裁是kingbase两地三中心方案最大的亮点，也是实现RPO=0，RTO≈0的关键技术。
我们来看下网络仲裁的关键功能，首先是LMS，也就是最后一个节点提供服务。
同样的场景，引入网络仲裁后因为仲裁能够给剩下的节点投票，在三节点集群中，即使只剩下一个节点，其票数仍然能满足多数派规则，可以继续提供服务。同样地，对于网络分区的场景，网络仲裁可以把票投给之前的主节点，既不用发生切换，还能继续提供服务。
那么网络仲裁到底有什么优势呢？我们和之前的基础架构做一个简单的比较，可以看到网络仲裁集群在如下功能上有明显的优势：
- 增强型多数派，在保证一致性的同时，少于半数节点仍能提供服务
- 最后一个节点继续服务
- 多套集群共用仲裁，可以节约资源
2.4 同城双中心共享存储仲裁
聪明的朋友可能会说，即使共用网络仲裁，在单套集群的时候还是会引入额外的机器，在我机器资源不足的时候还是没法采用这种方案。这个问题kingbase两地三中心集群同样考虑到了，就是下面我要讲解的同城双中心共享存储仲裁架构。
同城双中心共享存储仲裁不需要额外的服务器资源，只需要一块共享存储磁盘设备就可以达到前面所提到网络仲裁的功能：
- 最后一个节点提供服务
- 少于半数节点提供服务
- 防脑裂
和网络仲裁集群对比，我们来看下共享存储仲裁的表现：
- 可以看到，都支持最后一个节点故障仍能提供服务。
- 同样可以看到，在网络分区后都能投票给原主节点继续提供服务
下面是具体的架构能力对比，只是把仲裁由网络仲裁换成了共享存储仲裁，其能力没有任何区别，而且还可以节约服务资源，但需要单独购买共享存储设备。
2.5 同城双中心架构对比
到这里，同城双中心的三种架构就介绍完毕了。下面我们看下这三种架构的详细对比。可以看到每种架构都尤其适用场景，用户可以按需选择架构。
当然，从可用性的角度出发，kingbase强烈推荐网络仲裁架构和共享存储仲裁架构，只需要少量的资源就可以为系统带来更高的可用性。同时这两个方案也是kingbase两地三中心方案的亮点。
2.6 同城双中心容灾场景
到这里，同城双中心的架构就基本介绍完了，下面我们介绍一下同城双中心的容灾场景。首先来看下节点级故障切换，这个在前面其实已经简单提到过。
比如当生产中心的主节点故障后，会优先选择生产中心内的一个备节点（根据同异步状态、优先级、数据新旧程度、节点id进行选择）提升为新主节点，observer发现生产中心的主节点发生变更后，会重建灾备中心伪主节点到新主节点的数据同步关系，以保证中心间的数据同步是正常的。
若一段时间后故障节点恢复，这个时候，恢复的节点的高可用管理服务会自动启动，并拉起高可用代理，由高可用代理启动数据库，并重新建立与新主库的数据同步关系。
若此时有一个节点发生了网络故障，被网络隔离了，此时会触发自动fence，如果fence的是主库，还会触发自动故障切换。这些操作都是自动完成的。
更极端的如果是整个生产中心故障了，observer会通过同城灾备中心进一步确认生产中心是否故障，确认故障后observer就会将主节点切换到同城灾备中心的伪主节点，由同城灾备中心新主节点对外提供服务。
2.7 两地三中心架构
到这里同城双中心就讲解得差不多了，而在两地三中心方案中，最核心的其实是同城双中心，理解了同城双中心后，要理解两地三中心就没有什么难度了。两地三中心包含同城双中心的所有功能，只是对同城双中心做了扩展，增加了异地灾备中心。在技术架构和原理上并没有引入其他特别的机制。
下面简单介绍一下两地三中心架构。依然是大集群+小集群的架构，有三个可用区，也就是三个中心。
