一、mysql單機事務是如何實現的
關於網上談及分布式資料庫事務的文章並不少，不過大多都是講市面上存在的解決方案，含有太多特定名詞，看了難免一頭霧水。今天我們來聊聊分布式事務。首先我們看一看這麼個案例。a向b採購一批貨物，這裡涉及先發貨還是先付錢，我們發現他們兩個人必須有個先後，而這種先後避免不了會發生糾纏不清。實際解決這類問題的方案就是需要有個第三方來公證。這裡我先下兩個定義：
1.事務是發生在「寫」的基礎之上。只有兩個或者兩個以上的寫操作互相間有干預才會發生事務。
2.事務就是第三方公證。
關於事務的四個特性（原子性、一致性、隔離性，永續性）等就是事務要履行的職責。我們來看看mysql解決事務的方式：
1.表a有資料更改（資料庫發生「寫」操作），建立事務t。
2.事務t記錄表a寫操作的訴求s1（此訴求記錄是持久的，不會因為機器宕機而丟失，即永續性）。
3.只要存在訴求s1,表a就要進行寫操作。表a根據訴求s1的要求，進行持久化。（以下是事務的原子性）
①表a持久化成功，就執行消除訴求s1的操作
②表a持久化失敗，就執行回滾操作，回滾成功後，就執行消除訴求s1的操作。
那麼問題就出現在訴求s1的消除過程，當表a持久化成功後，s1消除操作失敗。怎麼辦？因此，就存在了冪等操作的要求。就是保證，只要存在s1，表a就要執行對應的持久化操作，無論執行多少次結果都一樣，即一致性。（冪等操作舉例，賬戶1001有餘額100元，扣款5元，無論執行多少次，結果都是100-5=95元，即此訴求記錄了原值、修改值）。由於併發的關係，實際上解決冪等操作等方案就是新增鎖機制，即事務鎖。
以上問題，如果我們回到併發場景，我們就會有疑問，當資料庫表發生寫操作，又發生了讀寫操作怎麼辦？
1.資料庫表事務操作是建立在同一行記錄的。
2.同一行記錄發生了併發問題（建立在兩個或者以上的事務），那麼取數以什麼為標準，就是我們所說的隔離級別，即隔離性，以下是mysql的隔離級別方案：
①讀未提交（事務1發生了寫操作產生訴求s1，表a還沒持久化，事務2讀取s1的修改值。）
②不可重複讀（事務1發生了寫操作產生訴求s1，表a已經持久化，事務2讀取表a中的值。）
③可重複讀（事務1發生了寫操作產生訴求s1，表a已經持久化，事務2讀取了s1中的原值。）
④序列化（事務1發生了寫操作產生訴求s1，表a已經持久化，不允許事務2進行讀操作。）
二、總結
參照單機mysql事務來解決分布式資料庫事務，主要核心實現就是這個第三方公證的設計，只要遵守事務的四大特性（原子性、一致性、隔離性，永續性），就能實現分布式資料庫事務。
談談資料庫事務
首先事務用一句簡單的話來說，事務就是邏輯上的操作，要麼都執行要麼都不執行。如最常見的轉賬。那麼事務是如何來保證這種操作的呢？一 事務的acid 原子性 事務視為乙個整體要麼全部成功要麼全部失敗。以轉賬為例子 在事務中的扣款和價款兩條語句。在資料庫管理系統中，預設情況下一條sql就是乙個單獨的事務，事...
分布式服務如何設計分布式事務
1 如果a b c強相關 考慮採用tcc框架 try confirm cancel bytetcc，himly 阿里的fescar，seata 推薦使用seata tcc框架 2 如果a 與bc並不強相關 考慮可靠訊息最終一致性解決方案，例如a成功後通過傳送kafka事件，bc監聽事件來處理。roc...
C 資料庫事務原理
隔離級別的概念 企業級的資料庫每一秒鐘都可能應付成千上萬的併發訪問，因而帶來了併發控制的問題。由資料庫理論可知，由於併發訪問，在不可預料的時刻可能引發如下幾個可以預料的問題 髒讀 包含未提交資料的讀取。例如，事務1 更改了某行。事務2 在事務1 提交更改之前讀取已更改的行。如果事務1 回滾更改，則事...