本地事務
我們先從本地事務（數據庫事務）說起吧，因為這個是大家在日常工作都接觸到，開發過程中都會用到的。
事務: 由一組操作構成的可靠的，獨立的操作單元；具有ACID四大特性，分別為原子性,一致性，隔離性和持久性。
優點：本地事務由資源管理系本地自行管理；支持嚴格的ACID四大特性；高效，可靠；
缺點：多個數據源搞不定，不具備分佈式事務處理能力。
全局事務：
說明：
X/Open DTP 定義了三個組件：RM和兩個協議：XA、TX
AP(Application Program)：也就是應用程序，可以理解為使用DTP的程序
RM(Resource Manager)：資源管理器，這裡可以理解為一個DBMS系統，或者消息服務器管理系統，應用程序通過資源管理器對資源進行控制。兩個要求：一是RM自身必須是支持事務的，二是RM能夠根據將全局（分佈式）事務標識定位到自己內部的對應事務。
TM(Transaction Manager)：事務管理器，負責協調和管理事務，提供給AP應用程序編程接口以及管理資源管理器。能與AP和RM直接通信，協調AP和RM來實現分佈式事務的完整性。主要的工作是提供AP註冊全局事務的接口，頒發全局事務標識（GTID之類 的），存儲/管理全局事務的內容和決策並指揮RM做commit/rollback。
XA協議：應用或應用服務器與事務管理之前通信的接口
TX協議：全局事務管理器與資源管理器之間通信的接口
兩階段提交：
1.準備階段：事務協調者(事務管理器)給每個參與者(資源管理器)發送Prepare消息，每個參與者要麼直接返回失敗(如權限驗證失敗)，要麼在本地執行事務，寫本地的redo和undo日誌，但不提交。
2.提交階段：如果協調者收到了參與者的失敗消息或者超時，直接給每個參與者發送回滾(Rollback)消息；否則，發送提交(Commit)消息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。(注意:必須在最後階段釋放鎖資源)
將提交分成兩階段進行的目的很明確，就是儘可能晚地提交事務，讓事務在提交前儘可能地完成所有能完成的工作，這樣，最後的提交階段將是一個耗時極短的微小操作，這種操作在一個分佈式系統中失敗的概率是非常小的，也就是所謂的“網絡通訊危險期”非常的短暫，這是兩階段提交確保分佈式事務原子性的關鍵所在。
從兩階段提交的工作方式來看，很顯然，在提交事務的過程中需要在多個節點之間進行協調，而各節點對鎖資源的釋放必須等到事務最終提交時，這樣，比起一階段提交，兩階段提交在執行同樣的事務時會消耗更多時間。事務執行時間的延長意味著鎖資源發生衝突的概率增加，當事務的併發量達到一定數量的時候，就會出現大量事務積壓甚至出現死鎖，系統性能就會嚴重下滑。這就是使用XA事務。
J2EE平臺中的分佈式事務實現： JTA&JTS; 感興趣的朋友可以自行去了解下。
Bsse理論
BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的總結， 是基於CAP定理逐步演化而來的。BASE理論的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。接下來看一下BASE中的三要素：
1、基本可用
基本可用是指分佈式系統在出現不可預知故障的時候，允許損失部分可用性—-注意，這絕不等價於系統不可用。比如：
（1）響應時間上的損失。正常情況下，一個在線搜索引擎需要在0.5秒之內返回給用戶相應的查詢結果，但由於出現故障，查詢結果的響應時間增加了1~2秒
（2）系統功能上的損失：正常情況下，在一個電子商務網站上進行購物的時候，消費者幾乎能夠順利完成每一筆訂單，但是在一些節日大促購物高峰的時候，由於消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面
2、軟狀態
軟狀態指允許系統中的數據存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時
3、最終一致性
最終一致性強調的是所有的數據副本，在經過一段時間的同步之後，最終都能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。
總的來說，BASE理論面向的是大型高可用可擴展的分佈式系統，和傳統的事物ACID特性是相反的，它完全不同於ACID的強一致性模型，而是通過犧牲強一致性來獲得可用性，並允許數據在一段時間內是不一致的，但最終達到一致狀態。換句話說，原子性和持久性必須要根本保障，為了可用性，性能與降級服務的需求，只有降低了一致性與隔離性的需求。
CAP理論
對於共享數據系統，最多隻能同時擁有CAP理論中的兩者，沒法全部兼顧。
任意兩者的組合都有使用的業務場景
真是業務場景中應該死ACID和BASE的混合體
1、一致性
在分佈式環境下，一致性是指數據在多個副本之間能否保持一致的特性。在一致性的需求下，當一個系統在數據一致的狀態下執行更新操作後，應該保證系統的數據仍然處於一直的狀態。
對於一個將數據副本分佈在不同分佈式節點上的系統來說，如果對第一個節點的數據進 行了更新操作並且更新成功後，卻沒有使得第二個節點上的數據得到相應的更新，於是在對第二個節點的數據進行讀取操作時，獲取的依然是老數據（或稱為髒數 據），這就是典型的分佈式數據不一致的情況。在分佈式系統中，如果能夠做到針對一個數據項的更新操作執行成功後，所有的用戶都可以讀取到其最新的值，那麼 這樣的系統就被認為具有強一致性。
2、可用性
可用性是指系統提供的服務必須一直處於可用的狀態，對於用戶的每一個操作請求總是能夠在有限的時間內返回結果。這裡的重點是”有限時間內”和”返回結果”。
“有限時間內”是指，對於用戶的一個操作請求，系統必須能夠在指定的時間內返回對 應的處理結果，如果超過了這個時間範圍，那麼系統就被認為是不可用的。另外，”有限的時間內”是指系統設計之初就設計好的運行指標，通常不同系統之間有很 大的不同，無論如何，對於用戶請求，系統必須存在一個合理的響應時間，否則用戶便會對系統感到失望。
“返回結果”是可用性的另一個非常重要的指標，它要求系統在完成對用戶請求的處理後，返回一個正常的響應結果。正常的響應結果通常能夠明確地反映出隊請求的處理結果，即成功或失敗，而不是一個讓用戶感到困惑的返回結果。
3、分區容錯性
分區容錯性約束了一個分佈式系統具有如下特性：分佈式系統在遇到任何網絡分區故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非是整個網絡環境都發生了故障。
網絡分區是指在分佈式系統中，不同的節點分佈在不同的子網絡（機房或異地網絡） 中，由於一些特殊的原因導致這些子網絡出現網絡不連通的狀況，但各個子網絡的內部網絡是正常的，從而導致整個系統的網絡環境被切分成了若干個孤立的區域。 需要注意的是，組成一個分佈式系統的每個節點的加入與退出都可以看作是一個特殊的網絡分區。
選擇說明：
CA： 放棄分區容錯性，加強一致性和可用性，其實就是傳統的單機數據庫的選擇
AP： 放棄一致性（這裡說的一致性是強一致性），追求分區容錯性和可用性，這是很多分佈式系統設計時的選擇，例如很多NoSQL系統就是如此
CP： 放棄可用性，追求一致性和分區容錯性，基本不會選擇，網絡問題會直接讓整個系統不可用
柔性事務
服務模式：
- 可查詢操作：
- 為了保證操作的可查詢，需要對於每一個服務的每一次調用都有一個全局唯一的標識，可以是業務單據號（如訂單號）、也可以是系統分配的操作流水號（如支付記錄流水號），或者是使用操作資源的組合標識（比如商戶號+商戶訂單號）。除此之外，操作的時間信息也要有完整的記錄。
- 可以使用全局的服務操作標識，來查詢操作的執行結果，特別對處理中的狀態的邏輯要謹慎對待。
- 冪等操作：
- 冪等性： ff((x))=f(x); 重複調用多次產生的業務結果與調用一次的業務結果一致；
- 可以通過業務操作本身實現冪等性；或者系統緩存所有的請求與處理結果，檢測到重複請求之後，返回之前的處理結果。
- TCC操作：
- Try:嘗試執行業務（1.完成所有業務檢查 2.預留必須的業務資源）
- confirm：確認執行業務（1.真正執行業務檢查 2.不做任何業務檢查 3.只只用try階段預留的業務資源 4.滿足冪等性）
- cancel:取消執行業務（1.釋放try階段預留的業務資源 2.cancel操作要滿足冪等性）
- 可補償操作：
- 可以抵消衝正正向業務操作的業務結果，補償需要滿足冪等性。
解決方案：
- 可靠消息的最終一致性（異步確保）
核心邏輯：
業務處理服務在業務事務提交前，向實時消息服務器發送消息，實時消息服務只記錄消息數據，而不是真正去發送；業務處理服務事務提交後，向實時消息服務發送確認發送的指令； 實時消息服務只有得到確認發送指令後才真正發送消息。
業務處理服務在業務事務回滾後，向實時消息發送取消發送指令。 消息確認系統定期找到未確認或者回滾發送的消息，向業務處理服務器詢問消息狀態，業務服務器根據消息ID或者內容確認消息是否有效。
被動方的處理結果不影響主動方的處理結果，被動方的消息處理操作是支持冪等操作。
優點：消息數據獨立存儲，伸縮性好，降低與業務系統的耦合性；對最終一致性的時間敏感度比較高，降低業務被動方的實現成本。
缺點：消息系統建設成本比較高，一次消息發送需要兩次請求，業務處理服務需要給消息系統提供狀態回查的接口。
- TCC（兩階型，補償型）
- 一個完整的業務活動由一個主業務服務以及其他從業務服務器註冊，主業務服務發起並完成整個業務活動；從業務服務提供TCC型業務操作；業務活動管理器控制業務活動的一致性，他記錄業務活動中的操作，並在業務活動提交的時確認所有的tcc操作的confirm操作；取消的時候調用所有tcc操作中的cancel操作。
- 適用強隔離性，一致性要求高的業務活動的場景
- 最大努力通知型
- 業務活動 主動方，在完成業務處理之後，向業務活動的被動方發送消息，允許消息丟失； 業務活動的被動方根據定時策略，向業務活動主動方查詢，回覆丟失的業務消息。
- 適用於對業務最終一致性的時間敏感度低的場景。
想要學習Dubbo框架、zookeper基本原理、redis分佈式緩存、JVM性能優化，Nginx+apache+Tomcat集群部署、大數據hadoop,Hbase實時計算spark、storm、數據分析分詞和權重等核心技術；需要的可以關注之後私信哈，記得要點贊轉發噢！！！
閱讀更多 IT技術分享 的文章
