簡單介紹下鎖機制：
鎖等待：當一個事務在特定數據（行、表）上持有鎖時，只有當該事務終止並釋放鎖，其他事物才能對加鎖的數據資源進行訪問（根據鎖類型，訪問權限有所不同），其他事務等待鎖的過程，稱爲鎖等待。
鎖超時：鎖等待時，將阻礙其他事務的執行，可以通過配置鎖超時值，在指定時間間隔內，若等待的事務還未獲得鎖，則事務會回滾當前請求，這就是鎖超時。
死鎖：兩個或多個事務對鎖的循環爭用，稱爲死鎖。
一、購買某一商品的活動序列：
1.客戶在前端選擇了商品，此時該商品的價格、數量等都已經確定，系統也對其做了相應的計算，單未提交；
2.系統管理員在管理端對該商品進行操作，如：刪除、修改數量、修改金額、商品下架等
3.此時回到步驟1的頁面，點擊【提交】看系統如何處理？
二、電子商務網站中用戶積分使用的一個活動序列：
1.某一客戶在機器A上讀取自己賬戶的積分爲100元；
2.在機器B上讀取自己賬戶的積分同樣爲100元；
3.在A機器上使用該客戶80元積分；
4.在B機器上使用該客戶70元積分；
5.此時在A.B兩個機器上的操作員對使用積分的購物同時點擊【提交】
正確的結果是：應該只有一方成功，另一方給出合理提示信息；
但處理不當就會導致：兩個都成功，用戶積分爲負值
三、飛機訂票系統中的一個活動序列:
甲售票點（甲事務）讀出某航班的機票餘額A,設A=16.
乙售票點（乙事務）讀出同一航班的機票餘額A,也爲16.
甲售票點賣出一張機票,修改餘額A←A-1.所以A爲15,把A寫回數據庫.
乙售票點也賣出一張機票,修改餘額A←A-1.所以A爲15,把A寫回數據庫.
結果明明賣出兩張機票，數據庫中機票餘額只減少1。
事務：是訪問並可能更新數據庫中各種數據項的一個程序執行單元（unit）
由於計算機可能會因爲停電、網絡中斷等而出現故障，因此有可能更新了表中的行，但沒有更新另一個表的行。如果事務中的某個點發生故障，則所有更新都可以回滾到事務開始前的狀態。如果沒有發生故障，則可以通過完成狀態提交事務來完成更新。
我們測試的目的是爲了確保事務在發生故障時，所有更新都可以回滾到事務開始之前的狀態。
通常事務會滾是以單元測試方式進行覆蓋，如果是功能測試，要如何測試?
只要事務中最後一個節點故障，那麼事務回滾後，最後一個節點之前所有的更新都會不會成功被更新到數據庫中？ 那麼我們需要知道該事務依次對那些表操作，人爲的使事務提交失敗而回滾。
什麼是分佈式事務
傳統的基於數據庫本地事務的解決方案只能保障單個服務的一次處理具備原子性、隔離性、一致性與持久性，但無法保障多個分佈服務間處理的一致性。因此，我們必須建立一套分佈式服務處理之間的協調機制，保障分佈式服務處理的原子性、隔離性、一致性與持久性。
支付寶爲什麼需要分佈式事務
基於SOA架構，整個支付寶系統會拆分成一系列獨立開發、自包含、自主運行的業務服務，並將這些服務通過各種機制靈活地組裝成最終用戶所需要的產品與解決方案。
在多個服務協同完成一次業務時，由於業務約束（如紅包不符合使用條件、賬戶餘額不足等）、系統故障（如網絡或系統超時或中斷、數據庫約束不滿足等），都可能造成服務處理過程在任何一步無法繼續，使數據處於不一致的狀態，產生嚴重的業務後果，所以我們需要一個分佈式事務的解決方案,用來協調多個服務的業務一致性。
支付寶的分佈式事務框架
支付寶開發的分佈式事務是基於兩階段提交的理論(Two Phase Commit)。
階段一：1.TM（事務管理器）向所有的RM（資源管理器）發送準備請求
2.RM收到準備請求後，進行準備操作，並向TM回覆是否可以提交
階段二：1.TM收到所有RM的回覆後，如果所有RM均可以提交，向所有的RM發送提交請求，否則發送回滾請求
2.RM根據TM發送的消息控制本地事務提交、回滾