金点分享 | 数据库系列之GoldenDB中分布式事务的实现

分布式数据库中事务的原子性和隔离性问题是分布式事务实现的难点,在GoldenDB分布式数据库中引入了binlog自动补偿机制以保证原子性、GTM全局事务管理器以保证事务的隔离性,实现一致性读和一致性写。本文简要介绍了分布式数据库的理论以及GoldenDB中分布式事务的实现。

作者: 专家

贡献者 2022-01-18 10:38

1、分布式数据库理论

1.1 CAP理论

分布式数据库的设计遵循CAP理论,即一个分布式系统不能同时满足Consistency(一致性)、Availability(可用性)和Partition Tolerance(分区容忍性)这三个基本需求。

  • 一致性Consistency

一致性指的是更新操作成功并返回客户端后,分布式集群中每个节点都返回相同的、最新的数据。对于一致性,可以从客户端和服务端两个不同的视角来看:从客户端来看,一致性主要指的是多并发访问时更新过的数据如何获取的问题;从服务端来看,则是更新如何复制到整个分布式系统,以保证数据的最终一致性。在多进程并发访问时,根据获取更新过的数据的不同策略,一致性又分为强一致性、弱一致性和最终一致性。对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性。如果能容忍后续的部分或者全部访问不到,则是弱一致性。如果经过一段时间后要求能访问到更新后的数据,则是最终一致性。

  • 可用性Availability

可用性指的是系统服务一直可用,在合理的时间内返回读写请求的响应。对于一个可用的分布式系统,衡量系统可用性的时候,一般通过停机时间来计算的。

image.png

通常说金融核心业务系统的可用性水平达到5个9,即即全年停机时间不超过 (1-0.99999)36524*60 = 5.256 min,这是一个极高的要求。
  • 分区容忍性Partition Tolerance

分区容忍性指的是分布式系统在网络分区出现故障时,仍然能够对外提供满足一致性和可用性的服务。在分布式数据库系统中,分区容忍性和扩展性紧密关联,一个好的分区容忍性能够保证当其中几台机器故障或者网络异常后,能够快速的进行故障隔离不影响其它机器的正常运行;也能够保证系统扩展性,节点的新增和删除做到对业务无感知。

  • CAP的权衡

根据CAP理论,无法同时满足一致性、可用性和分区容忍性。但是在分布式数据库系统中,分区容忍性是必须的,分区是始终会存在的,因此需要在一致性和可用性之间进行权衡。

CP without A:分布式系统容许系统停机或者长时间无响应,一旦发生网络故障或者消息丢失等情况,就要牺牲用户的体验,等待所有数据全部一致了之后再让用户访问系统。传统的分布式数据库事务都属于这种模式,对于金融行业的分布式数据库产品而言,优先保证数据的一致性。
AP without C:分布式系统中允许数据不一致,一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。
image.png
在实际的分布式数据库系统中,基于分片解决扩展性问题并可以实现负载均衡,当某个分片服务不可用时,只会影响部分业务,即服务降级。同时基于多副本构成集群架构,提升系统的高可用。
ACID指的是数据库系统中事务所具有的四个特性:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation,又称独立性)、持久性(Durability)。
分布式数据库中,将数据库事务的ACID理论延伸到分布式架构下:
image.png
在分布式系统中,每一个机器节点虽然都能够明确地知道自己在进行事务操作过程中的结果是成功或失败,但却无法直接获取到其他分布式节点的操作结果。因此,当一个事务操作需要跨越多个分布式节点的时候,为了保持事务处理的ACID特性,就需要引入一个称为"协调者"的组件来统一调度所有分布式节点的执行逻辑,这些被调度的分布式节点则被称为"参与者"。协调者负责调度参与者的行为,并最终决定这些参与者是否要把事务真正进行提交。基于以上原则,分布式事务一致性算法主要包括2PC、3PC、Paxos和Raft。
二阶段提交2PC是一致性协议算法,可以保证数据的强一致性,该算法能够解决很多临时性系统故障(包括进程、网络节点、通信等故障),被广泛地使用于关系型数据库系统中。2PC协议中系统分为协调者和参与者,整个过程分为两个阶段:
在请求阶段,协调者将通知事务参与者准备提交或取消事务,然后进入表决过程。在表决过程中,参与者将告知协调者自己的决策:同意(事务参与者本地作业执行成功)或取消(本地作业执行故障)。
在该阶段,协调者将基于第一个阶段的投票结果进行决策:提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务,否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。
image.png

2PC协议的优点是原理简单、实现方便,但也有以下缺点:
  • 同步阻塞:在二阶段提交的执行过程中,所有参与该事务操作的逻辑都处于阻塞状态,也就是说,各个参与者在等待其他参与者响应的过程中,将无法进行其他任何操作。
  • 单点问题:协调者的角色在整个二阶段提交协议中起到了非常重要的作用。一旦协调者出现问题,那么整个二阶段提交流程将无法运转,更为严重的是,如果协调者是在阶段二中出现问题的话,那么其他参与者将会一直处于锁定事务资源的状态中,而无法继续完成事务操作。
  • 数据不一致:在阶段二时,当协调者向所有的参与者发送Commit请求之后,发生了局部网络异常或者是协调者尚未发送完Commit请求之前自身发生了崩溃,导致最终只有部分参与者收到了Commit请求。于是,这部分收到了Commit请求的参与者就会进行事务的提交,而其他没有收到Commit请求的参与者则无法进行事务提交,于是整个分布式系统便出现了数据不一致现象。
  • 太过保守:二阶段提交协议没有设计较为完善的容错机制,任何一个节点的失败都会导致整个事务的失败。
1.3.2 3PC(three-phase commit)

3PC协议在协调者和参与者中都引入超时机制,并且把两阶段提交协议的第一个阶段拆分成了两步:询问,然后再锁资源,最后真正提交,包括CanCommit、PreCommit和doCommit三个阶段。
image.png
1)CanCommit阶段
3PC的CanCommit阶段和2PC的准备阶段很像。协调者向参与者发送commit请求,参与者如果可以提交就返回Yes响应,否则返回No响应。
2)PreCommit阶段
协调者根据参与者的反应情况来决定是否可以继续事务的PreCommit操作。根据响应情况,有以下两种可能。



推荐

最近更新

热门推荐