sharding-jdbc分布式事務支持：官網https://shardingsphere.apache.org/document/current/cn/features/transaction/
1、本地事務
在不開啟任何分布式事務管理器的前提下，讓每個數據節點各自管理自己的事務。 它們之間沒有協調以及通信的能力，也並不互相知曉其他數據節點事務的成功與否。 本地事務在性能方面無任何損耗，但在強一致性以及最終一致性方面則力不從心。
2、兩階段提交：
XA協議最早的分布式事務模型是由 X/Open 國際聯盟提出的 X/Open Distributed Transaction Processing (DTP) 模型，簡稱 XA 協議。
基於XA協議實現的分布式事務對業務侵入很小。 它最大的優勢就是對使用方透明，用戶可以像使用本地事務一樣使用基於XA協議的分布式事務。 XA協議能夠嚴格保障事務 ACID 特性。
嚴格保障事務 ACID 特性是一把雙刃劍。 事務執行在過程中需要將所需資源全部鎖定，它更加適用於執行時間確定的短事務。 對於長事務來說，整個事務進行期間對數據的獨占，將導致對熱點數據依賴的業務系統並發性能衰退明顯。 因此，在高並發的性能至上場景中，基於XA協議的分布式事務並不是最佳選擇。
3、柔性事務:
如果將實現了 ACID 的事務要素的事務稱為剛性事務的話，那么基於 BASE 事務要素的事務則稱為柔性事務。 BASE 是基本可用、柔性狀態和最終一致性這三個要素的縮寫。
- 基本可用（Basically Available）保證分布式事務參與方不一定同時在線。
- 柔性狀態（Soft state）則允許系統狀態更新有一定的延時，這個延時對客戶來說不一定能夠察覺。
- 而最終一致性（Eventually consistent）通常是通過消息傳遞的方式保證系統的最終一致性。
在 ACID 事務中對隔離性的要求很高，在事務執行過程中，必須將所有的資源鎖定。 柔性事務的理念則是通過業務邏輯將互斥鎖操作從資源層面上移至業務層面。通過放寬對強一致性要求，來換取系統吞吐量的提升。
基於 ACID 的強一致性事務和基於 BASE 的最終一致性事務都不是銀彈，只有在最適合的場景中才能發揮它們的最大長處。 可通過下表詳細對比它們之間的區別，以幫助開發者進行技術選型。
Sharding-JDBC下實現強一致分布式事務需要導入以下依賴：
<!--xa分布式事務--> <dependency> <groupId>io.shardingsphere</groupId> <artifactId>sharding-transaction-2pc-xa</artifactId> <version>3.1.0</version> </dependency> <dependency> <groupId>io.shardingsphere</groupId> <artifactId>sharding-transaction-spring-boot-starter</artifactId> <version>3.1.0</version> </dependency>
默認是用 atomikos 實現的。在 Service 類上加上注解：
@ShardingTransactionType(TransactionType.XA) @Transactional(rollbackFor = Exception.class)