分散式事務，解決方案_ZenDei技術網路在線

"聊聊分散式事務，再說說解決方案" "分散式事務CAP理解論證解決方案" "分散式系統的2PC、3PC詳細分析" "github tcc示例" "分散式事務、重覆消費、順序消費" 一、理論 CAP相關： CAP與BASE相關： "我的博客" 而對於分散式中的問題的解決方案,CAP原則出現,描述如下 ...

聊聊分散式事務，再說說解決方案
 分散式事務CAP理解論證-解決方案
 分散式系統的2PC、3PC詳細分析
 github tcc示例
 分散式事務、重覆消費、順序消費

一、理論

CAP相關：

CAP與BASE相關：我的博客

而對於分散式中的問題的解決方案,CAP原則出現,描述如下:

一致性(Consistency):

像A節點寫入一條信息之後,同一時刻,在其他節點都可以讀到這條信息

可用性(Availability):

多布一些節點A,B,C…,任何時刻,用戶訪問,都應該以可預期的結果返回,而不是瀏覽器報錯,404,500,頁面丟失…等用戶體驗不好的情況發生

分區容忍性(PartitionTolerance):

當各系統模塊間通信出現問題時,設計一個策略,使系統仍可對外提供滿足一致性或可用性

剛接觸cap時,有些不理解分區容忍性,我們自己倒推一下:

為了保證一致性,我們需要各個節點同步消息
為了保證可用性我們可以多部署節點,部分節點掛了仍可對外提供服務
為了保證分區容忍性:此刻卡殼了,怎麼做?沒了一種具體的方式,然而他還是客觀存在的。後來發現:進入了思維盲點:只要在分散式場景中,分區必然存在,那麼如果不處理分區發生時的情況,節點無法通訊時會發生什麼?–此刻如果仍對外提供服務,那麼導致無法同步消息,即保證不了強一致性;如果要保證強一致性,那麼就需要節點阻塞,一直等待通訊恢復,即保證不了可用性.

所以分區容忍性就是:當發生分區問題時,我們使用策略,在一致性和可用性二者間選擇
註意: 無法通信包括網路問題,或者節點機器宕機

誤區: CAP理論中說三者不可兼得,但實際情況是,在分散式場景中分區一定存在,即必須有分區容忍性對應的策略,之後才能在一致性和可用性間二者之間選擇.所以對主流架構來說不是三選二,而是二選一。

對P的理解

很多人可能對分區容忍性不太理解，知乎有一個回答對這個解釋的比較清楚CAP理論中的P到底是個什麼意思？，這裡引用一下：

一個分散式系統裡面，節點組成的網路本來應該是連通的。然而可能因為一些故障，使得有些節點之間不連通了，整個網路就分成了幾塊區域。數據就散佈在了這些不連通的區域中。這就叫分區。
當你一個數據項只在一個節點中保存，那麼分區出現後，和這個節點不連通的部分就訪問不到這個數據了。這時分區就是無法容忍的。
提高分區容忍性的辦法就是一個數據項複製到多個節點上，那麼出現分區之後，這一數據項就可能分佈到各個區里，容忍性就提高了。
然而，要把數據複製到多個節點，就會帶來一致性的問題，就是多個節點上面的數據可能是不一致的。
要保證一致，每次寫操作就都要等待全部節點寫成功，而這等待又會帶來可用性的問題。
總的來說就是，數據存在的節點越多，分區容忍性越高，但要複製更新的數據就越多，一致性就越難保證。為了保證一致性，更新所有節點數據所需要的時間就越長，可用性就會降低。

XA規範：

http://www.jasongj.com/big_data/two_phase_commit/
https://www.cnblogs.com/zhoujinyi/p/5257558.html

XA規範中，事務管理器主要通過以下的介面對資源管理器進行管理

xa_open，xa_close：建立和關閉與資源管理器的連接。
xa_start，xa_end：開始和結束一個本地事務。
xa_prepare，xa_commit，xa_rollback：預提交、提交和回滾一個本地事務。
xa_recover：回滾一個已進行預提交的事務。

XA規範：https://www.cnblogs.com/wt645631686/p/10882998.html

解決方案

一些具體實現

維護本地消息表
使用rocketmq事務消息：https://blog.csdn.net/weixin_40533111/article/details/84451219
兩階段提交協議(2PC)
TCC事務補償機制

使用限制：

a. XA事務和本地事務以及鎖表操作是互斥的

開啟了xa事務就無法使用本地事務和鎖表操作:

mysql> xa start 't1xa';
Query OK, 0 rows affected (0.04 sec)
mysql> begin;
ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global transaction is in the ACTIVE state
mysql> lock table t1 read;
ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global transaction is in the ACTIVE state

開啟了本地事務就無法使用xa事務:

mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> xa start 'rrrr';
ERROR 1400 (XAE09): XAER_OUTSIDE: Some work is done outside global transaction

b. xa start 之後必須xa end，否則不能執行xa commit 和xa rollback

所以如果在執行xa事務過程中有語句出錯了，你也需要先xa end一下，然後才能xarollback。

註意事項:

a. mysql只是提供了xa事務的介面，分散式事務中的mysql實例之間是互相獨立的不感知的。所以用戶必須
自己實現分散式事務的調度器

b. xa事務有一些使用上的bug，參考http://www.mysqlops.com/2012/02/24/mysql-xa-optimize.html

主要是:
“MySQL資料庫的主備資料庫的同步，通過Binlog的複製完成。而Binlog是MySQL資料庫內部XA事務的協調者，並且MySQL資料庫為binlog做了優化——binlog不寫prepare日誌，只寫commit日誌。
所有的參與節點prepare完成，在進行xa commit前crash。crash recover如果選擇commit此事務。由於binlog在prepare階段未寫，因此主庫中看來，此分散式事務最終提交了，但是此事務的操作並未寫到binlog中，因此也就未能成功複製到備庫，從而導致主備庫數據不一致的情況出現。
而crash recover如果選rollback, 那麼就會出現全局不一致（該分散式事務對應的節點，部分已經提交，無法回滾，而部分節點回滾。最終導致同一分散式事務，在各參與節點，最終狀態不一致）”

參考的那篇blog中給出的辦法是修改mysql代碼，這個無法在DBScale中使用。所以可選的替代方案是不使用
主從複製進行備份，而是直接使用xa事務實現同步寫來作為備份。

二、兩階段提交2PC

1. 介紹

兩個角色：

協調者
參與者

兩個階段：

階段一：提交事務請求
階段二：執行事務提交

犧牲了一部分可用性來換取的一致性。解決方案有：springboot+Atomikos or Bitronix

優點：原理簡單，實現方便

缺點：

同步阻塞：在提交的過程中，所有參與者都處於阻塞狀態，大大降低併發度
單點問題：一旦協調者出現問題，則所有參與者處於鎖定狀態，無法對外服務
數據不一致：在階段二，協調者發送了commit之後，發生了局部網路異常或者協調者尚未發送完commit請求就宕機了，導致部分參與者收到commit，導致系統出現不一致
太過保守：協調者在階段一中，參與者出現故障而導致協調者無法獲取到所有參與者的響應，協調者只能依靠超時時間來判斷是否中斷事務。換句話說，沒有完善的容錯機制。

2. 實現

JTA（Java Transaction API）定義了對XA事務的支持。像很多其他的Java規範一樣，JTA僅僅定義了介面，具體的實現則是由供應商(如J2EE廠商)負責提供，目前JTA的實現主要有以下幾種：

J2EE容器所提供的JTA實現(如JBoss)。
獨立的JTA實現：如JOTM（Java Open Transaction Manager），Atomikos。這些實現可以應用在那些不使用J2EE應用伺服器的環境里用以提供分佈事事務保證。

MySQL中的XA實現分為：外部XA和內部XA。前者是指我們通常意義上的分散式事務實現；後者是指單台MySQL伺服器中，Server層作為TM(事務協調者)，而伺服器中的多個資料庫實例作為RM，而進行的一種分散式事務，也就是MySQL跨庫事務；也就是一個事務涉及到同一條MySQL伺服器中的兩個innodb資料庫(因為其它引擎不支持XA)。

三、三階段提交3PC

是二階段的改進版，將二階段的提交事務請求過程一分為二，形成了：

CanCommit：協調者發送事務詢問、參與者反饋
PreCommit：協調者發送預提交請求、參與者事務預提交（執行事務操作，寫undo、redo日誌）、參與者響應
doCommit：協調者發送提交請求、參與者事務提交（事務提交，釋放資源）、參與者響應

在階段二中，參與者可能會響應no，或者協調者等待超時時間後還無法收到所有參與者的反饋，則中斷事務：協調者向所有參與者發送abort請求。參與者無論是收到協調者的abort請求，或者等待協調者請求過程中超時，都會中斷事務。

在階段三中，如果有任一參與者發送了no，或者等待超時後協調者還沒收到所有參與者的反饋，則中斷事務。需要註意的事，進入階段三，可能會有下麵兩種故障：

協調者出現問題
協調者、參與者之間的網路出現問題

無論哪種情況，都會導致參與者無法及時收到來自協調者的doCommit或者abort請求，這種情況，參與者在等待超時後繼續進行事務提交。

優點：

降低了參與者的阻塞範圍（二階段中如果參與者與協調者斷開，參與者abort；三階段，提交），並且能夠在單點故障後繼續達成一致。

缺點：

參與者在收到preCommit後出現網路分區，參與者依然會提交事務，會造成不一致。

四、實現

todo