聊一聊數據庫并發控制和恢復機制

　　簡單的說并發就是允許多個客戶端訪問一個數據庫，但是如何處理并發請求卻有一些學問，我們開始吧。

　　動物可以分為人和其它動物。數據庫也可以按照這個邏輯劃分。數據庫分為SQLite和其它數據庫。SQLite就是一個簡單的文件，本身不提供通過網絡訪問的功能。要對它實現并發，一般做法是將它放在一個文件服務器上， 比如drobox.但是一旦有客戶端進行寫操作，其他客戶端就不能進行任何操作了。

　　其他數據庫實現并發更加高效，就是在存放數據庫文件的電腦上同樣運行著一臺數據庫服務器。客戶端發送SQL客戶端通過查詢返回給客戶端結果。

　　在往下看之前，我們需要復習一下兩個基本概念。Transaction（事務）: a transaction is a sequence of statements.ACIDAtomic. 一旦一個事務要不被全部執行，要不一個也沒有執行。（這里涉及到回滾rollback）Consistent 執行事務后，數據庫本身的約束不能變化Isolated 兩個事務在人類看來是按順序執行的，雖然本身他們可能是interleaved的Durable 提交后的事務應該被寫入磁盤，永久存在。

　　它違背了ACID的I.因為這兩個的運行結果，在人類看來不可能是順序執行的。

　　我們可以簡單總結數據庫操作時讀，寫和基本計算操作。如果T1和T2順序執行，T2需要等待T1執行完畢，可明明T2更小，讓T2等待這么長時間是不是不太合理？

　　這個雖然實際上沒有按順序執行，但是和先執行T1,在執行T2結果是一樣的。可是依舊有一個問題，如果T1在 處執行失敗了，怎么辦？回滾T1嗎？那T2怎么辦；同時回滾T2嗎？T2已經執行完畢了

　　這里就需要大家弄清這個概念：recoverable schedules如果一個事務A要讀一個數據，這個數據又被另一個B事物修改，就必須等待B事務提交。人類看來是這樣的。其實也有可能出現如上圖的這種情況，這是實際執行順序，人類認為是T2在T1后執行的。遇到這種情況，T2不能確認commit,必須等待T1commit.

　　數據庫恢復需要日志，日志簡單分為undo log: a log that allows undoing changesRedo log: a log that allows redoing changesUndo/Redo log: Combination.

　　實際主流用到的是undo/redo log.

　　簡單的undo log

　　在數據被寫入磁盤之前，舊的數據會被寫入日志，這樣一旦事務失敗，我們可以可以根據日志回滾。比如下圖

　　但是這個不夠高效，實際我們會使用緩存，減少寫入磁盤的次數，同時查詢也可以之前在內存中進行，一舉兩得，如下圖

　　Redo Log

　　這個和undo log很像，不過它存儲的是更改后的數據，這樣就能保證，事務的失敗的時候，可以從新來一遍，如下圖

　　Undo/Redo Log

　　這種類型的日志就是前兩者的結合體。

　　日志是保證ACID的方法手段，使用日志肯定會降低性能，但是不能因為費時間就不吃飯了吧，哈哈。沒有日志我覺得宇宙會隨時爆炸，而且還不能重啟。另外一個對并發很重要的概念就是鎖。

　　我們下一篇再見，祝你愉快！