分佈式事物之綜合案例分析

7.1系統介紹

7.1.1. P2P介紹

P2P 金融又叫P2P信貸。其中P2P是 peer-to-peer 或 person-to-person 的簡寫，意思是：我的對我的。P2P金融指我的與我的間的小額借貸交易，通常須要藉助電子商務專業網絡平臺幫助借貸雙方確立借貸關係並完成相關交易手續。借款者可自行發佈借款信息，包括金額、利息、還款方式和時間，實現自助式借款;投資者根據借款人發佈的信息，自行決定出借金額，實現自助式借貸。目前，國家對P2P行業的監控與規範性控制愈來愈嚴格，出臺了不少政策來對其專項整治。並主張採用「銀行存管模式」來規避P2P平臺挪用借投人資金的風險，經過銀行開發的「銀行存管系統」管理投資者的資金，每位P2P平臺用戶在銀行的存管系統內都會有一個獨立帳號，平臺來管理交易，作到資金和交易分開，讓P2P平臺不能接觸到資金，就能夠必定程度避免資金被挪用的風險。
什麼是銀行存管模式？
銀行存管模式涉及到2套帳戶體系，P2P平臺和銀行各一套帳戶體系。投資人在P2P平臺註冊後，會同時跳轉到銀行再開一個電子帳戶，2個帳戶間有一一對應的關係。當投資人投資時，資金進入的是平臺在銀行爲投資人開設的二級帳戶中，每一筆交易，是由銀行在投資人與借款人間的交易劃轉，P2P平臺僅能看到信息的流動。

7.1.2.整體業務流程

術語	描述
銀行存管模式	這種模式下，涉及到2套帳戶系統，P2P平臺和銀行各一套帳戶體系。投資人在P2P平臺註冊後，會同時跳轉到銀行再開一個電子帳戶，2個帳戶間有一一對應的關係。當投資人投資時，資金進入的是平臺在銀行爲投資人開設的二級帳戶中，每一筆交易，由銀行在投資人與借款人間的交易劃轉，P2P平臺僅能看到信息的流動。
標的	P2P業內，習慣把借款人發佈的投資項目稱爲「標的」。
發標	借款人在P2P平臺中建立併發布「標的」過程。
投標	投資人在承認相關借款人以後進行額一種借貸行爲，對本身中意的借款標的進行投資操做，一個借款標可由單個投資人或多個投資人承接。
滿標	單筆借款標籌集齊全部借款資金即爲滿標，計息時間是以標滿當日開始計息，投資人較多的平臺多數會當天滿標。

7.1.2.模塊說明

統一帳戶服務
用戶的登陸帳戶、密碼、角色、權限、資源等系統級信息的管理，不包含用戶業務信息。
用戶中心
提供用戶業務信息的管理，如會員信息、實名認證信息、綁定銀行卡信息等，「用戶中心」的每一個用戶與「統一帳戶服務」中的帳號關聯。
交易中心
提供發標、投標等業務。
還款服務
提供還款計劃的生成、執行、記錄與歸檔。
銀行存管系統（模擬）
模擬銀行存管系統，進行資金的存管，劃轉。

7.2.註冊帳號案例分析

7.2.1.業務流程

採用用戶、帳號分離設計（這樣設計的好處是，當用戶的業務信息發生變化時，不會影響的認證、受權等系統機制），所以須要保證用戶信息與帳號信息的一致性。

7.2.2.解決方案分析

針對註冊業務，若是用戶與帳號信息不一致，則會致使嚴重問題，所以該業務對一致性要求較爲嚴格，即當用戶服務和帳號服務任意一方出現問題都須要回滾事務。
根據上述需求進行解決方案分析 ：
一、採用可靠消息一致性方案
可靠消息一致性要求只要消息發出，事務參與者接到消息就要將事務執行成功，不存在回滾的要求，因此不適用。
二、採用最大努力通知方案
最大努力通知表示發起通知執行完本地事務後將結果通知給事務參與者，即便事務參與者執行業務處理失敗發起通知方也不會回滾事務，因此不適用。
三、採用Seata實現2PC
在用戶中心發起全局事務，統一帳戶服務爲事務參與者，用戶中心和統一帳戶服務只要有一方出現問題則全局事務回滾，符合要求。
實現方法以下 ：
一、用戶中心添加用戶信息，開啓全局事務
二、統一帳號服務添加帳號信息，做爲事務參與者
三、其中一方執行失敗Seata對SQL進行逆操做刪除用戶信息和帳號信息，實現回滾。
四、採用Hmily實現TCC
TCC也能夠實現用戶中心和統一帳戶服務只要有一方出現問題則全局事務回滾，符合要求。
實現方法以下 ：
一、用戶中心
try ：添加用戶，狀態爲不可用
confirm ：更新用戶帳戶爲可用
cancel ：刪除用戶
二、統一帳號服務
try ：添加帳號，狀態不可用
confirm ：更新帳號狀態爲可用
cancel ：刪除帳號

7.3.存管開戶

7.3.1.業務流程

根據政策要求，P2P業務必須讓銀行存管資金，用戶的資金在銀行存管系統的帳戶中，而不在P2P平臺中，所以用戶要在銀行存管系統開戶。

用戶向用戶中心提交開戶資源，用戶中心生成開戶請求號並重定向至銀行存管系統開戶頁面。用戶設置存管密碼並確認開戶後，銀行存管當即返回「請求已受理」。在某一個時刻，銀行存管系統處理完該開戶請求後，將調用回調地址通知處理結果，若通知失敗，則按必定策略重試通知。同時，銀行存管系統應提供開戶結果查詢的接口，供用戶中心校對結果。

