跨微服務的 ACID 事務

banq發表於2021-08-29
微服務

大規模分散式系統上的分散式事務被認為本質上是邪惡的，需要按照CAP 定理，為了避免走彎路，請參考：分散式事務可能是個偽概念以及Shopify如何使用Saga等模式實現電子商務：Shopify如何使用Ruby實現每小時銷售1億美元?。
本文是atomikos商家自己的宣傳文章：
如何跨 REST 微服務實現經典的 ACID 事務？你們中的一些人可能知道我們的TCC用於預訂式互動的基於補償的 REST 事務。它很好而且鬆散耦合，但它不適合想要使用經典回滾而不是補償的場景。這篇文章介紹了另一種設計，我們目前在 Atomikos 正在研究這種設計。
我們將在本文的其餘部分逐步完善規範，以便更容易理解這些概念。

我們將使用以下角色和職責：

REST 應用程式
想象一個（複合）REST 應用程式：

  • 協調整個工作流程
  • 呼叫多個參與者服務
  • 透過協調器服務（如下所述）提交（或回滾）所有參與者服務的工作。

參與服務
參與者服務實際上是一個微服務，它：

  • 呼叫時建立本地 ACID 事務
  • 執行本地資料庫工作
  • 在呼叫結束時保持事務開啟，以便 REST 應用程式稍後提交（如下所述）。

協調員服務
協調器服務是一種專門的實用程式服務，用於協調跨多個參與者服務的兩階段提交。它還在發生故障和/或重新啟動時執行日誌記錄和恢復。更多詳情如下…
最小用例：一起提交或回滾 REST 微服務
最小用例實際上是在這種情況下可以做的最基本的事情：兩個或多個微服務呼叫一起提交或回滾。它是這樣的：

  1. REST 應用程式執行並呼叫任意數量的參與者服務。
  2. 每個參與者服務返回（作為其響應的一部分）AcidParticipantLink 資訊：基本上是可以提交事務的 URI。
  3. REST 應用程式在整個“事務”邏輯中進行時收集所有 AcidParticipantLinks。
  4. REST 應用程式然後要求協調器服務提交（或者，回滾）其工作的所有相關 AcidParticipantLinks

 

更精細的用例：重複呼叫可以共享相同的鎖
前面的場景有效，但同一參與者的重複呼叫將使用不同的本地 ACID 事務，這意味著他們無法看到/訪問資料庫中的相同資料。後續呼叫之間沒有鎖共享。在某些情況下，這可能是可取的，可以按如下方式完成：

  1. REST 應用程式首次呼叫參與者服務並返回一個 AcidParticipantLink。
  2. REST 應用程式提取參與者的事務識別符號（包含在 AcidParticipantLink 中）。
  3. REST 應用程式現在可以第二次呼叫參與者服務，並將事務識別符號作為呼叫的引數。
  4. 參與者服務檢測現有交易識別符號並允許呼叫“加入”現有交易。

其他一切都像前面的場景一樣工作。
 

高階用例：共享資料庫中呼叫者的服務共享鎖
在某些情況下，參與者服務可能需要加入存在於呼叫方的事務，特別是當它們訪問某個共享資料庫時。詳情將在稍後制定，因此請繼續檢視更多資訊！

...
 

相關文章