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

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.總體業務流程

7.1.2.模塊說明

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

7.2.注冊賬號案例分析

7.2.1.業務流程

采用用戶、賬號分離設計（這樣設計的好處是，當用戶的業務資訊發生變化時，不會影響的認證、授權等系統機制），因此需要保證用戶資訊與賬號資訊的一致性，

7.2.2.解決方案分析

針對注冊業務，如果用戶與賬號資訊不一致，則會導致嚴重問題，因此該業務對一致性要求較為嚴格，即當用戶服務和賬號服務任意一方出現問題都需要回滾事務，
根據上述需求進行解決方案分析 ：
1、采用可靠訊息一致性方案
可靠訊息一致性要求只要訊息發出，事務參與者接到訊息就要將事務執行成功，不存在回滾的要求，所以不適用，
2、采用最大努力通知方案
最大努力通知表示發起通知執行完本地事務后將結果通知給事務參與者，即使事務參與者執行業務處理失敗發起通知方也不會回滾事務，所以不適用，
3、采用Seata實作2PC
在用戶中心發起全域事務，統一賬戶服務為事務參與者，用戶中心和統一賬戶服務只要有一方出現問題則全域事務回滾，符合要求，
實作方法如下 ：
1、用戶中心添加用戶資訊，開啟全域事務
2、統一賬號服務添加賬號資訊，作為事務參與者
3、其中一方執行失敗Seata對SQL進行逆操作洗掉用戶資訊和賬號資訊，實作回滾，
4、采用Hmily實作TCC
TCC也可以實作用戶中心和統一賬戶服務只要有一方出現問題則全域事務回滾，符合要求，
實作方法如下 ：
1、用戶中心
try ：添加用戶，狀態為不可用
confirm ：更新用戶賬戶為可用
cancel ：洗掉用戶
2、統一賬號服務
try ：添加賬號，狀態不可用
confirm ：更新賬號狀態為可用
cancel ：洗掉賬號

7.3.存管開戶

7.3.1.業務流程

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

用戶向用戶中心提交開戶資源，用戶中心生成開戶請求號并重定向至銀行存管系統開戶頁面，用戶設定存管密碼并確認開戶后，銀行存管立即回傳“請求已受理”，在某一個時刻，銀行存管系統處理完該開戶請求后，將呼叫回呼地址通知處理結果，若通知失敗，則按一定策略重試通知，同時，銀行存管系統應提供開戶結果查詢的介面，供用戶中心校對結果，

7.3.2.解決方案分析

P2P平臺的用戶中心與銀行存管系統之間屬于跨系統互動，銀行存管系統屬于外部系統，用戶中心無法干預銀行存管系統，所以用戶中心只能在收到銀行存管系統的業務處理結果通知后積極處理，開戶后的使用情況完全由用戶中心開控制，
根據上述需求進行解決方案分析 ：
1、采用Seata實作2PC
需要侵入銀行存管系統的資料庫，由于它的外部系統，所以不適用，
2、采用Hmily實作TCC
TCC侵入性更強，所以不適用，
3、基于MQ的可靠訊息一致性
如果讓銀行存管系統監聽MQ則不合適，因為它的外部系統，如果銀行存管系統將訊息發給MQ用戶中心監聽MQ是可以的，但是由于相對銀行存管系統來說用戶中心屬于外部系統，銀行存管系統是不會讓外部系統直接監聽自己的MQ的，基于MQ的通信協議也不方便外部系統間的互動，所以本方案不適合，
4、最大努力通知方案
銀行存管系統內部使用MQ，銀行存管系統處理完業務后將處理結果發給MQ，由銀行存管的通知程式專門發送通知，并且采用互聯網協議通知給第三方系統（用戶中心），
下圖中發起通知即銀行存管系統 ：

7.4.滿標審核

7.4.1.業務流程

在借款人標的募集夠所有的資金后，P2P運營管理員審批該標的，觸發放款，并開啟還款流程，

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

7.4.2.解決方案分析

生成還款計劃是一個執行時長較長的業務，不建議阻塞主業務流程，此業務對一致性要求較低，
根據上述需求進行解決方案分析 ：
1、采用Seata實作2PC
Seata在事務執行程序會進行資料庫資源鎖定，由于事務執行時長較長會將資源鎖定較長時間，所以不適用，
2、采用Hmily實作TCC
本需求對業務一致性要求較低，因為生成還款計劃的時長較長，所以不要求交易中心修改標的狀態為“還款中”就立即生成還款計劃，所以本方案不適用，
3、基于MQ的可靠訊息一致性
滿標批通過后由交易中心修改標的狀態為“還款中”并且向還款服務發送訊息，還款服務接收到訊息開始生成還款計劃，基于MQ的可靠訊息一致性方案適用此場景，
4、最大努力通知方案
滿標審批通過后交易中心向還款服務發送通知要求生成還款計劃，還款服務并且對外提供還款計劃生成結果校對介面供其他服務查詢，最大努力通知也適用本場景，

分布式事務對比分析 ：

各種方案的優缺點 ：
2PC最大的詬病是阻塞協議，RM在執行分支事務后需要等待TM的決定，此時服務會阻塞并鎖定資源，由于其阻塞機制和最差時間復雜度高，因此，這種設計不能適應隨著事務涉及的服務數量增加而擴展的需要，很難用于并發較高以及子事務生命周期較長（long-running
transactions)的分布式服務中，

如果拿TCC事務的處理流程與2PC兩階段提交做比較，2PC通常都是在跨庫的DB層面，而TCC則在應用層面的處理，需要通過業務邏輯來實作，這種分布式事務的實作方式的優勢在于，可以讓應用自己定義資料操作的粒度，使得降低鎖沖突，提高吞吐量成為可能，
而不足之處則在于對應用的侵入性非常強，業務邏輯的每個分支都需要實作try、confirm、cancel三個操作，此外，其實作難度也比較大，需要按照網路狀態、系統故障等不同的失敗原因實作不同的回滾策略，典型的使用場景 ：滿，登錄送優惠卷等，

可靠訊息最終一致性事務適合執行周期長且實時性要求不高的場景，引入訊息機制后，同步的事務操作變為基于訊息執行的異步操作，避免來分布式事務中的同步阻塞操作的影響，并實作來兩個服務的解耦，典型的使用場景 ：注冊送積分，登錄送優惠卷等，

最大努力通知是分布式事務中要求最低的一種，適用于一些最終一致性時間敏感度低的業務；允許發起通知方處理業務失敗，在接收通知發收到通知后積極進行失敗處理，無論發起通知方如何處理結果都不會影響到接收通知方的后續處理；發起通知方需提供查詢執行情況介面，用于接收通知方校對結果，典型的使用場景 ：銀行通知、支付結果通知等，

總結 ：
在條件允許的情況下，我們盡可能選擇本地事務單資料源，因為它減少來網路互動帶來的性能損耗，且避免來資料若一致性帶來的種種問題，若某系統頻繁不合理的使用分布式事務，應首先從整體設計角度觀察服務的拆分是否合理，是否高內聚低耦合？是否粒度太小？分布式事務一直是業界難題，因為網路的不確定性，而且我們習慣于拿分布式事務與單機事務ACID做對比，
無論是資料庫曾的XA、還是應用層TCC、可靠訊息、最大努力通知等方案，都沒有完美解決分布式事務問題，他們不過是各自在性能、一致性、可用性等方面做取舍，尋求某些場景偏好下的權衡，

標籤：架構設計

上一篇：學習重構(5)-簡化條件運算式

下一篇：Spring基礎——IOC九種bean宣告方式