分布式OLTP数据库发展趋势（四）：系统高可用
高可用是系统架构设计中必须考虑的因素之一，主要设计目标是减少系统不能提供服务的时间，一般我们使用“可用性”来反映一个系统的高可用能力。可用性是一个百分比数值，计算公式为程序正常运行时间/(程序正常运行时间+系统故障时间)。通常我们习惯用N个9来表示系统的可用性，如4个9，也就是99.99%，代表这个系统每年停机时间为52.6分钟。
冗余和故障转移是高可用实现的两种模式，大多数高可用方案中都结合两者一起来保证部分组件发生故障时可以切换到冗余组件上继续对外提供服务，从而实现整体服务的高可用。按照一般业务架构类型划分，高可用又可以分为业务高可用、计算高可用和存储高可用。业务高可用和计算高可用因为是无状态的，只需部署多套能够实现同样功能的组件就可以实现高可用。存储高可用相对来说更为复杂，因为数据库在不同时刻不同节点会有不同的事务状态，因此并不是简单的两份就可以，而数据库的高可用本质上是存储的高可用。
01传统单机数据库采用共享存储
存在一定的局限性
共享存储方案最典型的基于共享存储的高可用方案是Oracle RAC，从架构上看，RAC底层是共享存储，上层是多个数据库实例通过高速网络互联，以支持多写和高可用。这种方案中所有节点都可以接收客户端的请求，能够保证集群中只要有一个节点存活，就能正常对外提供服务。
图-共享存储基本架构
不过这种方案实现对存储和网络有较高的要求，且受制于共享存储的性能上限，在当下分布式数据库技术日新月异的背景下，很难满足未来业务的发展趋势。而在容灾部署环境中，RAC架构显然是不合适的，通常还需要搭配存储系统层的复制方案，或者采用基于日志传输的数据复制方案。
基于日志同步的主从复制方案比较典型的基于主从复制的高可用方案有Oracle的DataGuard、MySQL的Binlog复制以及PostgreSQL的WAL复制等。这种方案是将一个主数据库中的数据通过日志形式同步给一个或多个从数据库，从数据库将接收到的日志在本地进行回放来实现数据的冗余。按照主从数据库一致性程度的不同，主从复制又可以分为强同步、半同步、异步复制等模式，在Oracle中称为最大保护、最大可用和最大性能模式。当主数据库故障的时候，可以将从数据库变更为主库持续对外提供服务。
图-MySQL基于Binlog主从复制架构
但是，基于日志同步的高可用方案，在容灾部署环境中通常RPO和RTO数值会比较高，难以满足重要行业或重要数据的安全保障。RPO方面，如果采用强同步的主从复制模式，主库的稳定性将受制于从库和网络环境，对生产系统的影响较大。因此，一般生产系统中都采用半同步或者异步复制模式，此时如果主库发生故障时则会有数据丢失的风险。RTO方面，由于主从复制方案缺少第三方仲裁，当主从数据库之间的网络异常时，从库无法判断主库是否真的发生故障，所以主从复制的数据库都不提供自动切主的功能，需要人工进行判断并实施切换操作，这往往使得故障持续时间大大增加。
02基于分库分表的分布式架构
高可用方案本质仍是主从复制
集中式数据库由于横向扩展能力的不足，无法满足业务量和数据量爆发式增长的需求，于是便演进出一系列最早起源于互联网厂商的分库分表架构的分布式数据库产品。这一类产品总体架构分为两层：上层是用来进行SQL解析和转发的路由层或者称为中间件层，下层则是用多个开源单机数据库实现数据的分库分表。
图-基于分库分表的分布式数据库架构
为了避免部分节点故障导致数据库不可用，通常对每个分片节点配置主从复制功能，并附以一定的优化机制，例如，通过增加管理组件实时捕获各数据库实例的状态并在发生故障时进行选主切换，从而实现一主多备的高可用。然而，这种分库分表架构的高可用能力本质上仍然是基于数据日志的主从复制，因此存在以下几方面的不足：
运维复杂度高。受分库分表架构影响，需要同时进行多个组件多种策略的高可用配置，任何一个组件出现问题则会影响整个集群的高可用。
数据一致性难以保证。考虑到实际业务的可用性，一般采用半同步或异步复制模式进行数据同步，如果发生主库故障时，会有数据丢失的风险。
故障恢复时间无法保证。当故障发生时，需要人为校对数据一致性，手动实施切换动作，另外受整个架构复杂度影响，需要针对多个组件进行校验和切换，增加了故障恢复的时间。
QianBase基于原生分布式架构
实现内部自治的数据高可用
不同于分库分表架构，易鲸捷打造的QianBase xTP数据库是一款基于原生分布式架构设计的分布式OLTP数据库。在底层存储引擎实现上，QianBase不再采用多个单机数据库的方式，而是将数据以分片为单位均匀打散在不同的数据节点，并以键值对的格式进行分布式存储。由于没有单机数据库，数据的冗余机制也不需要采用单机数据库的主从复制方案，而是基于业界比较流行的分布式一致性共识协议来实现数据多个副本的同步，因此能够很好的规避主从复制带来的一致性与可靠性相关问题。
图-QianBase原生分布式数据库架构
在具体实现上，QianBase针对每个数据分片可以设置多个副本（默认为3个），QianBase为每个分片副本赋予以下三种角色之一：
Leader角色。每个分片只能有1个副本是Leader，负责处理所有客户端的读写请求，并负责复制所有的数据日志到Follower角色。
Follower角色。正常情况下3副本中有2个是Follower，只是被动接受并响应来自Leader或者Candidate的消息，不对外提供服务。
Candidate角色。当Leader故障时，Follower会转换为Candidate状态并进行新Leader选举，收到多数派投票的候选者将成为新的Leader。因此这是一个中间临时状态。
图-一致性协议中的角色切换流程
注：上图中term充当一个逻辑时钟的概念，使得服务器节点发现一些过期的信息比如过期的Leader时可以自动识别并销毁，保证任何时刻服务的一致性。
可以想象，在一个正常的QianBase集群中，每个节点会有一定数量的分片副本，其中包含负责外部请求的Leader副本以及被动接受日志同步的Follower副本。当某个节点发生故障时，此节点上的Leader角色将会切换到其他正常节点，节点相关的业务会短暂中断后并立刻恢复正常，而Follower角色因为本身不提供服务所以对业务完全没有影响。
从上述描述中我们也可以总结出，QianBase基于一致性协议进行多副本数据复制，主要解决以下3个关键问题：
Leader选举。节点可能会宕机从而导致Leader失效，此时必须从Follower中选举出一个新的Leader出来，因为只有Leader才能对外提供服务。
日志复制。Leader从客户端接收变更后需要将变更日志复制到Follower并且保持数据的一致性，这样当Follower变更为Leader时才能继续对外提供服务。
保证安全。一致性协议中有一个“多数派”概念，当超过半数的副本数据同步成功后则认为事务成功。对于没有来得及同步的Follower副本，也一定要保证之后能够同步成功，否则就可能会有数据不一致的风险。
图-一致性协议解决的3个关键问题
由于多副本一致性实现是在QianBase数据库内部自动完成，不需要像主从复制那样进行复杂的数据库配置，也不需要引入第三方的同步工具，因此对运维管理人员来说是完全透明的，这有效解决了分库分表架构运维复杂度高的问题。其次，一致性协议算法采用多数派强一致提交，在保证数据一致性的前提下还能够容忍部分节点的异常。另外，QianBase还支持将副本放置在不同的地理位置，基于多数派提交机制，真正实现一套数据库集群部署多地多中心的方案，避免了一般分布式数据库需要部署多套集群并进行集群间数据同步的复杂操作。QianBase是一套能够真正满足重要核心业务系统的高可用分布式数据库。
党的二十大报告指出，教育、科技、人才是全面建设社会主义现代化国家的基础性、战略性支撑。必须坚持科技是第一生产力、人才是第一资源、创新是第一动力。加快建设网络强国和数字中国。贵州易鲸捷信息技术有限公司连日来深入学习党的二十大精神，将其贯彻至具体生产工作中，凝心聚力攻克科技技术难关，为我党实现第二个百年奋斗目标奋勇前进。
END
▼
往期精彩回顾
▼
易鲸捷简介
易鲸捷公司成立于2015年，专注于新一代融合型分布式数据库核心技术研发。公司核心团队源自天腾公司，曾创造过NonStopSQL等全球领先的数据库产品，核心技术完全自主可控。经过多年技术沉淀，易鲸捷已形成自主可控、国产可信、安全高效的三条完整分布式数据库产品线：QianBase xTP/QianBase TP/QianBase MPP，可面向不同行业应用提供完整的一站式解决方案，在金融、运营商、智能制造、5G等重点行业获得广泛应用。
网址：www.esgyn.cn
贵州易鲸捷信息技术有限公司 地址：贵阳市高新区长岭南路160号高科1号C座24楼 | |
北京易鲸捷信息技术有限公司 地址：北京市朝阳区大屯街道北苑路万科时代中心奥林A座10层 | |
上海易鲸捷信息技术有限公司 地址：上海市浦东新区金科路2889弄1号长泰广场A座6层03单元 | |
北京：010-84983409 | 上海：021-50822117 |
邮箱：info@esgyn.cn | 网址：www.esgyn.cn |