1. 基本概念

1.1 單庫

1.2 分片

分片解決的是“數據量太大”的問題，也就是通常說的“水平切分”。

一旦引入分片，勢必有“數據路由”的概念，哪個數據訪問哪個庫。

路由規則通常由3種方式：

（1）範圍：range

優點：簡單，容易擴展

缺點：各庫壓力不均（新號段更活躍）

（2）哈希：hash

優點：簡單，數據均衡，負載均勻

缺點：遷移麻煩（2庫擴3庫數據要遷移）

（3）路由服務：router-config-server

優點：靈活性強，業務與路由算法解耦

缺點：每次訪問數據庫前多一次查詢

大部分互聯網公司采用的方案2：哈希分庫、哈希路由

1.3 分組

分組解決“可用性”問題，分組通常通過主從復制的方式實現。

互聯網公司數據庫實際軟件架構是：又分片、又分組（如下圖）

2. 數據庫架構設計思路

（1）如何保證數據可用性

（2）如何提高數據庫讀性能（大部分應用讀多寫少，讀會先成為瓶頸）

（3）如何保證一致性

（4）如何提高擴展性

2.1 如何保證數據庫“讀”高可用

冗余讀庫

冗余讀庫帶倆的副作用，讀寫有延時，可能不一致。

上面這個圖中，寫仍然是單點，不能保證寫高可用。

2.2 如何保證數據庫“寫”高可用

冗余寫庫

采用雙主互備的方式，可以冗余寫庫。

帶來的副作用，雙寫同步，數據可能沖突。

2.3 雙主當主從讀寫

仍然是雙主，但只有一個主提供服務（讀+寫），另一個主是“shadow-master”，只用倆保證高可用，平時不提供服務。master掛了，shadow-master頂上（virtual ip漂移，對業務層透明，不需要人工介入）

優點

（1）讀寫沒有延時

（2）讀寫高可用

缺點：

（1）不能通過加從庫的方式擴展讀性能

（2）資源利用率為50%，一臺冗余主沒有提供服務

2.4 如何擴展讀性能

提高讀性能的方式一致有三種：（1）建立索引（2）增加從庫（3）增加緩存

2.5 如何保證一致性

主從數據庫的一致性，通常有兩種解決方案：

（1）中間件

（2）強制讀寫 -- 雙主當主從讀寫架構

數據庫與緩存間的不一致：

常見的緩存架構如上，此時

寫操作的順序是：

（1）淘汰cache

（2）寫數據庫

讀操作的順序是：

（1）讀cache，如果cache hit則返回

（2）如果cache miss，則讀從庫

（3）讀從庫後，將數據放回cache

在一些異常時序情況下，有可能從從庫讀到舊數據（同步還沒有完成），舊數據如cache後，數據會長期不一致。

解決辦法是“緩存雙淘汰”，寫操作時序升級為：

（1）淘汰cache

（2）寫數據庫

（3）在經驗“主從同步延時窗口時間”後，再次發起一個異步淘汰cache的請求

這些，即使有臟數據如cache，一個小的時間窗口之後，臟數據還是會被淘汰，帶來的代價是，多引入一次讀miss。

2.6 如何提高數據庫的擴展性

原來用hash的方式路由，分為2個庫，數據量還是太大，要分為3個庫，勢必需要進行數據遷移。

如何實現秒級擴容？

假設數據庫架構采用：雙主當主從讀寫

不做2庫變3庫的擴容，而是做2庫變4庫（庫加倍）的擴容（未來4->8->16）

假設現在有userid=1,2,3,4,5,6,7,8的用戶。

hash = userid % 2，hash如果等於0，則存儲在m0庫，如果等於1，則存儲在m1庫

擴容步驟：

（1）將shadow-master庫提升

（2）修改配置，2庫變4庫（原來userid%2，現在改為userid%4）

擴容成：

原來mod2為偶數的部分，現在會mod4余1或2

原來mod2為奇數的部分，現在會mod4余1或3

數據不需要遷移，同時互主互相同步，一邊是余0，一邊余2，兩邊數據同步也不會沖突，秒級完成擴容。

最後，要做一些收尾工作：

（1）將舊的雙主同步解除

（2）增加新的雙主（雙主是保證可用性的，shadow-master平時不提供服務）

（3）刪除多余的數據（余0的主，可以將余2的數據刪除掉）

這樣，秒級別內，就完成了2庫變4庫的擴展。

數據庫架構