南大通用GBase 8c事务状态保持技术解析与实践

原文链接：

https://www.gbase.cn/community/post/3866

更多精彩内容尽在南大通用GBase技术社区，南大通用致力于成为用户最信赖的数据库产品供应商。

在当今互联网及企业级应用中，数据处理的一致性与可靠性成为系统设计的关键因素。在此之前先了解基本概念

1、基础概念

在分布式集群中，单机事务（也可称为单分片事务）是指一个事务中所有的操作都发生在同一个分片（GBase 8c中称为DN）上，分布式事务是指一个事务中有两个或以上的分片参与了该事务的执行。对于单机事务，其写操作的原子性和读操作的一致性由该 DN 自身的事务机制就能保证;对于分布式事务，不同分片之间写操作的原子性和不同分片之间读操作的一致性，需要额外的机制来保障。

• 事务机制

事务是为用户提供的最核心、最具吸引力的数据库功能之一。简单地说,事务是用户定义的一系列数据库操作(如查询、插入、修改或删除等)的集合,从数据库内部保证了该操作集合(作为一个整体)的原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability),这些特性统称事务的 ACID特性。其中：

• A:原子性是指事务中的所有操作要么全部执行成功,要么全部执行失败。一个事务执行以后,数据库只可能处于上述两种状态之一,即使数据库在这些操作执行过程中发生故障,也不会出现只有部分操作执行成功的状态。

• C:一致性是指事务的执行会导致数据从一个一致的状态转移到另一个一致的状态,事务的执行不会违反一致性约束、触发器等定义的规则。

• I:隔离性是指在事务的执行过程中,所看到的数据库状态受并发事务的影响程度。根据该影响程度的轻重,一般将事务的隔离级别分为读未提交、读已提交、可重复读和可串行化四个级别(受并发事务影响由重到轻)。

• D:持久性是指一旦事务提交以后,即使数据库发生故障重启,该事务的执行结果不会丢失,仍然对后续事务可见。

• 单机事务（本地事务）

CN节点接收到上层应用的事务请求，发现数据分布在本地单个高可用组（HG）上，此时CN直接向该HG请求数据并返回。这种方式不走两阶段提交过程，处理性能非常高。

• 分布式事务

GBase 8c的跨节点的分布式事务是通过GTM的严格的两阶段提交的跨节点的分布式事务。在数据提交的时候，CN先向每个DN节点发送prepare状态，DN节点返回prepare ok状态后，CN再发送commit状态，最后DN节点返回commit ok状态后才算一次提交完成。

2、技术实现

在分布式数据库中，事务状态保持是确保数据一致性和系统可靠性的重要特性之一，主要依靠关键技术：

• 分布式事务协议：GBase 8c采用先进的分布式事务协议，确保跨多个节点的事务操作能够保证ACID特性，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。
• 数据多副本：为了提高数据的可用性和耐故障能力，GBase 8c支持数据多副本策略。数据可以存储在多个节点上，即使部分节点发生故障，也能通过其他副本继续提供服务。
• 故障恢复机制：当系统中的节点发生故障时，GBase 8c能够利用其他节点的数据副本进行故障恢复，保证事务的完成。
• 2PC（Two Phase Commitment Protocol）两阶段提交协议：实现分布式事务的关键就是两阶段提交协议。

传统2PC事务在全局提交阶段可能出现失败，例如协调器宕机，这会造成集群内各节点的提交状态不一致，破坏事务的原子性。并且2PC事务持续占有已申请的锁，可能造成其它事务因无法获取锁而不能继续执行，严重时可能导致整个集群卡住，因此，需要检查这类事务的存在，并尽快推进2PC的完成（提交或回滚）。

针对上述问题，GBase 8c优化了2PC的执行流程，设计了2PC事务状态保持功能，确保集群能够持续提供服务。

当协调器宕机之后，系统会立即检测到该问题，并自动选出一个健康的协调器，由后者接管故障协调器上所有未完成的2PC事务。新的协调器会收集所有未完成的2PC事务，检查各个2PC事务所处阶段，并决定每个2PC事务应当提交或者回滚，然后发送相应指令到各个参与者，完成全部2PC流程，确保系统不被阻塞。

如上图所示两阶段提交事务处理过程中：

1. CN2节点正常下发事务Prepare状态；

2. 三个DN节点正常返回事务Prepare OK状态；

3. CN2节点正常下发事务Commit状态；

4. DN1节点返回Commit OK状态且DN2、DN3还未完成Commit OK状态提交时，CN2节点宕机；

5. 此时CN3节点检测到CN2节点宕机，会自动接管CN2未完成的事务和状态；

6. DN2、DN3节点重新提交Commit OK状态至CN3节点，并完成该两阶段提交过程。

CN3节点接管事务后，无需重复前面已经成功提交的事务状态，可以继续完成宕机的CN2节点未完成的状态来完成本次事务。整个过程对上层业务无感知，数据库集群内任意节点宕机均不会造成死锁或异常等待情况。

3、应用案例分析

假设一个在线电商平台，使用GBase 8c管理其商品库存和用户订单信息。在大型促销活动期间，平台需要处理大量并发订单，同时更新库存信息。事务状态保持特性能够支撑满足如下业务场景：

• 峰值订单处理：在活动高峰期，GBase 8c的事务状态保持机制确保每个订单的处理不会相互干扰，每个订单更新的库存信息都保持一致性，避免了超卖现象。
• 系统故障应对：活动期间，如果某个数据库节点发生故障，GBase 8c自动故障转移机制能够迅速介入，保证订单处理不受影响，同时事务日志帮助快速恢复故障节点的数据。
• 数据恢复与完整性：通过事务日志，GBase 8c能够在系统恢复后，对未完成的事务进行回放，确保所有订单数据都能准确无误地反映最终用户的实际交易情况。

GBase 8c的事务状态保持特性为分布式数据库在高并发、高可用性要求的环境中的应用，提供了坚实的技术支持，确保了数据的一致性和系统的稳定性，为各类应用提供了可靠的数据服务。

原文链接：

https://www.gbase.cn/community/post/3866

更多精彩内容尽在南大通用GBase技术社区，南大通用致力于成为用户最信赖的数据库产品供应商。