本地事務 全域性事務 分布式事務

本地事務

事務隔離級別

select @@tx_isolation

+—————–+

| @@tx_isolation |

+—————–+

| repeatable-read |

+—————–+

1 row in set (0.00 sec)

開啟事務

執行緒1執行如下。

use order_db;

begin;
update orders set order_money = order_money + 0.01
where id = 171517987004616228;

select * from orders where id = 171517987004616228;

| id | order_money |

| 171517987004616228 | 94.00 |

commit;

select * from orders where id = 171517987004616228;

| id | order_money |

| 171517987004616228 | 94.01 |

全域性事務

use order_db;

## 分別開啟事務
mysql_connection.begin;
oracle_connection.begin;
## 分別執行操作
update mysql_orders set order_money = order_money + 0.01
where id = 171517987004616228;
update oracle_orders set order_money = order_money + 0.01
where id = 171517987004616228;
## 分別提交，如果有乙個失敗，則分別進行rollback操作
mysql_connection.commit;
oracle_connection.commit;

分布式事務

tcc補償性事務

tcc提供了乙個程式設計框架，將整個業務邏輯分為三塊：try、confirm和cancel三個操作。以支付場景為例，一次支付涉及mysql和oracle的金額變化。

try階段：分別凍結mysql和oracle中的金額。

confirm階段：分別扣除try階段中凍結的金額。

cancel階段：分別將凍結金額解凍恢復到使用者的餘額中。

由於可能會出現多次提交，需要支援冪等，即同一次請求必須只能成功一次，且每次返回結果都一樣。tcc對**侵入性強，不同的業務場景所寫的**都不一樣，複雜度也不一樣，**也不能很好的復用。

訊息佇列+最終一致性（最大努力型）

去哪兒、支付寶也採用過這種方式實現最終一致性。

利用訊息佇列+本地事務。如上例，一次支付涉及mysql和oracle的金額變化。

2.1 執行mysql的本地事務

2.2 傳送訊息（訊息佇列來保證訊息傳送成功後就不會丟）

2.1、2.2執行失敗就回滾本地事務。當然傳送訊息成功後如oracle的操作執行失敗呢？設定最大重試次數，直到訊息的資料處理完成。

思路就是將分布式事務拆分成多個本地事務，分別來保證每個事務的完整。

本地事務和分布式事務

1 本地事務acid 和 cap中的ca區別 本地事務 a 原子性 乙個事務中所有操作，要不全部完成，要不全部不完成，事務在執行過程中發生錯誤，會被回滾到事務開始前的狀態，就像這個事務沒有被執行過一樣。c 一致性 事務的一致性指在乙個事務執行之前和執行之後資料庫都必須處於一致性狀態，如果事務成功完成...

分布式事務和本地事務

指一次大的操作由不同的小操作組成的，這些小的操作分布在不同的伺服器上，分布式事務需要保證這些小操作要麼全部成功，要麼全部失敗。從本質上來說，分布式事務就是為了保證不同資料庫的資料一致性。1 資料庫分庫分表 當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋...

事務 分布式事務

事務 邏輯上的一組操作，要麼都成功要麼都失敗 事務的四個特性 acid 原子性，一致性，隔離性，永續性 事務的隔離級別 讀未提交 產生髒讀 讀已提交 不可重複讀 可重複讀 幻讀 mysql預設 序列化讀 效能最低 傳播行為 7個 七種傳播行為 required 支援當前事務，如果不存在，就新建乙個 ...