分布式事務，由於我們將單表的數據切片后將存儲在多個數據庫甚至多個數據庫實例中，所以依靠數據庫本身的事務機制不能滿足所有場景的需要，但是我們推薦在一個數據庫實例中的操作盡可能使用本地事務來保證一致性，跨數據庫實例的一系列更新操作需要根據事務路由在不同的數據源中完成，各個數據源之間的更新操作需要通過分布式事務處理。
主流的分布式事務解決方案有三種：兩階段提交協議、最大努力保證模式和事務補償機制。
兩階段提交協議將分布式事務分為兩個階段，一個是准備階段，一個是提交階段，兩個階段都由事務管理器發起。基於兩階段提交協議，事務管理器能夠最大限度地保證跨數據庫操作的事務的原子性，是分布式系統環境下最嚴格的事務實現方法。兩階段提交協議也帶來了性能方面的問題，難於進行水平伸縮，因為在提交事務的過程中，事務管理器需要和每個參與者進行准備和提交的操作的協調，在准備階段鎖定資源，在提交階段消費資源，但是由於參與者較多，鎖定資源和消費資源之間的時間差被拉長，導致響應速度較慢，在此期間產生死鎖或者不確定結果的可能性較大。由於兩階段提交協議是阻塞協議，在極端情況下不能快速響應請求方，因此有人提出了三階段提交協議，解決了兩階段提交協議的阻塞問題，但仍然需要事務管理器在參與者之間協調，才能完成一個分布式事務。
最大努力保證模式，這是一種非常通用的保證分布式一致性的模式，很多開發人員一直在使用，但是並為意識到這是一種模式，該模式適用於對一致性要求並不十分嚴格，但是對性能要求較高的場景。在更新多個資源時，將多個資源的提交盡量延后到最后一刻處理，這樣的話，如果業務流程出現問題，則所有的資源更新都可以回滾，事務仍然保持一致。唯一可能出現問題的情況是在提交多個資源時發生了系統問題，比如網絡問題等，但是這種情況是非常罕見的，一旦出現這種情況，就需要進行實時補償，將已提交的事務進行回滾。
事務補償機制，在對性能要求很高的場景中，兩階段提交協議並不是一種好方案，最大努力保證模式也會使多個分布式操作互相嵌套，有可能互相影響。
無論使用上面哪種方法實現分布式事務，都需要對分庫分表的多個數據源路由事務。如果更新操作在一個數據庫實例內發生，便可以使用數據源的事務來處理。對於跨數據源的事務，可通過在應用層使用最大努力保證模式和事務補償機制來達成事務的一致性。當然，有時我們需要通過編寫程序來選擇數據庫的事務管理器，根據實現方式的不同，可將事務路由具體分為以下三種。一是自動提交事務路由，二是可編程事務路由，三是聲明式事務路由。