分佈式事務
分佈式環境下的事務
要了解分佈式事務，首先要了解分佈式環境
分佈式
如一網站，訪問一個服務A（查詢自己用戶信息）， 提供服務A的服務器分別有A1（上海）A2（廣州） A3（新加坡）
同一個服務分佈在三個區域的服務器上，這就是分佈式。你可以訪問 上海的服務器，廣州的或者新加坡的，但是
三個服務器之前通信是有延遲的，所以數據同步需要一定時間
分佈式中的問題
舉例一個分佈式場景
如果用戶Y個人信息 名字為 “南柯一夢” Y改為 “南柯夢”， 同一時間，Y用戶好友查看Y的名字，好友查詢的結果是”南柯一夢” 還是 “南柯夢” 這是分佈式系統常見的問題（數據修改發生在上海，訪問發生在新加坡）。
CAP原則
CAP原則又稱CAP定理，指的是在一個分佈式系統中，一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。CAP 原則指的是，這三個要素最多只能同時實現兩點，不可能三者兼顧。
參考文章
An Illustrated Proof of the CAP Theorem
CAP 定理的含義
以為網絡有延遲和不可測故障，因此分佈式系統是保持服務穩定的常用手段，但是分佈式因為服務機器分佈在不同地點，因此也會有分佈式的特點問題。
分佈式中 一致性 可用性 容災性 是三個指標
Consistency
數據一致性，分佈式環境下，不同地點的服務器，數據庫數據同步一致。
Availability
服務可用性，分佈式環境下，調用服務，都可用
Partition tolerance
分區容錯性，容災能力
分佈式環境多台服務器運行，其中一部分機器故障了，整個系統仍然可以正常運行提供服務
CAP不能同時滿足
必須滿足P
首先分佈式環境，系統需要穩定運行，一台服務器意外斷電，不應該影響系統整體功能正常，另一台或多台服務器還能穩定提供服務，所以分區容錯是必須要滿足。
滿足C
數據一致性，所指的是同一個服務所在不同服務器的數據是同步的。如上改名字的場景 南柯一夢 改為 南柯夢 （在上海的數據庫被修改） 那麼系統要做到滿足數據一致性，必須馬上同步廣州和新加坡的數據庫，這樣才能滿足廣州或者新加坡的訪問者獲得的結果也一致是 “南柯夢” 而不是”南柯一夢”
滿足A
服務可用性，指任何時候訪問服務，都返回結果
A與C是衝突的，上海服務器南柯一夢改為南柯夢后，為了服務可用，此時間訪問新加坡和廣州的服務器，返回的結果應該是南柯一夢(任何時候服務都返回結果) 但是嚴格上講，數據是錯誤的，因為用戶已經改了名字，改為南柯夢，但是數據在上海的才是正確的。
滿足數據一致性必須犧牲服務可用性 或者相反
要達到數據一致性的要求，必須在上海服務器修改數據的同時，同步廣州和新加坡的數據庫，並且在數據同步完成之前，訪問廣州和新加坡的數據庫中這條數據需要等待，返回同步后的結果（一致性）。
失去了服務可用性（這裏服務是等待數據同步完成才返回結果，而不是立刻返回）
因此CAP 要麼 滿足AP （分區服務可用）要麼 CP （分區數據一致）
分佈式中事務
商品購買中的事務
以商品購買生成訂單為例子
網絡上用戶A 購買 一雙鞋子 價格50 付款後生成消費訂單
事務中包含子的服務
這裏簡單設為三個服務，他們是事務相關的
1.商品信息服務
提供商品信息等服務
鞋子 顏色 價格 庫存數量等信息 這裏設 價格price為 50 庫存數 num 9
2.商家賬號收款服務
提供金額收入信息等服務
用戶購買鞋子，需要付款50元到商家賬號
3.用戶消費訂單服務
提供購買消費憑證信息等服務
首先分析用戶購買鞋子，三個服務分別要做什麼
@1 鞋子庫存減1
@2 商家賬號金額增加50
@3 生成 用戶購買鞋子的訂單記錄， 包括數量金額等信息
事務特性
原子性
@1 @2 @3 要麼同時發生，要麼都不發生
一致性
鞋子庫存減少1，收入增加50
隔離性
鞋子庫存減1，後續用戶最多只能購買(9-1=8)雙鞋子
持久性
動作執行成功后，訂單生效，收入新增50生效，庫存減1生效
上述三個服務他們可以在不同的地點，不同機器上部署的，並很常見。
保證數據正確
開啟事務
確定要執行的服務，每個服務的數據庫事務開啟
執行業務
調用庫存減1，轉賬，生成訂單等子服務
提交
業務執行過程中沒有意外，各子服務的數據庫提交事務，生效數據修改
回退
回退，如果服務調用出現了差錯，或者某個子服務執行失敗，可以通過回滾所有數據庫達到數據正確。
補償
某些情況下，某個子服務執行失敗，但是不影響整體業務，也可以提交事務，後續補償機制將失敗的子服務重新執行。
補償機制
個人認為就商品購買而言，補償機制多數情況可以使用且實用。（對強一致要求沒那麼高的情況下）
@1 庫存減1
@2 收入增加50
@ 3生成訂單記錄
如果這次執行的動作， 只有@3失敗，@1 @2成功 說明金額交易，商品庫存業務都沒問題，只是訂單記錄失敗，這是可以提交事務的，訂單錯誤可以生成一條記錄（攜帶商品，金額等信息），發送到MQ消息隊列（或者其他設計）通過消息隊列通知訂單相關服務，補償重新執行生成訂單，達到最終一致性。
分佈式事務控制問題
不同服務在不同區運行
不管是從安全性，穩定性，還是服務粒度細化方便維護等多因素考慮，都是很有必要讓不同的服務分開在不同服務區運行。
單體數據庫的事務不被支持，購買商品到生成訂單所有操作加起來算一個事務，涉及的數據在不同一服務（不同的數據庫），並且同一個服務可能運行在多台服務器上。
數據庫開啟事務針對的是單台服務器，多個服務多個數據庫，並不支持數據庫的事務，需要額外設計處理數據一致性問題（或者最終一致性）
同一個服務運行在多個區
不同服務不在一個服務器，同樣的，分佈式為穩定性可用而生，因此，一個服務大多有在多個區的服務器上運行，開啟事務的時候，如何保證事務開啟提交等事務相關命令每次發送到同一個區的同一個服務器，也是一定要考慮的問題。
分佈式事務處理方式
如上所述分佈式服務代表多個數據庫，不支持數據庫的事務，
如何保證事務中涉及的數據庫數據修改都提交生效或者都回滾。
建立控制中心
控制中心在執行業務時，統一發送開始事務的命令給三個服務，返回狀態
狀態沒問題執行數據修改，
都沒問題就發送給三個服務，提交事務，否在回滾事務
消息機制事務
MQ消息隊列，達到控制事務正確目的，項目中kafka聽的比較多，可在高併發環境下穩定運行，可以通過消息機制發送事務處理結果到子服務，子服務收到消息，通過分析消息內容，做出對應的操作，達到事務一致性或者最終一致性等目的
思考圖：
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※教你寫出一流的銷售文案?
