初探InnoDB存儲引擎的架構設計
前言
InnoDB組件結構：
buffer pool : 緩沖池，緩存磁盤的數據
redo log buffer ：記錄對緩沖池的操作，根據策略寫入磁盤防止宕機但事務已經提交而丟失數據
undo log ：當對緩沖池的數據進行修改時，在事務未提交的時候都可以進行回滾，將舊值寫入 undo 日志文件便于回滾，此時緩沖池的數據與磁盤中的不一致，是臟數據
1. Buffer Pool
假設現在有一條更新語句：
update users set name = 'lisi' where id = 1
需要更新到數據庫，InnoDB會執(zhí)行哪些操作呢？
首先，InnoDB會判讀緩沖池里是否存在 id = 1 這條數據，如果不存在則從磁盤中加載到緩沖池中，而且還會對這行數據加獨占鎖，防止多個sql同時修改這行數據。
2. undo 日志文件
假設 id = 1 這條數據name原來的值 name = 'zhangsan'，現在我們要更新為 name = 'lisi' , 那么我們就需要把舊值name='zhangsan'和id=1這些信息寫入到undo日志文件中。
對于熟悉數據庫的同學來說都了解事務的概念，在事務未提交之前，所有操作都有可能進行回滾，即可以把 name = 'lisi' 回滾到 name = 'zhangsan'，所以將更新前的值寫到undo日志文件。
3. 更新buffer pool 數據
在undo日志文件寫入完畢之后，便開始更新內存中的這條數據。把 id = 1 的 name = 'zhangsan' 更新為 name = 'lisi'。這時內存中的數據已經更新完畢，但磁盤上的還沒有變化，此時出現了不一致的臟數據。
這時可能有一個疑問，萬一事務提交完成，但MySQL服務宕機了，而內存中的數據還沒寫入到磁盤，是不是會造成數據丟失而造成sql執(zhí)行數據前后不一致？
4. redo log buffer
在InnoDB結構中，有一個 redo log buffer 緩沖區(qū)存放redo日志，所謂redo日志，例如 把id=1，name='zhangsan'修改為name='lisi' 便是一條日志。
但這時redo log buffer 還僅僅存在內存中，沒能實現MySQL宕機后的數據恢復。
5. 事務沒提交，數據庫宕機后有影響嗎？
其實并沒有影響，事務沒有提交，意味著執(zhí)行沒有成功，就算MySQL崩潰或者宕機后，內存中的 buffer pool 和 redo log buffer 修改過的數據都會丟失，也并不影響數據前后的一致性。如果事務提交失敗，那數據庫的數據更加不會改變。
6. 提交事務，redo日志的配置策略
在提交事務時，redo日記會根據策略實現把redo日志從 redo log buffer 里寫入磁盤。策略通過 innoDB_flush_log_at_trx_commit 來配置。
innoDB_flush_log_at_trx_commit的參數為0，就算事務提交后，也不會把redo日志寫入磁盤。MySQL宕機后會內存中的數據會丟失。
innoDB_flush_log_at_trx_commit的參數為1，事務提交后，redo日志會從內存刷入磁盤，只要事務提交成功，redo log 就必然存在磁盤里。
此時就算buffer pool 的數據沒有刷進磁盤，也可以從redo log 中得知修改過哪些數據，MySQL宕機重啟后，可以從redo日志中恢復修改的數據。
innoDB_flush_log_at_trx_commit的參數為2，事務提交后，redo log 僅僅停留在 os cache 中，還沒刷進磁盤，萬一此時服務宕機了。那么os cache 中的數據也會丟失，即使事務提交成功，也會造成數據丟失。
看完這幾種相信為了保證數據安全，參數為1是最佳策略。
7. 事務的最終提交，binlog
binlog其實是屬于MySQL Server 的日志文件，而在這出提出是因為與redo log有著很大的關聯。
1) biglog 與 redo log的區(qū)別
redo log:記錄的是偏物理性質重做日志，比如 “對哪個數據頁中的什么記錄，做了哪些修改”
binlog：偏向于邏輯性的日志，如：“對users表中的id=10的一行數據做了更新操作，更新以后的值是什么”
2) 提交事務的時候同時寫入binlog
在執(zhí)行更新的同時，innoDB與執(zhí)行器一直在交互，包括加載數據到緩沖池，寫入undo日志文件，更新內存數據，寫redo日志和刷入磁盤等。而對binlog的寫入也是由執(zhí)行器執(zhí)行。
其中 1、2、3、4步驟為執(zhí)行更新語句做的事，而 5、6是提交事務開始做的事。
3) binlog日志刷盤策略分析
sync_binlog參數控制binlog的刷盤策略
sync_ binlog默認值是0，提交事務后，會把binlog日志存在 os cache 中，MySQL宕機后會造成os cache中數據的丟失
sync_binlog 值為1，提交事務后，把binlog日志直接刷入磁盤中。
4) 基于binlog 和 redo log 完成事務的提交
binlog寫入磁盤后，會把binlog日志文件所在的位置和文件名稱都寫入redo log日志文件中，同時在redo log日志文件里寫入一個commit標記。
5) commit 標記有什么意義？
commit 標記意義著保持redo log 和 binlog 日志一致。如果在步驟5或者步驟6，事務提交開始，MySQL宕機了，redo log 中并沒有commit標記，都算事務提交失敗。
意味著 commint 標記是事務最終提交成功。
8. buffer pool 臟數據刷入磁盤
臟數據刷入磁盤是由后臺IO線程隨機刷入磁盤的。
這時候考慮到，在刷入磁盤之前，MySQL宕機怎么辦？這時候，事務已經提交成功，redo log 中也有commit標記，就算宕機了，重啟后，也會根據redo日志文件把數據更新到內存中，等待IO線程的刷盤。
9. 總結
通過更新語句執(zhí)行分析之后，了解到InnoDB存儲引擎中包含了 buffer pool 緩沖池、redo log buffer 緩沖區(qū)等緩存數據，undo、reod log等日志文件，同時也有MySQL Server 的日志文件。
在執(zhí)行更新語句的時候，會修改buffer pool、寫undo日志文件、 寫redo log buffer等操作；提交事務時，會將redo log 刷盤，binlog刷盤，寫入binlog文件名稱和位置，寫入commit標記,最后等待IO線程將buffer pool的臟數據隨機刷盤。
關注公眾號【Java技術江湖】后回復“PDF”即可領取200+頁的《Java工程師面試指南》
強烈推薦，幾乎涵蓋所有Java工程師必知必會的知識點，不管是復習還是面試，都很實用。
