Page 264 - 《软件学报》2026年第1期
P. 264
向清平 等: 分布式数据库高可用研究进展 261
能对整个集群的高可用性构成威胁, 尤其是在分布式数据库系统中. 这一问题将在第 2.1 节进行详细的探讨, 特别
是关于如何通过网络优化和容错机制来保证数据库的高可用性. 在多数据中心环境中, 数据在不同地理位置之间
的同步和一致性维护变得更加复杂, 不同数据中心之间的网络延迟和带宽差异也会影响数据库的高可用性.
1.2 可用性和一致性的冲突
为了正确地描述一个事务处理系统是否具有高可用性, 我们需要描述一个客户必须接触哪些服务器以及服务
器能够提供哪些响应, 特别是考虑到中止的可能性. 传统上, 一个系统如果能在服务器之间存在任意、无限长的网
络分区的情况下, 每个用户能够访问正确服务器且最终都能收到来自服务器的响应, 那么这个系统就被认为是高
可用的.
CAP 理论包括强一致性、可用性和分区容忍性这 3 个属性. 强一致性是指在分布式系统中的同一数据多副
本情形下, 对于数据的更新操作体现出的效果与只有单份数据相同. 可用性指客户端在任何时刻对大规模数据系
统的读写操作都应该保证在限定的时延内完成. 分区容忍性指在大规模分布式数据系统中出现网络分区故障时系
统仍然能够继续运行处理请求.
对于一个大规模分布式数据系统来说, CAP 三要素不可兼得, 同一个系统至多只能实现其中的两个. 例如, 在
存在网络分区的情况下, 支持高可用性的系统就不能同时保证数据的强一致性. 分布式环境具有较高的不稳定性,
通常可能会出现两类故障: 节点故障和链路故障. 链路故障可能会导致网络分区, 即一个分布式系统的集群被划分
为若干个区域. 在同一个区域中, 节点间可以通信, 跨区域的通信则出现困难. 当多个副本分布在不同的网络分区
中时, 对一个副本的写入可能会无法同步到其他副本. 那么, 读取不同的副本将会返回不一致的结果. 因此, 由于分
布式环境下存在的链路故障, 系统通常需要在读写操作的一致性和节点的可用性之间加以权衡.
文献 [5] 将可用性分为粘性可用性、事务可用性和副本可用性这 3 种, 可实现的高可用事务 (high availability
transaction, HAT) 语句包括 ACID 隔离保证、ACID 原子性保证和会话保证. 在非粘性可用性的情况下, 系统必须
处理在分区下出现不幸的客户被迫向分区、过时服务器发出请求的可能. 粘性可用性允许 3 个额外的保证: 读所
写、PRAM (流水线随机存储)、因果一致性. 两种额外的高可用事务保证包括收敛性 (即最终一致性) 和一致性
(一个高可用性事务系统可以做出有限的应用级一致性保证).
文献 [6] 将系统可用性分为: 节点级别高可用、服务级别高可用和人工介入后可用. 节点级别高可用指当出
现网络分区后, 所有节点都能继续对外提供服务; 服务级别高可用指当出现网络分区后, 只要分区的严重程度有
限 (比如某个分区中存在多数派), 那么整个系统依然可以继续对外提供服务; 人工介入后可用指当出现网络分区
后, 系统暂时不可对外服务, 只有在人工介入确认系统状态或采取某种补救措施后, 系统才能继续提供服务.
文献 [6] 提到, 当系统在操作一致性方面提供强一致性, 但不支持事务一致性时, 系统无法实现节点级别的高
可用性. BigTable 是这种系统的一个典型代表. BigTable 主要由 3 部分构成: Chubby、Tablet Server 和 GFS. BigTable
将数据库划分为多个 Tablet, Chubby 将每个 Tablet 分配到唯一的 Tablet Server 上. 因此, 对 Tablet 的多次操作会
由相同的 Tablet Server 服务, 从而保证了数据访问的强一致性. BigTable 能够实现服务级别的高可用性, 这主要得
益于 Chubby 和 GFS 提供的高可用性保障. 当发生故障时, 虽然 Chubby 和 GFS 能够提供服务级别的高可用性保
障, 但在网络分区, 单个节点上的 Tablet 数据可能无法立即恢复, 导致节点级别的可用性受限. 例如当发生网络分
区时, 如果某个 Tablet Server 与 Chubby 之间的通信变得困难, 该 Tablet Server 会自动停止工作. Chubby 会认为其
出现故障并指定一个新的节点来恢复 Tablet 数据, 继续提供服务. 此外, GFS 中的数据在多个节点上保存副本, 全
局 Master 节点会监控节点故障并指定新的节点替换故障节点, 从而进一步确保系统的高可用性. 当系统提供较强
的操作一致性和事务一致性时, 系统仅能在人工介入下实现高可用性. 这类系统包括以 VoltDB 为代表的 NewSQL
数据库以及传统的基于主从复制技术的关系型数据库. VoltDB 依赖两阶段提交协议 (two-phase commit, 2PC) 来
协调多个线程共同完成事务执行. VoltDB 为每个数据分区维护了多个副本, 这些副本分布在多个物理节点上, 因
此可以容忍部分节点故障. 然而, 系统本身无法区分节点故障和链路故障. VoltDB 依赖外部的网络分区检测工具
来判定是否发生了链路故障. 如果检测到网络分区, 外部工具会仅保留拥有节点数量最多的那个网络分区, 并强制

