Mysql技術內幕InnoDB儲存引擎讀書筆記--《七》事務

事務的ACID四個特性，原子性，一致性，隔離性，永續性，這些已經老生常談了，就不必說。

事務的實現

redo

在InnoDB儲存引擎中，事務日誌通過重做（redo）日誌檔案和InnoDB儲存引擎的日誌緩衝（InnoDB Log Buffer）來實現。當開始一個事務時，會記錄該事務的一個LSN（Log Sequence Number，日誌序列號）；當事務執行時，會往I濃濃DB儲存引擎的日誌緩衝裡插入事務日誌；當事務提交時，必須將InnoDB儲存引擎的日誌緩衝寫入磁碟（預設的實現，即innodb_flush_log_at_trx_commit=1）。也就是在寫資料前，需要先寫日誌。這種方式稱為預寫日誌方式（Write-Ahead
-Logging，WAL）。

InnoDB儲存引擎通過預寫日誌的方式來保證事務的完整性。這意味著磁碟上儲存的資料頁和記憶體緩衝池中的頁是不同步的，對於記憶體緩衝池中頁的修改，先是寫入重做日誌檔案，然後再寫入磁碟，因此是一種非同步的方式。

undo

undo是用來利用undo資訊將資料回滾到修改之前的樣子。與redo不同的是，redo存放在重做日誌檔案中，undo存放在資料庫內部的一個特殊段（segment）中，這稱為undo段（undo segment），undo段位於共享表空間內。

由於別的事務也會修改資料，所以InnoDB儲存引擎回滾時，實際上是做相反的操作，對於每個INSERT進行DELETE，對於每個UPDATE執行一個相反的UPDATE，將修改前的行放回去。而不是直接全域性回滾，這回影響到其他事務的資料。

對於事務操作的統計

InnoDB儲存引擎應該關注的點：每秒請求書（QPS），每秒事務處理能力（Transaction Per Second，TPS）。

分散式事務

如一個使用者需要從上海轉10000元到北京的一個使用者上：

#Bank@Shanghai
update account set money = money - 10000 where user = 'David';


#Bank@Beijing
update account set money = money + 10000 where user = 'Mariah';

分散式事務由一個或者多個資源管理器（Resource Managers）、一個事務管理器（Transaction Manager）以及一個應用程式（Application Program）組成。

• 資源管理器：提供訪問事務資源的方法。通常一個資料庫就是一個資源管理器。
• 事務管理器：協調參與全域性事務中的各個事務。需要和參與全域性事務中的所有資源管理器進行通訊。
• 應用程式：定義事務的邊界，指定全域性事務中的操作。

分散式事務使用二階段提交（tow-phase commit）的方式。在第一個階段，所有參與全域性事務的節點都開始轉唄（PREPARE），告訴事務管理器他們準備好提交了。第二個階段，事務管理器告訴資源管理器執行ROLLBACK還是COMMIT。如果任何一個節點顯示不能提交，則所有的節點都被告知需要回滾。