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

日前，分布式數據庫中間件 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/incubator-shardingsphere-example/tree/dev/sharding-jdbc-example/transaction-example/transaction-base-seata-example/transaction-base-seata-raw-jdbc-example

操作手冊：

1、按照 seata-work-shop 中的步驟，下載并啟動 seata server。

https://github.com/seata/seata-workshop

參考 Step6 和 Step7 即可。

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

3、Run YamlConfigurationTransactionExample.java

關于 ShardingSphere

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

關于 Seata

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