分佈式事務，解決方案

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

1、理論

CAP相關：

CAP與BASE相關：個人博客

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

一致性(Consistency):

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

可用性(Availability):

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

分區容忍性(PartitionTolerance):

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

剛接觸cap時,有些不理解分區容忍性,咱們本身倒推一下:

1. 爲了保證一致性,咱們須要各個節點同步消息
2. 爲了保證可用性咱們能夠多部署節點,部分節點掛了仍可對外提供服務
3. 爲了保證分區容忍性:此刻卡殼了,怎麼作?沒了一種具體的方式,然而他仍是客觀存在的。後來發現:進入了思惟盲點:只要在分佈式場景中,分區必然存在,那麼若是不處理分區發生時的狀況,節點沒法通信時會發生什麼?–此刻若是仍對外提供服務,那麼致使沒法同步消息,即保證不了強一致性;若是要保證強一致性,那麼就須要節點阻塞,一直等待通信恢復,即保證不了可用性.

因此分區容忍性就是:當發生分區問題時,咱們使用策略,在一致性和可用性兩者間選擇
注意: 沒法通訊包括網絡問題,或者節點機器宕機

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

對P的理解

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

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

XA規範：

http://www.jasongj.com/big_data/two_phase_commit/
http://www.javashuo.com/article/p-uoynwnjq-gm.html

XA規範中，事務管理器主要經過如下的接口對資源管理器進行管理

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

XA規範：http://www.javashuo.com/article/p-htncjnzz-cp.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事務實現同步寫來做爲備份。

2、兩階段提交2PC

1. 介紹

兩個角色：

1. 協調者
2. 參與者

兩個階段：

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

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

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

缺點：

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

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)。

3、三階段提交3PC

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

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

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

在階段三中，若是有任一參與者發送了no，或者等待超時後協調者還沒收到全部參與者的反饋，則中斷事務。須要注意的事，進入階段三，可能會有下面兩種故障：

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

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

優勢：

1. 下降了參與者的阻塞範圍（二階段中若是參與者與協調者斷開，參與者abort；三階段，提交），而且可以在單點故障後繼續達成一致。

缺點：

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

4、實現

todo