寫在最前:

本文主要描述在網站的不同的并發訪問量級下，Mysql架構的演變

可擴展性

架構的可擴展性往往和并發是息息相關，沒有并發的增長，也就沒有必要做高可擴展性的架構，這里對可擴展性進行簡單介紹一下，常用的擴展手段有以下兩種

Scale-up : 縱向擴展，通過替換為更好的機器和資源來實現伸縮，提升服務能力

Scale-out : 橫向擴展, 通過加節點（機器）來實現伸縮，提升服務能力

對于互聯網的高并發應用來說，無疑Scale out才是出路，通過縱向的買更高端的機器一直是我們所避諱的問題，也不是長久之計，在scale out的理論下，可擴展性的理想狀態是什么？

可擴展性的理想狀態

一個服務，當面臨更高的并發的時候，能夠通過簡單增加機器來提升服務支撐的并發度，且增加機器過程中對線上服務無影響(no down time)，這就是可擴展性的理想狀態！

　架構的演變V1.0 簡單網站架構

一個簡單的小型網站或者應用背后的架構可以非常簡單, 數據存儲只需要一個mysql instance就能滿足數據讀取和寫入需求（這里忽略掉了數據備份的實例），處于這個時間段的網站，一般會把所有的信息存到一個database instance里面。

在這樣的架構下，我們來看看數據存儲的瓶頸是什么？

1.數據量的總大小 一個機器放不下時

2.數據的索引（B+ Tree）一個機器的內存放不下時

3.訪問量(讀寫混合)一個實例不能承受

只有當以上3件事情任何一件或多件滿足時，我們才需要考慮往下一級演變。 從此我們可以看出，事實上對于很多小公司小應用，這種架構已經足夠滿足他們的需求了，初期數據量的準確評估是杜絕過度設計很重要的一環，畢竟沒有人愿意為不可能發生的事情而浪費自己的經歷。

這里簡單舉個我的例子，對于用戶信息這類表 （3個索引），16G內存能放下大概2000W行數據的索引，簡單的讀和寫混合訪問量3000/s左右沒有問題，你的應用場景是否

V2.0 垂直拆分

一般當V1.0 遇到瓶頸時，首先最簡便的拆分方法就是垂直拆分，何謂垂直？就是從業務角度來看，將關聯性不強的數據拆分到不同的instance上，從而達到消除瓶頸的目標。以圖中的為例，將用戶信息數據，和業務數據拆分到不同的三個實例上。對于重復讀類型比較多的場景，我們還可以加一層cache，來減少對DB的壓力。

在這樣的架構下，我們來看看數據存儲的瓶頸是什么？

1.單實例單業務 依然存在V1.0所述瓶頸

遇到瓶頸時可以考慮往本文更高V版本升級, 若是讀請求導致達到性能瓶頸可以考慮往V3.0升級， 其他瓶頸考慮往V4.0升級

V3.0 主從架構

此類架構主要解決V2.0架構下的讀問題，通過給Instance掛數據實時備份的思路來遷移讀取的壓力，在Mysql的場景下就是通過主從結構，主庫抗寫壓力，通過從庫來分擔讀壓力，對于寫少讀多的應用，V3.0主從架構完全能夠勝任

在這樣的架構下，我們來看看數據存儲的瓶頸是什么？

1.寫入量主庫不能承受

V4.0 水平拆分

對于V2.0 V3.0方案遇到瓶頸時，都可以通過水平拆分來解決，水平拆分和垂直拆分有較大區別，垂直拆分拆完的結果，在一個實例上是擁有全量數據的，而水平拆分之后，任何實例都只有全量的1/n的數據，以下圖Userinfo的拆分為例，將userinfo拆分為3個cluster，每個cluster持有總量的1/3數據，3個cluster數據的總和等于一份完整數據（注：這里不再叫單個實例 而是叫一個cluster 代表包含主從的一個小mysql集群）

數據如何路由？1.Range拆分

sharding key按連續區間段路由，一般用在有嚴格自增ID需求的場景上，如Userid, Userid Range的小例子：以userid 3000W 為Range進行拆分 1號cluster userid 1-3000W 2號cluster userid 3001W-6000W

2.List拆分

List拆分與Range拆分思路一樣，都是通過給不同的sharding key來路由到不同的cluster,但是具體方法有些不同,List主要用來做sharding key不是連續區間的序列落到一個cluster的情況，如以下場景：假定有20個音像店，分布在4個有經銷權的地區，如下表所示：

地區

商店ID 號

北區

3, 5, 6, 9, 17

東區

1, 2, 10, 11, 19, 20

西區

4, 12, 13, 14, 18

中心區

7, 8, 15, 16