【架构】分布式事务
前言
為什么需要分布式事務???
?一、數據庫分庫分表
二、應用SOA化
三、事務的特性
模型-?X/OpenDTP
一、分布式事務概念
二、模型的概念
三、具體應用
互聯網解決方案?
一、業務接口整合，避免分布式事務
?二、最終一致性方案
三、最大努力通知型
小結
前言
?????小編學習分布式事務的過程中，對于分布式事務的產生背景、分布式事務的應用場景以及互聯網中對于分布式系統的解決方案有了一定的了解，下面簡單地做一下總結。
??????????????????????????????????????????????
為什么需要分布式事務???
?一、數據庫分庫分表
?1.如果數據庫單表一年產生的數據超過1000W，就要考慮分庫分表，原來一個數據庫變成多個數據庫，一個操作既要訪問01庫，又要訪問02庫，要保證數據一致性，就要使用分布式事務。
????????????????????????????????????????????????????????????????????
二、應用SOA化
????1.業務的服務化，原來單機支撐了整個交易平臺，現在對整個網站進行拆解，分離出用戶中心、庫存中心、訂單中心和商品中心，同時不同的服務對應各自的數據庫。
????2.如果要同時對訂單和庫存進行操作，這時需要分布式事務，來保證數據的一致性。
?????????????????????????????????????????????
三、事務的特性
?1.分布式事務本身是事務，那也就具有ACID四個特性。
?2.特性的具體表現
A：原子性（Atomicity）
事務中的各個操作單元要么全部做，要么就全部不做。不能事務執行后，處于只做一半的狀態。
?例如：銀行轉賬，從 A 賬戶轉 100 元至 B 賬戶，分為兩個步驟：
從 A 賬戶取 100 元
存入 100 元至 B 賬戶
C：一致性（Consistency）
事務執行后，必須由一個一致狀態變為另外一個一致狀態。
?例如：現有完整性約束 A+B=100，如果一個事務改變了 A，那么必須得改變 B，使得事務結束后依然滿足 A+B=100，否則事務失敗。
I：隔離性（Isolation）
事務之間不能相互干擾。
例如：現有有個交易是從 A 賬戶轉 100 元至 B 賬戶，在這個交易事務還未完成的情況下，如果此時 B 查詢自己的賬戶，是看不到新增加的 100 元的。
D：持久性（Durability）
一旦事務完成，對于數據的變更是永久的。
模型-?X/OpenDTP
一、分布式事務概念
?1. 分布式事務是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位于不同的分布式系統的不同節點之上。
?2.一個大的操作有連個或者更小的操作共同完成，這些小的操作有分布在不同的網絡主機上，這些操作，要么全部執行成功，要么全部不執行。
二、模型的概念
???1.X/Open DTP(X/Open?Distributed Transaction Processing Reference Model) 是X/Open 這個組織定義的一套分布式事務的標準，也就是了定義了規范和API接口，由這個廠商進行具體的實現。這個思想在java 平臺里面到處都是。
??2.三個組件?
????AP(Application Program)：也就是應用程序，可以理解為使用DTP的程序
????RM(Resource Manager)：資源管理器，這里可以理解為一個DBMS系統，或者消息服務器管理系統，應用程序通過資源管理器對資源進行控制。資源必須實現XA定義的接口
????TM(Transaction Manager)：事務管理器，負責協調和管理事務，提供給AP應用程序編程接口以及管理資源管理器
?????????????????????????????????????????????????????
三、具體應用
?（一）2PC
1.兩個階段：?提交事務請求（投票） ； 執行事務請求（提交或中斷）
階段一：提交事務請求
（1）TM向所有的AP發送事務內容，詢問是否可以執行事務的提交操作，并等待各個AP的響應。
（2）執行事務
??????各個AP節點執行事務操作，將undo和redo信息記錄到事務日志中，盡量把提交過程中所消耗時間的操作和準備都提前完成后確保后續事務提交的成功率
（3）各個AP向TM反饋事務詢問的響應
??????各個AP成功執行了事務操作，那么反饋給TM yes的response；如果AP沒有成功執行事務，就反饋TM no的response。
階段二：執行事務提交
（1）成功提交?
?
（2）出現問題 ：中斷事務提交
2.出現數據一致性問題：
數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求之后，發生了局部網絡異常或者在發送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之后就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。于是整個分布式系統便出現了數據部一致性的現象。
同步阻塞問題。執行過程中，所有參與節點都是事務阻塞型的。當參與者占有公共資源時，其他第三方節點訪問公共資源不得不處于阻塞狀態
二階段無法解決的問題：協調者在發出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了。那么即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交
單點故障。由于協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。
（二）3PC?
?1.三個階段
canCommit
preCommit
doCommit
階段1：CanCommit
1、協調者向所有參與者發出包含事務內容的CanCommit請求，詢問是否可以提交事務，并等待所有參與者答復。
2、參與者收到CanCommit請求后，如果認為可以執行事務操作，則反饋YES并進入預備狀態，否則反饋NO。
?
階段2：PreCommit
?
此階段分兩種情況：
1、所有參與者均反饋YES，即執行事務預提交。
2、任何一個參與者反饋NO，或者等待超時后協調者尚無法收到所有參與者的反饋，即中斷事務。
?
事務預提交：（所有參與者均反饋YES時）
1、協調者向所有參與者發出PreCommit請求，進入準備階段。
2、參與者收到PreCommit請求后，執行事務操作，將Undo和Redo信息記入事務日志中（但不提交事務）。
3、各參與者向協調者反饋Ack響應或No響應，并等待最終指令。
?
中斷事務：（任何一個參與者反饋NO，或者等待超時后協調者尚無法收到所有參與者的反饋時）
1、協調者向所有參與者發出abort請求。
2、無論收到協調者發出的abort請求，或者在等待協調者請求過程中出現超時，參與者均會中斷事務。
?
階段3：do Commit
?
此階段也存在兩種情況：
1、所有參與者均反饋Ack響應，即執行真正的事務提交。
2、任何一個參與者反饋NO，或者等待超時后協調者尚無法收到所有參與者的反饋，即中斷事務。
?
提交事務：（所有參與者均反饋Ack響應時）
1、如果協調者處于工作狀態，則向所有參與者發出do Commit請求。
2、參與者收到do Commit請求后，會正式執行事務提交，并釋放整個事務期間占用的資源。
3、各參與者向協調者反饋Ack完成的消息。
4、協調者收到所有參與者反饋的Ack消息后，即完成事務提交。
?
中斷事務：（任何一個參與者反饋NO，或者等待超時后協調者尚無法收到所有參與者的反饋時）
1、如果協調者處于工作狀態，向所有參與者發出abort請求。
2、參與者使用階段1中的Undo信息執行回滾操作，并釋放整個事務期間占用的資源。
3、各參與者向協調者反饋Ack完成的消息。
4、協調者收到所有參與者反饋的Ack消息后，即完成事務中斷。
?
注意：進入階段三后，無論協調者出現問題，或者協調者與參與者網絡出現問題，都會導致參與者無法接收到協調者發出的do Commit請求或abort請求。此時，參與者都會在等待超時之后，繼續執行事務提交。?
?
?
2.改進點
增加了超時機制
第二階段，如果協調者超時沒有接受到參與者的反饋，則自動認為失敗，發送abort命令
第三階段，如果參與者超時沒有接受到協調者的反饋，則自動認為成功開始提交事務（基于概率）
3.問題點?
?????相對于2PC，3PC主要解決的單點故障問題，并減少阻塞，因為一旦參與者無法及時收到來自協調者的信息之后，他會默認執行commit。而不會一直持有事務資源并處于阻塞狀態。但是這種機制也會導致數據一致性問題，因為，由于網絡原因，協調者發送的abort響應沒有及時被參與者接收到，那么參與者在等待超時之后執行了commit操作。這樣就和其他接到abort命令并執行回滾的參與者之間存在數據不一致的情況。?
互聯網分布式事務的解決方案?
一、業務接口整合，避免分布式事務
二、最終一致性方案
????eBay的方案其實是一個最終一致性方案，它主要采用消息隊列來輔助實現事務控制流程，方案的核心是將需要分布式處理的任務通過消息隊列的方式來異步執行，如果事務失敗，則可以發起人工重試的糾正流程。人工重試被更多的應用于支付場景，通過對賬系統對事后問題進行處理。
1.消息隊列
???例如：某個用戶產生了一筆交易，那么需要在交易表中增加記錄，同時需要修改用戶表的金額（余額），由于這兩個表屬于不同的遠程服務，所以就會涉及到分布式事務與數據一致性的問題。???
???使用消息隊列解決：
???先啟動一個事務，更新交易表（transaction）后，并不直接更新user表，而是將要對user表進行的更新插入到消息隊列中。
目標系統收到該消息以后，啟動本地事務去對用戶表的余額做調整。
?????可能出現以下情況：
數據庫操作成功，向MQ中投遞消息也成功
操作數據庫失敗，不會向MQ中投遞消息
操作數據庫成功，但是向MQ中投遞消息時失敗，向外拋出異常。數據庫操作回滾
如何保證消息不丟失
?????現在用的比較普遍的MQ都具有持久化消息的功能，如果消費者宕機或者消費失敗，都可以執行重試機制
對于如何避免消息的重復消費
??（1）保證消費者的冪等性
???如果隊列中的消息因為網絡異常導致發送多次的情況下，仍然需要保證消息被應用多次與應用一次產生的效果是一樣的
???（2）通過消費日志表來記錄消費狀態
?????增加一個message_applied（msg_id）表，用來記錄已經被成功應用的消息。在目標系統執行更新操作之前，先檢測該消息是否已經被消費過，消費完成后通過本地事務控制來更新這個“消費表狀態”，用來避免消息重復消費問題
2.DTS架構
????（1） DTS(Distributed Transaction Service)框架是由支付寶在X/OpenDTP模型的基礎上改進的一個設計，定義了類似2PC的標準兩階段接口。
????（2）DTS最大的特點是放寬了數據庫的強一致約束，保證了數據的最終一致性?。
????（3）支付系統接收到會員的支付請求后，需要扣減會員賬戶余額、增加會員積分（暫時假設需要同步實現）增加商戶賬戶余額。會員系統、商戶系統、積分系統是獨立的三個子系統，無法通過傳統的事務方式進行處理。
?????TRYING階段：我們需要做的就是會員資金賬戶的資金預留，即：凍結會員賬戶的金額（訂單金額）
?????CONFIRMING階段：我們需要做的就是會員積分賬戶增加積分余額，商戶賬戶增加賬戶余額
?????CANCELING階段：該階段需要執行的就是解凍釋放我們扣減的會員余額
???????????????????????????????????????????
3.保證最終一致性的模式
（1）查詢模式
????任何一個服務操作都提供一個查詢接口，用來向外部輸出操作執行的狀態。服務操作的使用方可以通過接口得知服務操作執行的狀態，然后根據不同狀態做不同的處理操作為了能夠實現查詢，每個服務操作都需要有唯一的流水號。
（2）補償模式
????有了查詢模式，我們就能夠得知操作所處的具體狀態，如果整個操作處于不正常狀態，我們需要修正操作中的出現問題的子操作。也許是要重新執行，或者取消已完成的操作。通過修復使得整個分布式系統達到最終一致。
????根據發起形式又分為：
????自動恢復：通過對發生失敗操作的接口自動重試或者回滾已經完成的操作
????通知運營：如果程序無法自動完成恢復，則通過運營人員手動進行補償
????通知技術：通過監控或者告警通知到技術人員，通過技術手段進行修復?
三、最大努力通知型
???做支付寶交易接口，一般會在支付寶的回調頁面和接口里，解密參數，然后調用系統中更新交易狀態相關的服務，將訂單更新為付款成功。
????同時，只有當我們回調頁面中輸出了success字樣或者標識業務處理成功相應狀態碼時，支付寶才會停止回調請求。否則，支付寶會每間隔一段時間后，再向客戶方發起回調請求，直到輸出成功標識為止。
????這就是一個很典型的補償例子，跟一些MQ重試補償機制很類似。
小結
????這部分的內容結合源碼去理解，可能會理解得更加透徹。
???????????????????????????????????????????????????????????????????????????感謝您的訪問！
---------------------?
作者：馮浩月?
來源：CSDN?
原文：https://blog.csdn.net/m18633778874/article/details/90110788?
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！
總結
- 上一篇： 如何保养笔记本电池
- 下一篇： 工行金闪借可以先还利息在还本金吗