分布式事务的理解和解决方法
什么是分布式事務？
- 什么是分布式系統(tǒng)?
? ? ? ?部署在不同結點上的系統(tǒng)通過網絡交互來完成協(xié)同工作的系統(tǒng)。 比如：充值加積分的業(yè)務，用戶在充值系統(tǒng)向自己的賬戶充錢，在積分系統(tǒng)中自己積分相應的增加。充值系統(tǒng)和積分系統(tǒng)是兩個不同的系統(tǒng)，一次充值加積分的業(yè)務就需要這兩個系統(tǒng)協(xié)同工作來完成。
- 什么是事務？
? ? ? ?是指由一組操作的工作單元，這個工作單元具有ACID（原子性（atomicity）、一致性（consistency）、隔離性（isolation）和持久性（durability））
原子性：執(zhí)行單元中的操作要么全部執(zhí)行成功，要么全部失敗。如果有一部分成功一部分失敗那么成功的操作要全部回滾到執(zhí)行前的狀態(tài)。
一致性：執(zhí)行一次事務會使用數據從一個正確的狀態(tài)轉換到另一個正確的狀態(tài)，執(zhí)行前后數據都是完整的。
隔離性：在該事務執(zhí)行的過程中，任何數據的改變只存在于該事務之中，對外界沒有影響，事務與事務之間是完全的隔離的。只有事務提交后其它事務才可以查詢到最新的數據。
持久性：事務完成后對數據的改變會永久性的存儲起來，即使發(fā)生斷電宕機數據依然在。
- 什么是本地事務？
本地事務就是用關系數據庫來控制事務，關系數據庫通常都具有ACID特性，傳統(tǒng)的單體應用通常會將數據全部存儲在一個數據庫中，會借助關系數據庫來完成事務控制。
- 什么是分布式事務？
在分布式系統(tǒng)中一次操作由多個系統(tǒng)協(xié)同完成，這種一次事務操作涉及多個系統(tǒng)通過網絡協(xié)同完成的過程稱為分布式事務。這里強調的是多個系統(tǒng)通過網絡協(xié)同完成一個事務的過程，并不強調多個系統(tǒng)訪問了不同的數據庫，即使多個系統(tǒng)訪問的是同一個數據庫也是分布式事務，另外一種分布式事務的表現是，一個應用程序使用了多個數據源連接了不同的數據庫，當一次事務需要操作多個數據源，此時也屬于分布式事務，當系統(tǒng)作了數據庫拆分后會出現此種情況。
- 分布式事務有哪些場景？
?
-
如何進行分布式事務控制？
- CAP理論
CAP理論是分布式事務處理的理論基礎，了解了CAP理論有助于我們研究分布式事務的處理方案。
CAP理論是：分布式系統(tǒng)在設計時只能在一致性(Consistency)、可用性(Availability)、分區(qū)容忍性(Partition Tolerance)中滿足兩種，無法兼顧三種。
- 一致性(Consistency)：服務A、B、C三個結點都存儲了用戶數據，三個結點的數據需要保持同一時刻數據一致 性。
- 可用性(Availability)：服務A、B、C三個結點，其中一個結點宕機不影響整個集群對外提供服務，如果只有服務A結點，當服務A宕機整個系統(tǒng)將無法提供服務，增加服務B、C是為了保證系統(tǒng)的可用性。
- 分區(qū)容忍性(PartitionTolerance)：分區(qū)容忍性就是允許系統(tǒng)通過網絡協(xié)同工作，分區(qū)容忍性要解決由于網絡分區(qū)導致數據的不完整及無法訪問等問題。
分布式系統(tǒng)不可避免的出現了多個系統(tǒng)通過網絡協(xié)同工作的場景，結點之間難免會出現網絡中斷、網延延遲等現象，這種現象一旦出現就導致數據被分散在不同的結點上，這就是網絡分區(qū)。?
在分布式系統(tǒng)設計中AP的應用較多，即保證分區(qū)容忍性和可用性，犧牲數據的強一致性（寫操作后立刻讀取到最新數據），保證數據最終一致性。比如：訂單退款，今日退款成功，明日賬戶到賬，只要在預定的用戶可以接受的時間內退款事務走完即可。
?
-
分布式事務的解決辦法
- 兩階段提交協(xié)議(2PC)
為解決分布式系統(tǒng)的數據一致性問題出現了兩階段提交協(xié)議（2PhaseCommitmentProtocol），兩階段提交由協(xié)調者和參與者組成，共經過兩個階段和三個操作
1）第一階段：準備階段（prepare） 協(xié)調者通知參與者準備提交訂單，參與者開始投票。協(xié)調者完成準備工作向協(xié)調者回應Yes。
2）第二階段：提交(commit)/回滾(rollback)階段 協(xié)調者根據參與者的投票結果發(fā)起最終的提交指令。如果有參與者沒有準備好則發(fā)起回滾指令。 一個下單減庫存的例子：
- 三階段提交協(xié)議(3PC)
2PC的優(yōu)點：實現強一致性，部分關系數據庫支持（Oracle、MySQL等）。 缺點：整個事務的執(zhí)行需要由協(xié)調者在多個節(jié)點之間去協(xié)調，增加了事務的執(zhí)行時間，性能低下。
解決方案有：springboot+AtomikosorBitronix
3PC主要是解決協(xié)調者與參與者通信阻塞問題而產生的，它比2PC傳遞的消息還要多，性能不高。
- 事務補償（TCC）
TCC事務補償是基于2PC實現的業(yè)務層事務控制方案，它是Try、Confirm和Cancel三個單詞的首字母，含義如下：
1、Try檢查及預留業(yè)務資源 完成提交事務前的檢查，并預留好資源。
2、Con?rm確定執(zhí)行業(yè)務操作 對try階段預留的資源正式執(zhí)行。
3、Cancel取消執(zhí)行業(yè)務操作 對try階段預留的資源釋放。 下邊用一個下單減庫存的業(yè)務為例來說明：
1、Try 下單業(yè)務由訂單服務和庫存服務協(xié)同完成，在try階段訂單服務和庫存服務完成檢查和預留資源。 訂單服務檢查當前是否滿足提交訂單的條件（比如：當前存在未完成訂單的不允許提交新訂單）。 庫存服務檢查當前是否有充足的庫存，并鎖定資源。 2、Confirm 訂單服務和庫存服務成功完成Try后開始正式執(zhí)行資源操作。 訂單服務向訂單寫一條訂單信息。 庫存服務減去庫存。 3、Cancel 如果訂單服務和庫存服務有一方出現失敗則全部取消操作。 訂單服務需要刪除新增的訂單信息。 庫存服務將減去的庫存再還原。
優(yōu)點：最終保證數據的一致性，在業(yè)務層實現事務控制，靈活性好。
缺點：開發(fā)成本高，每個事務操作每個參與者都需要實現try/confirm/cancel三個接口。
注意：TCC的try/confirm/cancel接口都要實現冪等性，在為在try、confirm、cancel失敗后要不斷重試。
什么是冪等性？
冪等性是指同一個操作無論請求多少次，其結果都相同。 冪等操作實現方式有： 1、操作之前在業(yè)務方法進行判斷如果執(zhí)行過了就不再執(zhí)行。 2、緩存所有請求和處理的結果，已經處理的請求則直接返回結果。3、在數據庫表中加一個狀態(tài)字段（未處理，已處理），數據操作時判斷未處理時再處理。
?
-
消息隊列實現最終一致性
本方案是將分布式事務拆分成多個本地事務來完成，并且由消息隊列異步協(xié)調完成，如下圖：
下邊以下單減少庫存為例來說明：
1、訂單服務和庫存服務完成檢查和預留資源。
2、訂單服務在本地事務中完成添加訂單表記錄和添加“減少庫存任務消息”。
3、由定時任務根據消息表的記錄發(fā)送給MQ通知庫存服務執(zhí)行減庫存操作。
4、庫存服務執(zhí)行減少庫存，并且記錄執(zhí)行消息狀態(tài)（為避免重復執(zhí)行消息，在執(zhí)行減庫存之前查詢是否執(zhí)行過此消息）。
5、庫存服務向MQ發(fā)送完成減少庫存的消息。
6、訂單服務接收到完成庫存減少的消息后刪除原來添加的“減少庫存任務消息”。 實現最終事務一致要求：預留資源成功理論上要求正式執(zhí)行成功，如果執(zhí)行失敗會進行重試，要求業(yè)務執(zhí)行方法實現冪等。
優(yōu)點： 由MQ按異步的方式協(xié)調完成事務，性能較高。 不用實現try/confirm/cancel接口，開發(fā)成本比TCC低。
缺點： 此方式基于關系數據庫本地事務來實現，會出現頻繁讀寫數據庫記錄，浪費數據庫資源，另外對于高并發(fā)操作不是
最佳方案。
?
?
總結
以上是生活随笔為你收集整理的分布式事务的理解和解决方法的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Jenkins的安装和卸载（转载）
- 下一篇： v4l2 框架下如何设置分辨率_Linu