我們已經了解了四種分布式事務解決方案，2pc【鏈結】、tcc【鏈結】、可靠訊息最終一致性【鏈結】、最大努力通知【鏈結】，每種解決方案我們通過案例開發進行學習，本章節我們結合網際網路金融專案中的業務場景，來進行分布式事務解決方案可行性分析。
p2p金融又叫 p2p信貸。其中 p2p是 peer-to-peer 或 person-to-person 的簡寫，意思是：個人對個人。p2p金融指 個人與個人間的小額借貸交易，一般需要借助電子商務專業網路平台幫助借貸雙方確立借貸關係並完成相關交易手續。借款者可自行發布借款資訊，包括金額、利息、還款方式和時間，實現自助式借款。投資者根據借款人發布的資訊，自行決定出借金額，實現自助式借貸。 目前，國家對 p2p行業的監控與規範性控制越來越嚴格，出台了很多政策來對其專項整治。並主張採用「銀行存管模式」來規避 p2p平台挪用借投人資金的風險，通過銀行開發的「銀行存管系統」管理投資者的資金，每位 p2p平台使用者在銀行的存管系統內都會有乙個獨立賬號，平台來管理交易，做到資金和交易分開，讓 p2p平台不能接觸到資金， 就可以一定程度避免資金被挪用的風險。
什麼是銀行存管模式】：
銀行存管模式：此種模式下，涉及到2套賬戶體系，p2p平台和銀行各一套賬戶體系。投資人在 p2p平台註冊後，會同時跳轉到銀行再開乙個電子賬戶，2個賬戶間有一一對應的關係。當投資人投資時，資金進入的是平台在銀行為投資人開設的二級賬戶中，每一筆交易，是由銀行在投資人與借款人間的交易劃轉，p2p 平台僅能看到資訊的流動。
標的：p2p業內，習慣把借款人發布的投資專案稱為「標的」。
發標：借款人在 p2p平台中建立並發布「標的」過程。
投標：投資人在認可相關借款人之後進行的一種借貸行為，對自己中意的借款標的進行投資操作，乙個借款標的可由單個投資人或多個投資人承接。
滿標：單筆借款集齊所有借款資金即為滿標，計息時間是以標滿當日開始計息，投資人較多的平台多數會當天滿標。
模組說明：
統一賬號服務：使用者的登入賬號、密碼、角色、許可權、資源等系統級資訊的管理，不包含使用者業務資訊。
使用者中心：提供使用者業務資訊的管理，如會員資訊、實名認證資訊、繫結銀行卡資訊等，「使用者中心」的每個使用者與「統一賬號服務」中的賬號關聯。
交易中心：提供發標、投標等業務。
還款服務：提供還款計畫的生成、執行、記錄與歸檔。
銀行存管系統(模擬)：模擬銀行存管系統，進行資金的存管，劃轉。
：使用者向使用者中心發起註冊請求，使用者中心儲存使用者業務資訊，然後通知統一賬號服務新建該使用者所對應登入賬號。
解決方案分析：針對註冊業務，如果使用者與賬號資訊不一致，則會導致嚴重問題，因此該業務對一致性要求較為嚴格，即當使用者服務和賬號服務任意一方出現問題都需要回滾事務。
根據上述需求進行解決方案分析：
【1】採用可靠訊息一致性方案：可靠訊息一致性要求只要訊息發出，事務參與者接到訊息就要將事務執行成功，不存在回滾的要求，所以不適用。
最大努力通知方案：最大努力通知表示發起通知方執行完本地事務後將結果通知給事務參與者，即使事務參與者執行業務處理失敗發起通知方也不會回滾事務，所以不適用。
採用 seata實現 2pc：在使用者中心發起全域性事務，統一賬戶服務為事務參與者，使用者中心和統一賬戶服務只要有一方出現問題則全域性事務回滾，符合要求。實現方法如下：
1、使用者中心新增使用者資訊，開啟全域性事務；
2、統一賬號服務新增賬號資訊，作為事務參與者；
3、其中一方執行失敗 seata對 sql進行逆操作刪除使用者資訊和賬號資訊，實現回滾；
採用 hmily實現：tcc也可以實現使用者中心和統一賬戶服務只要有一方出現問題則全域性事務回滾，符合要求。 實現方法如下：
1、使用者中心try：新增使用者，狀態為不可用，confirm：更新使用者狀態為可用，cancel：刪除使用者；
2、統一賬號服務 try：新增賬號，狀態為不可用，confirm：更新賬號狀態為可用，cancel：刪除賬號；
：使用者向使用者中心提交開戶資料，使用者中心生成開戶請求後並重定向至銀行存管系統開戶頁面。使用者設定存管密碼並確認開戶後，銀行存管立即返回「請求已受理」。在某一時刻，銀行存管系統處理完該開戶請求後，將呼叫**位址通知處理結果，若通知失敗，則按一定策略重試通知。同時，銀行存管系統應提供開戶結果查詢的介面，供使用者中心校對結果。
解決方案分析：p2p平台的使用者中心與銀行存管系統之間屬於跨系統互動，銀行存管系統屬於外部系統，使用者中心無法干預銀行存管系統，所以使用者中心只能在收到銀行存管系統的業務處理結果通知後積極處理，開戶後的使用情況完全由使用者中心來控制。
根據上述需求進行解決方案分析：
採用 seata實現 2pc：需要侵入銀行存管系統的資料庫，由於它的外部系統，所以不適用；
採用 hmily實現 tcc：tcc侵入性更強，所以不適用；
基於 mq的可靠訊息一致性
：管理員對某標的滿標審批通過，交易中心修改標的狀態為「還款中」，同時要通知還款服務生成還款計畫。
解決方案分析：生成還款計畫是乙個執行時間較長的業務，不建議阻塞主業務流程，此業務對一致性要求較低。
根據上述需求進行解決方案分析：
採用 seata實現 2pc：seata在事務執行過程會進行資料庫資源鎖定，由於事務執行時長較長會將資源鎖定較長時間，所以不適用。
採用 hmily實現 tcc：本需求對業務一致性要求較低，因為生成還款計畫的時長較長，所以不要求交易中心修改標的狀態為「還款中」就立即生成還款計畫，所以本方案不適用。
基於mq的可靠訊息一致性：滿標審批通過後由交易中心修改標的狀態為「還款中」並且向還款服務傳送訊息，還款服務接收到訊息開始生成還款計畫，基本於 mq的可靠訊息一致性方案適用此場景。
最大努力通知方案：滿標審批通過後由交易中心向還款服務傳送通知要求生成還款計畫，還款服務並且對外提供還款計畫生成結果校對介面供其它服務查詢，最大努力通知方案也適用本場景。
事務的基本概念以及本地事務特性。cap、base理論的概念。2pc、tcc、可靠訊息最終一致性、最大努力通知各型別原理及特性。不同分布式事務型別的應用場景討論。
2pc
tcc
可靠訊息最終一致性
最大努力通知
一致性強一致性
強一致性
最終一致
最終一致
吞吐量低中高
高實現複雜度易難
中易【2pc】最大的詬病是乙個阻塞協議。rm在執行分支事務後需要等待 tm的決定，此時服務會阻塞並鎖定資源。由於其阻塞機制和最差時間複雜度高，因此，這種設計不能適應隨著事務涉及的服務數量增加而擴充套件的需要，很難用於併發較高以及子事務生命週期較長（long-runningtransactions）的分布式服務中。如果拿 tcc事務的處理流程與 2pc兩階段提交做比較，2pc通常都是在跨庫的 db層面，而 tcc則在應用層面的處理，需要通過業務邏輯來實現。這種分布式事務的實現方式的優勢在於，可以讓應用自己定義資料操作的粒度，使得降低鎖衝突、提高吞吐量成為可能。而不足之處則在於對應用的侵入性非常強，業務邏輯的每個分支都需要實現try、confirm、cancel三個操作。此外，其實現難度也比較大，需要按照網路狀態、系統故障等不同的失敗原因實現不同的回滾策略。典型的使用場景：登入送優惠券等。
【可靠訊息最終一致性事務】適合執行周期長且實時性要求不高的場景。引入訊息機制後，同步的事務操作變為基於訊息執行的非同步操作，避免了分布式事務中的同步阻塞操作的影響，並實現了兩個服務的解耦。典型的使用場景：註冊送積分，登入送優惠券等。
【最大努力通知】是分布式事務中要求最低的一種，適用於一些最終一致性時間敏感度低的業務；允許發起通知方處理業務失敗，在接收通知方收到通知後積極進行失敗處理，無論發起通知方如何處理結果都會不影響到接收通知方的後續處理；發起通知方需提供查詢執**況介面，用於接收通知方校對結果。典型的使用場景：銀行通知、支付結果通知等。
【總結】：在條件允許的情況下，我們盡可能選擇本地事務單資料來源，因為它減少了網路互動帶來的效能損耗，且避免了資料弱一致性帶來的種種問題。若某系統頻繁且不合理的使用分布式事務，應首先從整體設計角度觀察服務的拆分是否合理，是否高內聚低耦合？是否粒度太小？分布式事務一直是業界難題，因為網路的不確定性，而且我們習慣於拿分布式事務與單機事務 acid做對比。無論是資料庫層的xa、還是應用層tcc、可靠訊息、最大努力通知等方案，都沒有完美解決分布式事務問題，它們不過是各自在效能、一致性、可用性等方面做取捨，尋求某些場景偏好下的權衡。
（六）分布式事務綜合案例分析
1.1.p2p介紹 p2p金融又叫p2p信貸。其中p2p是 peer to peer 或 person to person 的簡寫，意思是 個人對個人。p2p金融指個人與個人間的小額借貸交易，一般需要借助電子商務專業網路平台幫助借貸雙方確立借貸關係並完成相關交易手續。借款者可自行發布借款資訊，包括金...
分布式事務分析
近期公司專案基於微服務架構需要涉及到實現一套分布式事務。經過幾天在網上查閱資料發現大部分文章只是講解了具體的其中乙個模型。因此在這裡做乙個總結 自己的一些感悟和看法。cap理論本身並不是一套和事務相關的理論，而是用來解釋分布式系統的理論。但是用來分析分布式事物的邊界非常適合。關於cap理論，可以檢視...
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...