sharding-jdbc分布式事務支援：官網
1、本地事務
在不開啟任何分布式事務管理器的前提下，讓每個資料節點各自管理自己的事務。 它們之間沒有協調以及通訊的能力，也並不互相知曉其他資料節點事務的成功與否。 本地事務在效能方面無任何損耗，但在強一致性以及最終一致性方面則力不從心。
2、兩階段提交：
xa協議最早的分布式事務模型是由x/open國際聯盟提出的x/open distributed transaction processing (dtp)模型，簡稱 xa 協議。
基於xa協議實現的分布式事務對業務侵入很小。 它最大的優勢就是對使用方透明，使用者可以像使用本地事務一樣使用基於xa協議的分布式事務。 xa協議能夠嚴格保障事務acid特性。
嚴格保障事務acid特性是一把雙刃劍。 事務執行在過程中需要將所需資源全部鎖定，它更加適用於執行時間確定的短事務。 對於長事務來說，整個事務進行期間對資料的獨佔，將導致對熱點資料依賴的業務系統併發效能衰退明顯。 因此，在高併發的效能至上場景中，基於xa協議的分布式事務並不是最佳選擇。
3、柔性事務:
如果將實現了acid的事務要素的事務稱為剛性事務的話，那麼基於base事務要素的事務則稱為柔性事務。base是基本可用、柔性狀態和最終一致性這三個要素的縮寫。
柔性狀態（soft state）則允許系統狀態更新有一定的延時，這個延時對客戶來說不一定能夠察覺。
而最終一致性（eventually consistent）通常是通過訊息傳遞的方式保證系統的最終一致性。
在acid事務中對隔離性的要求很高，在事務執行過程中，必須將所有的資源鎖定。 柔性事務的理念則是通過業務邏輯將互斥鎖操作從資源層面上移至業務層面。通過放寬對強一致性要求，來換取系統吞吐量的提公升。
基於acid的強一致性事務和基於base的最終一致性事務都不是銀彈，只有在最適合的場景中才能發揮它們的最大長處。 可通過下表詳細對比它們之間的區別，以幫助開發者進行技術選型。
sharding-jdbc下實現強一致分布式事務需要匯入以下依賴：
io.shardingsphere
sharding-transaction-2pc-xa
3.1.0
io.shardingsphere
sharding-transaction-spring-boot-starter
3.1.0
預設是用 atomikos 實現的。在 service 類上加上註解：
@shardingtransactiontype(transactiontype.xa)@transactional(rollbackfor = exception.class)
sharding jdbc 分庫分表
sharding官網 環境 jdk8,springboot jpa sharding jdbc 實現分表分庫 導包 io.shardingsphere sharding jdbc spring boot starter 3.1.0 io.shardingsphere sharding jdbc sp...
sharding jdbc分庫分表
1.gradle構建方式載入依賴包 compile group io.shardingsphere name sharding jdbc core version 3.0.0 2.testsourceconfiguration檔案類配置資料庫 configuration public class t...
分庫分表和sharding jdbc
關係型資料庫在大於一定資料量的情況下效能會急劇下降。在面對網際網路海量資料的情況時,所有資料都存於一張表,顯然很容易會達到資料表可承受的資料量閾值。單純分表雖然可以解決資料量過大導致檢索變慢的問題,但無法解決高併發情況下訪問同乙個庫,導致資料庫響應變慢的問題。所以通常水平拆分都至少要採用分庫的方式,...