團隊在微服務(wù)環(huán)境中必須處理的眾多復(fù)雜問題之一就是事務(wù)。跨越多個微服務(wù)的事務(wù)。與單體應(yīng)用程序不同，單體應(yīng)用程序的事務(wù)通常使用單個數(shù)據(jù)庫和 @Transactional
進行管理 注解，在微服務(wù)中，每個服務(wù)往往都有自己的數(shù)據(jù)庫，使得分布式事務(wù)變得更加復(fù)雜。這是有關(guān)如何在 Spring Boot 中有效處理這些分布式事務(wù)的指南。

首先，讓我們先就什么是交易達成一致。

事務(wù)是計算或數(shù)據(jù)庫環(huán)境中的一個工作單元，被視為單個不可分割的操作。它代表一系列必須一起成功或一起失敗的操作或步驟，即使在發(fā)生意外事件（例如斷電或網(wǎng)絡(luò)故障）時也能確保數(shù)據(jù)的一致性和完整性。

在數(shù)據(jù)庫上下文中，事務(wù)可能涉及多個查詢，例如創(chuàng)建、更新或刪除記錄。交易通常遵循四個基本屬性，稱為 ACID 屬性：

a. 原子性 - 事務(wù)中的所有操作都被視為一個單元。要么所有操作成功，要么全部失敗。

b. 一致性 - 事務(wù)將系統(tǒng)從一種有效狀態(tài)轉(zhuǎn)移到另一種有效狀態(tài)，從而保持數(shù)據(jù)有效性。

c. 隔離 - 事務(wù)是隔離執(zhí)行的，這意味著中間狀態(tài)對其他事務(wù)不可見。

d. 持久性 - 事務(wù)一旦提交，其更改就是永久性的，并且在系統(tǒng)崩潰時也能幸存。

---

一個短篇故事

在一個繁忙的電子商務(wù)應(yīng)用程序中，想象一下客戶 Alice 訂購了一臺新筆記本電腦、一個配件和快遞。以下是她的訂單如何在由 OrderSagaOrchestrator 管理的系統(tǒng)中流動的幕后故事。

在一個繁忙的電子商務(wù)應(yīng)用程序中，想象一下客戶 Alice 訂購了一臺新筆記本電腦、一個配件和快遞。以下是她的訂單如何在由 OrderSagaOrchestrator 管理的系統(tǒng)中流動的幕后故事。

Alice 輸入付款和送貨信息后點擊“立即訂購”。此操作啟動了一個稱為傳奇的流程，這是一系列精心策劃的交易，以確保她的訂單從頭到尾得到正確處理。

第 1 步：付款處理
saga 編排器首先檢查 PaymentService，發(fā)起調(diào)用以從 Alice 的帳戶中扣除所需的金額。調(diào)用 paymentService.processPayment() 方法，授權(quán) Alice 支付。

第2步：庫存預(yù)訂
一旦付款成功，協(xié)調(diào)器就會轉(zhuǎn)移到 InventoryService，在那里為 Alice 保留特定的筆記本電腦型號和配件。此預(yù)訂步驟至關(guān)重要，以便在訂單仍在處理期間，庫存不會售完或交給其他客戶。

第 3 步：發(fā)貨啟動
成功預(yù)訂庫存后，saga 協(xié)調(diào)器將聯(lián)系 ShippingService。在這里，shippingService.initiateShipping() 啟動物流，確保物品包裝好并準備好運送到 Alice 的地址。

處理失敗：補償邏輯

但是在分布式環(huán)境中，任何一步都可能出錯。如果由于物流錯誤而導(dǎo)致發(fā)貨失敗，或者由于庫存差異而實際上無法履行庫存怎么辦？協(xié)調(diào)器已準備好補償策略。

如果拋出異常，協(xié)調(diào)器將啟動補償事務(wù)以回滾整個過程，因此 Alice 不會為她不會收到的物品付費：

3.1。取消發(fā)貨 - 協(xié)調(diào)器調(diào)用shippingService.cancelShipping()，停止發(fā)貨。

3.2。釋放庫存 - 然后觸發(fā) inventoryService.releaseInventory()，釋放 Alice 的保留物品，以便其他客戶可以購買它們。

3.3。退款 - 最后，它調(diào)用 paymentService.refund() 來退還 Alice 的付款，確保她不會為訂單付費。

最后，這個精心策劃的傳奇確保了 Alice 的體驗流暢且一致，如果出現(xiàn)任何問題，都會以維護系統(tǒng)完整性的方式解決。這就是微服務(wù)中分布式事務(wù)和補償邏輯的魔力。

---

現(xiàn)在我們知道了什么是事務(wù)并了解了事務(wù)可能有用的現(xiàn)實場景，讓我們深入研究如何在分布式環(huán)境中實現(xiàn)此功能。

團隊可以使用一些關(guān)鍵方法來解決這個問題

1。 SAGA 模式： Saga 模式是微服務(wù)架構(gòu)中處理分布式事務(wù)最廣泛使用的模式之一。傳奇是每個服務(wù)獨立執(zhí)行的本地事務(wù)序列。 saga 中的每一步都會通過一個操作來補償，如果 saga 失敗，該操作會撤消該步驟。

Saga 模式可以通過兩種主要方式實現(xiàn)：

1. a。 基于編排的 SAGA： 事務(wù)中涉及的每個服務(wù)都會偵聽事件并執(zhí)行其事務(wù)。完成后，它會發(fā)出一個事件來觸發(fā)傳奇中的下一步。如果某個步驟失敗，則會觸發(fā)補償事件以撤消之前的步驟。

