ShardingSphere x Seata，一致性更強的分佈式數據庫中間件

做者：支付寶技術團隊

原文連接： http://blog.itpub.net/6990479...

日前，分佈式數據庫中間件 ShardingSphere 將 Seata 分佈式事務能力進行整合，旨在打造一致性更強的分佈式數據庫中間件。

背景

數據庫領域，分佈式事務的實現主要包含：兩階段的 XA 和 BASE 柔性事務。

XA 事務底層，依賴於具體的數據庫廠商對 XA 兩階段提交協議的支持。一般，XA 協議經過在 Prepare 和 Commit 階段進行 2PL（2 階段鎖），保證了分佈式事務的 ACID，適用於短事務及非雲化環境（雲化環境下一次 IO 操做大概須要 20ms，兩階段鎖會鎖住資源長達 40ms，所以熱點行上的事務的 TPS 會降到 25/s 左右，非雲化環境一般一次 IO 只需幾毫秒，所以鎖熱點數據的時間相對較低）。

但在 BASE 柔性事務方面，ShardingSphere 提供的接入分佈式事務的 SPI，只適用於對性能要求較高，對一致性要求比較低的業務。

Seata 核心的 AT 模式適用於構建於支持本地 ACID 事務的關係型數據庫。經過整合 Seata，其 AT 模式在一階段提交+補償的基礎上，經過 TC 的全局鎖實現了 RC 隔離級別的支持，可提升 ShardingSphere 的分佈式事務的一致性。

整合方案

整合 Seata AT 事務時，須要把 TM，RM，TC 的模型融入到 ShardingSphere 分佈式事務的 SPI 的生態中。在數據庫資源上，Seata 經過對接 DataSource 接口，讓 JDBC 操做能夠同 TC 進行 RPC 通訊。一樣，ShardingSphere 也是面向 DataSource 接口對用戶配置的物理 DataSource 進行了聚合，所以把物理 DataSource 二次包裝爲 Seata 的 DataSource 後，就能夠把 Seata AT 事務融入到 ShardingSphere 的分片中。

在 Seata 模型中，全局事務的上下文存放在線程變量中，經過擴展服務間的 transport，能夠完成線程變量的傳遞，分支事務經過線程變量判斷是否加入到整個 Seata 全局事務中。而 ShardingSphere 的分片執行引擎一般是按多線程執行，所以整合 Seata AT 事務時，須要擴展主線程和子線程的事務上下文傳遞，這同服務間的上下文傳遞思路徹底相同。

Quick Start

ShardingSphere 已經實現了 base-seata-raw-jdbc-example，你們能夠自行進行嘗試：

https://github.com/apache/inc...

操做手冊：

一、按照 seata-work-shop 中的步驟，下載並啓動 seata server。

https://github.com/seata/seat...

參考 Step6 和 Step7 便可。

二、在每個分片數據庫實例中執行 resources/sql/undo_log.sql 腳本，建立 undo_log 表

三、Run YamlConfigurationTransactionExample.java

關於 ShardingSphere

ShardingSphere 是一套開源的分佈式數據庫中間件解決方案組成的生態圈，它由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar（計劃中）這 3 款相互獨立的產品組成，提供標準化的數據分片、分佈式事務和數據庫治理功能，可適用於如 Java 同構、異構語言、容器、雲原生等各類多樣化的應用場景。目前，已經擁有超過 8000 的 Star，57 位 Contributors。

關於 Seata

Seata 是阿里巴巴和螞蟻金服共同開源的分佈式事務中間件，融合了雙方在分佈式事務技術上的積累，並沉澱了新零售、雲計算和新金融等場景下豐富的實踐經驗，以高效而且對業務 0 侵入的方式，解決微服務場景下面臨的分佈式事務問題。目前，已經擁有超過 9900 的 Star，83 位 Contributors。