赔偿事务管理怎样处理分布式事务不成功的状况?

在分布式数据库中，事务管理牵涉到跨好几个节点数据操作，确保这种实际操作的一致性是一个重要考验。本文详解两阶段提交协议书（2PC）、三阶段递交协议书（3PC）和赔偿事务管理这三种处理分布式事务一致性难题的解决方案。

1. 两阶段提交协议书（2PC）

1.1 什么叫两阶段提交协议书？

两阶段提交协议书是一种分布式事务解决中的经典协议书。它通过引进一个实施者（coordinator）人物角色来保证事项的原子性和一致性。实施者承担追踪参加事项的全部连接点（称之为参加者，participants）状态，并根据这个情况来确定事务管理能否取得成功递交。

1.2 两阶段提交合同的全过程

两阶段提交协议书包含两阶段：

1. 启动阶段（Prepare Phase） ：实施者为所有参加者推送提前准备（Prepare）信息。参加者得到消息后，实行事务操作并把结论储存在临时存储中。随后，参加者回应实施者一个表明事务操作成功与否的“允许”（YES）或“舍弃”（NO）信息。
2. 递交环节（Commit Phase） ：实施者依据参加者回应来确定事务管理能否递交。假如全部参加者都回复我“允许”信息，实施者向参加者推送递交（Commit）信息。参加者得到消息后，将事务操作得到的结果分布式锁，并释放出来锁定的网络资源。假如出现任何参加者回复我“舍弃”信息，实施者向参加者推送回退（Rollback）信息。参加者得到消息后，回滚事务实际操作并释放出来锁定的网络资源。

根据这两阶段，两阶段提交协议书保证了分布式事务的一致性。

2. 三阶段递交协议书（3PC）

2.1 什么是三环节递交协议书？

三阶段递交协议书是两阶段提交合同的改善版本号。它通过引进一个新的“预递交”环节去解决两阶段提交协议书在一些场景中可能造成的堵塞难题。

2.2 三阶段递交合同的全过程

三阶段递交协议书包含三个阶段：

1. 启动阶段（Prepare Phase） ：与两阶段提交合同的启动阶段同样，实施者为所有参加者推送提前准备（Prepare）信息，参加者得到消息后实行事务操作并把结论储存在临时存储中。随后，参加者回应实施者一个表明事务操作成功与否的“允许”（YES）或“舍弃”（NO）信息。

2. 预递交环节（Pre-Commit Phase） ：实施者依据参加者回应来确定事务管理能否递交。假如全部参加者都回复我“允许”信息，实施者向参加者推送预递交（Pre-Commit）信息。参加者得到消息后，会确定备好递交事务管理。随后，参加者回应实施者一个表明预递交状态下的“确定”（ACK）信息。

3. 递交环节（Commit Phase） ：实施者接到全部参加者“确定”消息时，向参加者推送递交（Commit）信息。参加者得到消息后，将事务操作得到的结果分布式锁，并释放出来锁定的网络资源。假如实施者接到一切参加者“舍弃”信息或者在预递交环节请求超时，实施者向参加者推送回退（Rollback）信息。参加者得到消息后，回滚事务实际操作并释放出来锁定的网络资源。

根据这三个阶段，三阶段递交协议书克服了两阶段提交协议书在一些场景中可能造成的堵塞难题，从而提高分布式事务处理易用性。

3. 赔偿事务管理

3.1 什么叫赔偿事务管理？

赔偿事务管理是一种解决分布式事务不成功状况解决方案。在分布式数据库中，事务操作有可能在好几个节点上实行，如果某个节点上的操作失败，全部事务管理必须回退。赔偿事务管理提供了一种回退不成功操控的方式，根据实行反过来的实际操作（赔偿实际操作）来撤消以前的操作。

3.2 赔偿事务管理怎样处理分布式事务不成功的状况？

赔偿事务管理一般依靠一个量化策略的架构设计，在其中每一个事务操作会产生一个事情。当事务管理成功时，系统将根据这个事情去执行对应的赔偿实际操作。比如，如果一个连接点实施了一个“创建订单”实际操作，但另一个节点上的“扣减库存量”操作失败，系统能够实行一个“撤销合作”实际操作往返滚以前的“创建订单”实际操作。

想要实现赔偿事务管理，每一个事务操作都要界定一个反过来的赔偿实际操作。除此之外，系统软件必须纪录每一个实际操作状态，确保在事务管理成功时开启对应的赔偿实际操作。

赔偿事务管理的优势是不需要像两阶段提交协议和三阶段递交协议书那般严格同歩和协调，从而提高全面的扩展性和性能。但是，赔偿事务管理必须为每一个实际操作界定对应的赔偿实际操作，而且需要保证这种赔偿实际操作可以准确地撤消以前的操作，这也许增强了全面的多元性。

3.3 实例

假定我们会有一个简单的银行转帐实际操作，牵涉到2个帐户。正常情况下，我们应该在一个事务管理中进行2个实际操作：从一个帐户扣减金额向另一个帐户加上额度。下列是一个简单化的事例：

public class BankAccount {
    private int balance;

    public BankAccount(int initialBalance) {
        this.balance = initialBalance;
    }

    public void deposit(int amount) {
        balance  = amount;
    }

    public void withdraw(int amount) {
        balance -= amount;
    }
}

假如我们应用赔偿事务管理，我们应该界定每一个操控的反过来实际操作。在这样一个例子中，deposit操控的反过来操作是withdraw，withdraw操控的反过来操作是deposit。下列是一个简化的赔偿事务管理完成：

public class BankTransfer {
    public static void transfer(BankAccount from, BankAccount to, int amount) {
        try {
            from.withdraw(amount);
            to.deposit(amount);
        } catch (Exception e) {
            // 当转帐操作失败时，实行赔偿实际操作
            from.deposit(amount);
            to.withdraw(amount);
        }
    }
}

汇总

在本文，大家阐述了两阶段提交协议书、三阶段递交协议和赔偿事务管理这三种处理分布式事务一致性难题的解决方案。两阶段提交协议书是一种经典分布式事务解决协议书，通过引进实施者人物角色来保证事务管理的一致性。但是，两阶段提交协议书在一些场景中可能造成堵塞。三阶段递交协议书优化了两阶段提交协议书，通过引进一个预递交环节去解决堵塞难题，从而提高分布式事务处理易用性。赔偿事务管理则提供了一种解决分布式事务不成功状况解决方案，根据实行反过来的实际操作来撤消以前的操作。赔偿事务管理的优势是不需要严格同歩和协调，但是可能增强了全面的多元性。

实际应用中，依据系统软件的要求和特性选择适合自己的分布式事务处理措施才是关键。对需要严苛一致性的画面，能够尝试使用两阶段提交协议和三阶段递交协议书。但对于能接受最终一致性的画面，能够尝试使用赔偿事务管理来提升全面的扩展性和性能