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

圖片

如上圖所示，兩個(gè)相互同步的主庫使用相同的虛擬IP，當(dāng)主庫掛掉的時(shí)候，虛擬IP自動(dòng)漂移到另外一臺(tái)主庫，整個(gè)過程用戶是無感知的。使用雙主同步+keepalived+虛ip的方式進(jìn)行。

如果遇到數(shù)據(jù)暴增，我們?cè)趺崔k？

我們可以通過水平切分。

圖片

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

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

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

第一步：

圖片

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

第二步:

圖片

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

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

（a）即使%2尋庫和%4尋庫同時(shí)存在，也不影響數(shù)據(jù)的正確性，因?yàn)榇藭r(shí)仍然是雙主數(shù)據(jù)同步的；

（b）即使%4=0與%4=2的尋庫落到同一個(gè)數(shù)據(jù)庫實(shí)例上，也不影響數(shù)據(jù)的正確性，因?yàn)榇藭r(shí)仍然是雙主數(shù)據(jù)同步的；

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

圖片

有這些一些收尾工作：

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

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

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

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

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

InnoDB引擎為什么高效?

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

-鎖

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

鎖

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

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

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

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

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

-共享鎖，讀可以并行

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

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

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

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

圖片

-核心原理

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

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

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

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

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

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

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

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

先了解三個(gè)概念：redo、undo、回滾段

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

優(yōu)化：將修改的行寫到redo日志中，再定期刷新到硬盤中。這里的寫日志是順序?qū)?，可以提高性能。如果有一刻?shù)據(jù)奔潰，可以讀取redo日志恢復(fù)數(shù)據(jù)。

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

舉例說明：

-insert操作，undo日志存儲(chǔ)的是PK（rowid），回滾時(shí)直接刪除

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

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

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

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

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

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

總結(jié)

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

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

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

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

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

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

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