7.3.2.解決方案分析

P2P平臺的用戶中心與銀行存管系統之間屬於跨系統交互，銀行存管系統屬於外部系統，用戶中心沒法干預銀行存管系統，因此用戶中心只能在收到銀行存管系統的業務處理結果通知後積極處理，開戶後的使用狀況徹底由用戶中心開控制。
根據上述需求進行解決方案分析 ：
一、採用Seata實現2PC
須要侵入銀行存管系統的數據庫，因爲它的外部系統，因此不適用。
二、採用Hmily實現TCC
TCC侵入性更強，因此不適用。
三、基於MQ的可靠消息一致性
若是讓銀行存管系統監聽MQ則不合適，由於它的外部系統。若是銀行存管系統將消息發給MQ用戶中心監聽MQ是能夠的，可是因爲相對銀行存管系統來講用戶中心屬於外部系統，銀行存管系統是不會讓外部系統直接監聽本身的MQ的，基於MQ的通訊協議也不方便外部系統間的交互。因此本方案不適合。
四、最大努力通知方案
銀行存管系統內部使用MQ，銀行存管系統處理完業務後將處理結果發給MQ，由銀行存管的通知程序專門發送通知，而且採用互聯網協議通知給第三方系統（用戶中心）。
下圖中發起通知即銀行存管系統 ：

7.4.滿標審覈

7.4.1.業務流程

在借款人標的募集夠全部的資金後，P2P運營管理員審批該標的，觸發放款，並開啓還款流程。

管理員對某標的滿標審批經過，交易中心修改標的狀態爲「還款中」，同時要通知還款服務生成還款計劃。

7.4.2.解決方案分析

生成還款計劃是一個執行時長較長的業務，不建議阻塞主業務流程，此業務對一致性要求較低。
根據上述需求進行解決方案分析 ：
一、採用Seata實現2PC
Seata在事務執行過程會進行數據庫資源鎖定，因爲事務執行時長較長會將資源鎖定較長時間，因此不適用。
二、採用Hmily實現TCC
本需求對業務一致性要求較低，由於生成還款計劃的時長較長，因此不要求交易中心修改標的狀態爲「還款中」就當即生成還款計劃，因此本方案不適用。
三、基於MQ的可靠消息一致性
滿標批經過後由交易中心修改標的狀態爲「還款中」而且向還款服務發送消息，還款服務接收到消息開始生成還款計劃，基於MQ的可靠消息一致性方案適用此場景。
四、最大努力通知方案
滿標審批經過後交易中心向還款服務發送通知要求生成還款計劃，還款服務而且對外提供還款計劃生成結果校對接口供其餘服務查詢，最大努力通知也適用本場景。

分佈式事務對比分析 ：

各類方案的優缺點 ：
2PC最大的詬病是阻塞協議。RM在執行分支事務後須要等待TM的決定，此時服務會阻塞並鎖定資源。因爲其阻塞機制和最差時間複雜度高，所以，這種設計不能適應隨着事務涉及的服務數量增長而擴展的須要，很難用於併發較高以及子事務生命週期較長（long-running
transactions)的分佈式服務中。

若是拿TCC事務的處理流程與2PC兩階段提交作比較，2PC一般都是在跨庫的DB層面，而TCC則在應用層面的處理，須要經過業務邏輯來實現。這種分佈式事務的實現方式的優點在於，可讓應用本身定義數據操做的粒度，使得下降鎖衝突，提升吞吐量成爲可能。
而不足之處則在於對應用的侵入性很是強，業務邏輯的每一個分支都須要實現try、confirm、cancel三個操做。此外，其實現難度也比較大，須要按照網絡狀態、系統故障等不一樣的失敗緣由實現不一樣的回滾策略。典型的使用場景 ：滿，登陸送優惠卷等。

可靠消息最終一致性事務適合執行週期長且實時性要求不高的場景。引入消息機制後，同步的事務操做變爲基於消息執行的異步操做，避免來分佈式事務中的同步阻塞操做的影響，並實現來兩個服務的解耦。典型的使用場景 ：註冊送積分，登陸送優惠卷等。

最大努力通知是分佈式事務中要求最低的一種，適用於一些最終一致性時間敏感度低的業務；容許發起通知方處理業務失敗，在接收通知發收到通知後積極進行失敗處理，不管發起通知方如何處理結果都不會影響到接收通知方的後續處理；發起通知方需提供查詢執行狀況接口，用於接收通知方校對結果。典型的使用場景 ：銀行通知、支付結果通知等。
總結 ：在條件容許的狀況下，咱們儘量選擇本地事務單數據源，由於它減小來網絡交互帶來的性能損耗，且避免來數據若一致性帶來的種種問題。若某系統頻繁不合理的使用分佈式事務，應首先從總體設計角度觀察服務的拆分是否合理，是否高內聚低耦合？是否粒度過小？分佈式事務一直是業界難題，由於網絡的不肯定性，並且咱們習慣於拿分佈式事務與單機事務ACID作對比。不管是數據庫曾的XA、仍是應用層TCC、可靠消息、最大努力通知等方案，都沒有完美解決分佈式事務問題，他們不過是各自在性能、一致性、可用性等方面作取捨，尋求某些場景偏好下的權衡。