Spring Framework最近宣布將提供對反應式事務管理的支持 。
讓我們深入研究它對R2DBC（SQL數據庫訪問的反應式規范）如何工作。

事務管理是一種模式，而不是特定于技術的。 從這個角度來看，它的屬性和運行時行為是實現技術的功能。

TL; DR：從數據庫的角度來看，命令式和響應式事務的工作原理相同。 從Java的角度來看，命令式事務和反應式事務之間存在一些差異。

讓我們先來看命令式交易。

命令性交易

在命令性事務中，更具體地說，在具有例如攔截器的面向方面的事務管理中，事務狀態通常對于代碼是透明的。 根據底層API，我們可以從某處獲取事務狀態和事務綁定資源。 這個地方通常生活在一個ThreadLocal存儲。 命令性事務假定代碼的所有事務工作都在同一Thread 。

命令性事務的另一個方面是，在進行事務時，所有數據都保留在@Transactional方法內。 諸如JPA之類的工具允許通過Java 8 Stream.進行結果流傳輸Stream. 在任何情況下，流傳輸都需要使用@Transactional方法。 事務正在進行時，任何事務數據都不能離開方法–數據不會逃逸。

我指出這兩個問題是因為它們在被動事務中的行為不同。

資源綁定

在繼續進行被動交易之前，我們需要提高對交易狀態的理解。 事務狀態通常由事務狀態（啟動，提交，回滾）和綁定到事務的資源組成。

事務資源，例如數據庫連接，通常將其事務進度綁定到基礎傳輸連接。 在大多數情況下，這是TCP連接。 如果數據庫連接使用多路復用，則狀態將綁定到會話對象。 在極少數情況下，數據庫操作會接受事務或會話標識符。 因此，我們假設將連接綁定到事務以包含能力最低的方法，因為事務狀態通常無法跨連接移植。

反應性交易

使用反應式編程時，我們希望在使用事務時應用相同級別的便利性（閱讀：使用相同的編程模型），而在使用基于注釋的事務劃分時，最好使用@Transactional方法。 回到交易管理只是一種模式的概念，我們唯一需要交換的就是技術。

反應性事務不再將其事務狀態綁定到ThreadLocal而是綁定到訂戶上下文。 那是與特定執行路徑關聯的上下文。 或者換句話說：每個具體化的反應性序列都具有與其他執行隔離的訂戶上下文。 這已經是命令式交易的第一個區別。

第二個區別是@Transactional方法中的數據轉義。
使用反應式流的反應式編程幾乎全部涉及通過功能反應式運算符進行的數據流和數據流。 與異步API相比，這也是一個主要優點，即異步Publisher者在數據庫驅動程序解碼后立即發出第一個元素，而不是在Future完成之前等待最后一個數據包到達。

反應性交易包含了這一事實。 與命令式事務類似，事務在實際工作之前開始。 當我們通過事務工作產生數據時，數據在事務處于活動狀態時流經Publisher 。 這意味著在活動事務期間數據會逸出我們的@Transactional方法。 更詳細地看，我們將認識到@Transactional方法只是反應性序列中的標記。 我們在方法上考慮不多； 我們寧愿只觀察訂閱和完成過程中發生的影響。
如果在事務處理過程中發生任何錯誤，則在實際事務回滾的同時，我們可能會保留在事務內處理的數據。 這是您的應用程序中要考慮的事情。
通過意圖進行的反應式事務管理不會延遲排放，而不會忽略流屬性。 原子性在應用程序中的權重比流技術高，這是您可以在應用程序中處理的事情。 否則，您將獲得反應式數據流的全部功能。

（B）鎖定

從Java的角度來看，使用R2DBC進行的反應性數據庫訪問是完全非阻塞的。 所有I / O都使用非阻塞套接字進行。 因此，您從R2DBC獲得的是I / O不再阻塞您的線程。 但是，反應性關系數據庫驅動程序符合數據庫通信協議并遵守數據庫行為。
盡管我們不再占用Thread ，但仍然占有數據庫連接，因為這是RDBMS的工作方式-通過命令發送命令。 一些數據庫允許進行輕微的優化，稱為流水線。 在流水線模式下，驅動程序將繼續向連接發送命令，而無需等待上一個命令完成。