2. b。 基于編排的 SAGA： 集中式服務(wù)（saga 編排器）協(xié)調(diào) saga 的步驟。它確定操作順序并管理發(fā)生故障時的補償。

2。兩階段提交（2PC）： 雖然兩階段提交協(xié)議通常用于單體系統(tǒng)，但它可以通過 Atomikos 或 Bitronix 等分布式事務(wù)管理器跨分布式系統(tǒng)使用。但是，我不推薦這種方法，因為它在微服務(wù)上下文中存在一些限制，因為它會導(dǎo)致高延遲并且容錯能力較差。如果我是你，我通常會避免這種方法，而選擇 Saga 模式。

3。事件驅(qū)動架構(gòu)： 使用事件驅(qū)動方法，服務(wù)通過事件進行通信，特別適合處理分布式事務(wù)。這種方法與 Saga 模式非常吻合。每個服務(wù)獨立執(zhí)行其事務(wù)，然后發(fā)出一個事件以通知其他服務(wù)有關(guān)結(jié)果。這些事件可以使用 Apache Kafka、RabbitMQ 或其他消息代理來處理。

現(xiàn)在，讓我們看看它在代碼中是如何工作的。

saga 模式有多種風(fēng)格，但在本文中，我將嘗試在 Spring Boot 中實現(xiàn)基于編排的 Saga 模式：

第 1 步： 定義 Saga Orchestrator：
在這里，我將創(chuàng)建一個簡單的服務(wù)來充當(dāng)協(xié)調(diào)器，負責(zé)協(xié)調(diào)事務(wù)。

該服務(wù)將定義傳奇的流程，以正確的順序調(diào)用每個服務(wù)，并在需要時處理補償事務(wù)。

@Service
public class OrderSagaOrchestrator {

    @Autowired
    private PaymentService paymentService;

    @Autowired
    private InventoryService inventoryService;

    @Autowired
    private ShippingService shippingService;

    public void createOrderSaga(Order order) {
        try {
            paymentService.processPayment(order.getPaymentDetails());
            inventoryService.reserveInventory(order.getItems());
            shippingService.initiateShipping(order.getShippingDetails());
        } catch (Exception e) {
            // Compensation logic
            shippingService.cancelShipping(order.getShippingId());
            inventoryService.releaseInventory(order.getItems());
            paymentService.refund(order.getPaymentId());
        }
    }
}

第 2 步： 在每個服務(wù)中創(chuàng)建本地事務(wù)和補償方法：

每個服務(wù)都應(yīng)該有自己的事務(wù)來完成其在傳奇中的步驟，并在需要時使用另一個事務(wù)來補償它。這是大概的結(jié)構(gòu)。

@Service
public class PaymentService {

    @Transactional
    public void processPayment(PaymentDetails details) {
        // Perform payment logic
    }

    @Transactional
    public void refund(String paymentId) {
        // Perform refund logic
    }
}

第 3 步： 基于事件的通信（可選，用于編排）：每個服務(wù)都可以發(fā)出事件來通知其他人交易的結(jié)果。

public class PaymentService {

    private final ApplicationEventPublisher eventPublisher;

    public PaymentService(ApplicationEventPublisher eventPublisher) {
        this.eventPublisher = eventPublisher;
    }

    public void processPayment(PaymentDetails details) {
        // Process payment
        eventPublisher.publishEvent(new PaymentProcessedEvent(this, details));
    }
}

第 4 步： 采取措施保證數(shù)據(jù)一致性： 使用冪等性檢查來確保 saga 中的每個步驟僅執(zhí)行一次。這在分布式系統(tǒng)中很重要，因為網(wǎng)絡(luò)故障或重試可能會導(dǎo)致重復(fù)請求。

第 5 步： 使用消息代理來提高可靠性：如果您使用事件來管理傳奇，可以使用像 RabbitMq 的 Kafka 這樣的消息代理持久性，并且可以在服務(wù)暫時不可用時緩沖事件。

第 6 步： 錯誤處理和重試： 將錯誤處理和重試邏輯合并到您的協(xié)調(diào)器和各個服務(wù)中以處理臨時故障。 Spring Retry 在這里很有用，因為它可以在可配置策略中自動重試失敗的操作。

@Service
public class OrderSagaOrchestrator {

    @Autowired
    private PaymentService paymentService;

    @Autowired
    private InventoryService inventoryService;

    @Autowired
    private ShippingService shippingService;

    public void createOrderSaga(Order order) {
        try {
            paymentService.processPayment(order.getPaymentDetails());
            inventoryService.reserveInventory(order.getItems());
            shippingService.initiateShipping(order.getShippingDetails());
        } catch (Exception e) {
            // Compensation logic
            shippingService.cancelShipping(order.getShippingId());
            inventoryService.releaseInventory(order.getItems());
            paymentService.refund(order.getPaymentId());
        }
    }
}

結(jié)論

微服務(wù)中的分布式事務(wù)具有挑戰(zhàn)性，但通過使用 Saga（尤其是編排）和事件驅(qū)動通信等模式，您可以實現(xiàn)可靠且可擴展的解決方案。

Spring Boot 通過提供對事務(wù)管理、事件發(fā)布以及與消息代理集成的支持，使這一切變得更容易。

最后，這個精心策劃的傳奇確保了 Alice 的體驗流暢且一致，如果出現(xiàn)任何問題，都會以維護系統(tǒng)完整性的方式解決。這就是微服務(wù)中分布式事務(wù)和補償邏輯的魔力。

以上是跨多個服務(wù)的事務(wù)操作。一種瘋狂的方法。的詳細內(nèi)容。更多信息請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！