資料庫不在乙個例項上面，
比如支付寶賬戶表和餘額寶賬戶表顯然不會在同乙個資料庫例項上，他們往往分布在不同的物理節點上，這個時候一定要避免使用本地事務。在跨庫操作中，如果使用本地事務，往往會使本地事務失效，或者造成龐大的伺服器開銷，引發伺服器死掉的極端影響。
本地事務：一般情況下，乙個龐大的資料庫表
需要按照拆分字段進行分離，拆分成多個資料庫例項，這個分離也是有規則的。比如按照使用者userid這個維度進行拆分，無論有多少個表，只要具有同乙個拆分字段，那麼具有相同userid的資料都會存在於乙個物理機器上面。通常情況下，我們在業務處理中，相當大的業務都會使用同樣乙個維度進行操作（因為乙個人使用**買東西，很多操作都是圍繞這個人進行的，比如這個人的訂單，這個人的資金，這個人的瀏覽記錄......這是從購買者的角度上來看的。當然還有從商品的角度上面還看的業務，這個後面再說，我們可以先把從購買者角度上面的歸集起來），張三操作的，只有這乙個人，不會變成李四，這就決定了無論多少個表關聯，都會存在於乙個物理機上面，在不考慮事務時間的情況下，可以放心大膽的使用本地事務了。
異構索引表：乙個人在**買東西，從業務上面來看，不僅僅需要從購買者的角度來操作，還需要從商品的角度上面來操作。對於乙個訂單，假如有從購買者角度的表，我們非常容易的能夠使用購買者id定位到物理庫位置，然後查詢到這個訂單。但是如果要通過商品或者賣家呢？直接查詢的話，因為不知道購買者id，只能進行全庫查詢，造成非常大的開銷。因此，需要建立異構索引表，表結構和資料一模一樣，只能分庫主鍵為商品id。當需要不同的業務時，就需要操作不同的異構索引表。
訊息系統的分布式事務：上面說到了異構索引表，表資料是一樣的，只是因為業務的需要，建立了不同維度的表。但是如何進行資料同步？使用本地事務肯定行不通，在多個資料庫進行分布式事務，開銷非常大的。只能通過訊息系統的分布式事務解決。所有跨庫操作都只能通過這種方式處理。
多個物理節點上面的本地事務：如果需要在多個物理節點使用join操作，如果資料量不太大，就使用小表廣播的方式。如果資料量太大了，那就需要在**方面處理，盡量拆分為當個物理節點上面的事務操作。即分別單獨在乙個物理庫上面執行事務，有多少個資料庫，就執行多少次。
資料庫連線資源：對於乙個資料庫連線，我們通常需要嚴格保證事務的時間，不能無限制的占用資源。因此，在本地事務中，盡量不要使用太大的事務，浪費資料庫資源。
分布式事務實現思路
大體思路是對事務進行 手動控制事務的開啟提交。datasource connect transaction transtaction註解也是aop 自己編寫事務註解zdytranstaction實現transtration裡面的幾個方法，connect也是，對datasource connect t...
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...
阿里開源GTS FESCAR分布式事務
2.進行測試時首先啟動 server專案server類的main方法，accountserviceimpl orderserviceimpl storageserviceimpl實現類的main方法，都是註冊到dubbo中作為各個服務，accountserviceimpl，storageservic...