通常，在以下情況下可以釋放連接：

一個語句（多個語句）已完成

申請交易完成

我們仍然可以觀察到鎖定會阻止連接。

數據庫鎖

根據您使用的數據庫，您可以觀察MVCC行為或阻止行為，通常是事務鎖定。 對于命令式SQL數據庫事務，我們通常以兩個（b）鎖結束：

應用程序線程被I / O阻止

數據庫鎖

僅當數據庫釋放其鎖時，我們的應用程序才能繼續運行。 釋放鎖還可以解除對應用程序線程的阻塞。
由于非阻塞的I / O，使用反應式數據庫集成不再阻塞應用程序線程。 數據庫鎖定行為保持不變 。 而不是阻塞兩個資源，我們最終得到了阻塞的數據庫連接。

從Java的角度來看，TCP連接便宜。

由于SQL數據庫是如何工作的，我們仍然可以獲得強大的一致性保證。

符合ACID的數據庫是否天生就不會發生反應？

關于SQL數據庫和響應式有以下三種觀點：

• 鎖定：談論反應式時，SQL數據庫并不是最佳的持久性機制。 許多數據庫在運行更新時執行內部鎖定，因此并發訪問受到限制。 某些數據庫應用了MVCC ，從而使鎖定效果更小。 無論如何，繁重的用例可能不太適合您的響應式應用程序，因為對于傳統的SQL數據庫，這可能會導致可伸縮性瓶頸。
• 可伸縮性：SQL數據庫的伸縮性通常比NoSQL差，在NoSQL上，您可以再放置50臺計算機來擴展群集。 借助RedShift，CockroachDB，Yugabyte之類的新SQL數據庫，我們可以比傳統SQL數據庫進行不同的擴展和更好的方式。
• 游標：許多SQL數據庫在其有線協議中都具有響應功能。 這通常類似于分塊讀取。 運行查詢時，響應式驅動程序可以通過獲取少量結果以使驅動程序不致從游標中讀取結果。 讀取第一行后，驅動程序就可以將該行向下發送給其使用者，然后繼續進行下一行。 一旦處理了塊，驅動程序就可以開始處理下一個塊。 如果取消訂閱，驅動程序將停止從游標讀取并釋放它。 這是一個非常強大的安排。

真的有性能優勢嗎？

性能是一個巨大的領域。 在本文的背景下，讓我們關注資源使用和吞吐量。

您不需要對吞吐量做出反應。 您這樣做是為了實現可伸縮性。

有些影響會完全基于背壓影響吞吐量。 背壓是指Subscriber可以通過向其Publisher者報告所請求的條目數來一次處理多少條目的概念。 知道應用程序需要多少行的背壓允許被動驅動程序應用智能預取。
命令性驅動程序通常在前一個數據完成處理時獲取下一個數據塊。 阻塞驅動程序將阻塞基礎連接和線程，直到數據庫答復為止（ 命令獲取模型 ，請求之間的白色區域是等待時間）。
知道客戶端需要多少數據，可以讓反應性驅動程序在應用程序處理前一個數據塊時提取下一個數據塊（ 反應式提取模型 ，其中將等待時間降至最低）。

就資源使用而言，反應性驅動程序不會阻塞線程。 一旦從網絡流中解碼出行，它們就會發出接收到的行。 總而言之，它們在實現過程中帶有GC友好的執行模型。 在組裝期間，GC壓力增加。

結論

您已經了解了命令式和反應式數據庫屬性。 事務管理需要在命令性流程中實現，而與反應式代碼不同。 實現的更改反映出運行時行為略有不同，尤其是在涉及數據轉義時。 通過更改有關延遲和資源使用的性能配置文件，您可以獲得相同的強大一致性保證。

注意：程序性交易管理是有意省略的，因為本文概述了交易管理的內部原理以及命令式交易與反應式交易之間的差異。

翻譯自: https://www.javacodegeeks.com/2019/05/reactive-relational-database-transactions.html

總結

以上是生活随笔為你收集整理的反应型关系数据库事务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。