首先我們先來看下數據庫的高可用一般都是怎么實現的。我們還是借用圖來說明。真想手繪。

圖片

如上圖所示，兩個相互同步的主庫使用相同的虛擬IP，當主庫掛掉的時候，虛擬IP自動漂移到另外一臺主庫，整個過程用戶是無感知的。使用雙主同步+keepalived+虛ip的方式進行。

如果遇到數據暴增，我們怎么辦？

我們可以通過水平切分。

圖片

上圖所示，用戶庫user分布在兩臺服務器上，ip0和ip1。通過用戶取模得方式，模2余0到ip0的機器上，反之到ip1的機器上，同時ip0和ip1并行做了雙主同步，這樣做到了水平切分和高可用。

新的問題來了，分成n庫以后，隨著數據量的不斷增加，要增加到2*n庫的時候，數據如何擴容，數據如何平滑遷移，如何對外提供服務，保證數據的可用性？(一連串的靈魂拷問)

1.停服升級（暫時跳過）2.假設上面每個庫ip0和ip1每個庫都有1億數據，如何平滑擴容，增加實例數，降低單庫數據量呢？

第一步：

圖片

這樣能保證原來的數據不變，還可以路由到原來的機器上。

第二步:

圖片

這里需要服務層重新reload，高級一點可以通過配置中心向服務層發信息，重新讀取配置文件，重新初始化連接數據庫。完成之后，數據庫實例從2變成4個，過程在秒級完成。

整個過程可以逐步重啟，對服務的正確性和可用性完全沒有影響：

（a）即使%2尋庫和%4尋庫同時存在，也不影響數據的正確性，因為此時仍然是雙主數據同步的；

（b）即使%4=0與%4=2的尋庫落到同一個數據庫實例上，也不影響數據的正確性，因為此時仍然是雙主數據同步的；

上面對數據庫實例進行了擴展，但是數據的數量并沒有降低，我們還需要再做一步。

圖片

有這些一些收尾工作：

（a）把雙虛擬ip修改回單虛擬ip；

（b）解除舊的雙主同步，讓成對庫的數據不再同步增加；

（c）增加新的雙主同步，保證高可用；

（d）刪除掉冗余數據，例如：ip0里%4=2的數據全部刪除，只為%4=0的數據提供服務；

這一步，數據庫單實例數據量減半了。

InnoDB引擎為什么高效?

技術上怎么控制并發操作？

-鎖

-數據多版本

鎖

-簡單暴力，任務執行過程的本質是串行的

-出現了共享鎖和排它鎖

 --共享鎖(S鎖)，讀取數據加S鎖

 --排他鎖(X鎖) 修改時加X鎖

共享鎖和排他鎖的區別?

-共享鎖，讀可以并行

-排他鎖跟任何鎖互斥，讀和寫都不可以并行

總結下：一但寫數據沒有完成，數據是不能被其他任務讀取的，這對并發有著比較大的影響。

有沒有可能，進一步提高并發呢？

數據多版本

圖片

-核心原理

 （1）寫任務發生的時候，將數據克隆一份，以版本號區分

 （2）寫任務操作克隆的數據，直至提交

 （3）讀取數據還是舊版本上，不阻塞

所以并發提高演進的思路

1.普通鎖，串行執行

2.讀寫鎖，讀讀可以并發

3.數據多版本，讀寫都可以并發

對應到innodb，是怎么處理的呢？

先了解三個概念：redo、undo、回滾段

redo：數據庫事務提交之后，必須將更新后的數據刷新到硬盤上，保證ACID原則。這里是隨機讀寫的，如果來個事務就寫一次，相當影響吞吐量。

優化：將修改的行寫到redo日志中，再定期刷新到硬盤中。這里的寫日志是順序寫，可以提高性能。如果有一刻數據奔潰，可以讀取redo日志恢復數據。

undo：事務未提交時，可以將修改前的數據存在undo日志里，當崩潰或者事務回滾時，利用undo日志撤銷修改。

舉例說明：

-insert操作，undo日志存儲的是PK（rowid），回滾時直接刪除

-update/delete操作，undo日志記錄舊數據的row，回滾時直接恢復。

回滾段：存儲undo日志的地方，就是回滾段。

Innodb是基于版本并發控制的存儲引擎。

MVCC就是通過“讀取舊版本數據”來降低并發事務的鎖沖突，提高任務的并發度。

innodb為何能做到這么高的并發？

回滾段的數據，也就是歷史數據的快照，這些數不會被改變,select操作可以為所欲為的并發讀取

總結

(1)常見并發控制保證數據一致性的方法有鎖，數據多版本；

(2)普通鎖串行，讀寫鎖讀讀并行，數據多版本讀寫并行；

(3)redo日志保證已提交事務的ACID特性，設計思路是，通過順序寫替代隨機寫，提高并發；

(4)undo日志用來回滾未提交的事務，它存儲在回滾段里；

(5)InnoDB是基于MVCC的存儲引擎，它利用了存儲在回滾段里的undo日志，即數據的舊版本，提高并發；

(6)InnoDB之所以并發高，快照讀不加鎖；

(7)InnoDB所有普通select都是快照讀；