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

圖片

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

如果遇到數(shù)據(jù)暴增，我們怎么辦？

我們可以通過水平切分。

圖片

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

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

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

第一步：

圖片

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

第二步:

圖片

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

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

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

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

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

圖片

有這些一些收尾工作：

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

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

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

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

這一步，數(shù)據(jù)庫單實例數(shù)據(jù)量減半了。

InnoDB引擎為什么高效?

技術(shù)上怎么控制并發(fā)操作？

-鎖

-數(shù)據(jù)多版本

鎖

-簡單暴力，任務(wù)執(zhí)行過程的本質(zhì)是串行的

-出現(xiàn)了共享鎖和排它鎖

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

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

共享鎖和排他鎖的區(qū)別?

-共享鎖，讀可以并行

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

總結(jié)下：一但寫數(shù)據(jù)沒有完成，數(shù)據(jù)是不能被其他任務(wù)讀取的，這對并發(fā)有著比較大的影響。

有沒有可能，進一步提高并發(fā)呢？

數(shù)據(jù)多版本

圖片

-核心原理

 （1）寫任務(wù)發(fā)生的時候，將數(shù)據(jù)克隆一份，以版本號區(qū)分

 （2）寫任務(wù)操作克隆的數(shù)據(jù)，直至提交

 （3）讀取數(shù)據(jù)還是舊版本上，不阻塞

所以并發(fā)提高演進的思路

1.普通鎖，串行執(zhí)行

2.讀寫鎖，讀讀可以并發(fā)

3.數(shù)據(jù)多版本，讀寫都可以并發(fā)

對應(yīng)到innodb，是怎么處理的呢？

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

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

優(yōu)化：將修改的行寫到redo日志中，再定期刷新到硬盤中。這里的寫日志是順序?qū)懀梢蕴岣咝阅堋Ｈ绻幸豢虜?shù)據(jù)奔潰，可以讀取redo日志恢復(fù)數(shù)據(jù)。

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

舉例說明：

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

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

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

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

MVCC就是通過“讀取舊版本數(shù)據(jù)”來降低并發(fā)事務(wù)的鎖沖突，提高任務(wù)的并發(fā)度。

innodb為何能做到這么高的并發(fā)？

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

總結(jié)

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

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

(3)redo日志保證已提交事務(wù)的ACID特性，設(shè)計思路是，通過順序?qū)懱娲S機寫，提高并發(fā)；

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

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

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

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