再有人問你分佈式事務，把這篇文章砸過去給他

本文內容整理自 博學谷狂野架構師

事務的具體定義

​ 事務提供一種機制將一個活動涉及的所有操作納入到一個不可分割的執行單元，組成事務的所有操作只有在所有操作均能正常執行的情況下方能提交，只要其中任一操作執行失敗，都將導致整個事務的回滾。簡單地説，事務提供一種“要麼什麼都不做，要麼做全套（All or Nothing）”機制

數據庫本地事務

説到數據庫事務就不得不説，數據庫事務中的四大特性，ACID

A:原子性(Atomicity)

​ 一個事務(transaction)中的所有操作，要麼全部完成，要麼全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。

​ 就像你買東西要麼交錢收貨一起都執行，要麼要是發不出貨，就退錢。

C:一致性(Consistency)

​ 事務的一致性指的是在一個事務執行之前和執行之後數據庫都必須處於一致性狀態。如果事務成功地完成，那麼系統中所有變化將正確地應用，系統處於有效狀態。如果在事務中出現錯誤，那麼系統中的所有變化將自動地回滾，系統返回到原始狀態。

I:隔離性(Isolation)

​ 指的是在併發環境中，當不同的事務同時操縱相同的數據時，每個事務都有各自的完整數據空間。由併發事務所做的修改必須與任何其他併發事務所做的修改隔離。事務查看數據更新時，數據所處的狀態要麼是另一事務修改它之前的狀態，要麼是另一事務修改它之後的狀態，事務不會查看到中間狀態的數據。

打個比方，你買東西這個事情，是不影響其他人的

D:持久性(Durability)

​ 指的是隻要事務成功結束，它對數據庫所做的更新就必須永久保存下來。即使發生系統崩潰，重新啟動數據庫系統後，數據庫還能恢復到事務成功結束時的狀態。

打個比方，你買東西的時候需要記錄在賬本上，即使老闆忘記了那也有據可查。

簡單而言，ACID是從不同維度描述事務的特性：

• 原子性 —— 事務操作的整體性
• 一致性 —— 事務操作下數據的正確性
• 隔離性 —— 事務併發操作下數據的正確性
• 持久性 —— 事務對數據修改的可靠性

一個支持事務（Transaction）的數據庫，需要具有這4種特性，否則在事務過程當中無法保證數據的正確性，處理結果極可能達不到請求方的要求。

什麼時候使用數據庫事務

​ 在介紹完事務基本概念之後，什麼時候該使用數據庫事務？ 簡單而言，就是業務上有一組數據操作，需要如果其中有任何一個操作執行失敗，整組操作全部不執行並恢復到未執行狀態，要麼全部成功，要麼全部失敗。

​ 在使用數據庫事務時需要注意，儘可能短的保持事務，修改多個不同表的數據的宂長事務會嚴重妨礙系統中的所有其他用户，這很有可能導致一些性能問題。

什麼是分佈式事務

分佈式產生背景與概念

​ 隨着互聯網快速發展，微服務，SOA等服務架構模式正在被大規模的使用，現在分佈式系統一般由多個獨立的子系統組成，多個子系統通過網絡通信互相協作配合完成各個功能。

​ 有很多用例會跨多個子系統才能完成，比較典型的是電子商務網站的下單支付流程，至少會涉及交易系統和支付系統，而且這個過程中會涉及到事務的概念，即保證交易系統和支付系統的數據一致性，此處我們稱這種跨系統的事務為分佈式事務，具體一點而言，分佈式事務是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不同的分佈式系統的不同節點之上。

舉個互聯網常用的交易業務為例：

​ 上圖中包含了庫存和訂單兩個獨立的微服務，每個微服務維護了自己的數據庫。在交易系統的業務邏輯中，一個商品在下單之前需要先調用庫存服務，進行扣除庫存，再調用訂單服務，創建訂單記錄。

可以看到，如果多個數據庫之間的數據更新沒有保證事務，將會導致出現子系統數據不一致，業務出現問題。

分佈式事務的難點

事務的原子性

	事務操作跨不同節點，當多個節點某一節點操作失敗時，需要保證多節點操作的**要麼什麼都不做，要麼做全套（All or Nothing）**的原子性。

事務的一致性

​ 當發生網絡傳輸故障或者節點故障，節點間數據複製通道中斷，在進行事務操作時需要保證數據一致性，保證事務的任何操作都不會使得數據違反數據庫定義的約束、觸發器等規則。

事務的隔離性

​ 事務隔離性的本質就是如何正確多個併發事務的處理的讀寫衝突和寫寫衝突，因為在分佈式事務控制中，可能會出現提交不同步的現象，這個時候就有可能出現“部分已經提交”的事務。此時併發應用訪問數據如果沒有加以控制，有可能出現“髒讀”問題。

本文由傳智教育博學谷狂野架構師教研團隊發佈。

如果本文對您有幫助，歡迎關注和點贊；如果您有任何建議也可留言評論或私信，您的支持是我堅持創作的動力。

轉載請註明出處！