原創文章,轉載請註明: 轉載自http://www.cnblogs.com/Creator/

本文已經被多處轉載,包括CSDN推薦以及碼農週刊等等,閱讀數超過50w+,迴流到我部落格流量的還是比較少,不過這不重要, 後續會分享更多技術,儘量試圖把自己理解的東西描述出來(很多時候自己的理解是90分,可是描述出來就只有60分了)

CSDN的轉載 :http://www.csdn.net/article/2014-06-10/2820160

伯樂線上的轉載: http://blog.jobbole.com/70844/

當然還有大量轉載沒有寫明出處的...

寫在最前:

本文主要描述在網站的不同的併發訪問量級下,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

.


業務希望能夠把一個地區的所有資料組織到一起來搜尋,這種場景List拆分可以輕鬆搞定

3.Hash拆分

通過對sharding key 進行雜湊的方式來進行拆分,常用的雜湊方法有除餘,字串雜湊等等,除餘如按userid%n 的值來決定資料讀寫哪個cluster,其他雜湊類演算法這裡就不細展開講了。


資料拆分後引入的問題:

資料水平拆分引入的問題主要是隻能通過sharding key來讀寫操作,例如以userid為sharding key的切分例子,讀userid的詳細資訊時,一定需要先知道userid,這樣才能推算出再哪個cluster進而進行查詢,假設我需要按username進行檢索使用者資訊,需要引入額外的反向索引機制(類似HBASE二級索引),如在redis上儲存username->userid的對映,以username查詢的例子變成了先通過查詢username->userid,再通過userid查詢相應的資訊。
實際上這個做法很簡單,但是我們不要忽略了一個額外的隱患,那就是資料不一致的隱患。儲存在redis裡的username->userid和儲存在mysql裡的userid->username必須需要是一致的,這個保證起來很多時候是一件比較困難的事情,舉個例子來說,對於修改使用者名稱這個場景,你需要同時修改redis和mysql,這兩個東西是很難做到事務保證的,如mysql操作成功 但是redis卻操作失敗了(分散式事務引入成本較高),對於網際網路應用來說,可用性是最重要的,一致性是其次,所以能夠容忍小量的不一致出現. 畢竟從佔比來說,這類的不一致的比例可以微乎其微到忽略不計(一般寫更新也會採用mq來保證直到成功為止才停止重試操作)

在這樣的架構下,我們來看看資料儲存的瓶頸是什麼?
在這個拆分理念上搭建起來的架構,理論上不存在瓶頸(sharding key能確保各cluster流量相對均衡的前提下),不過確有一件噁心的事情,那就是cluster擴容的時候重做資料的成本,如我原來有3個cluster,但是現在我的資料增長比較快,我需要6個cluster,那麼我們需要將每個cluster 一拆為二,一般的做法是
1.摘下一個slave,停同步,
2.對寫記錄增量log(實現上可以業務方對寫操作 多一次寫持久化mq  或者mysql主建立trigger記錄寫 等等方式)
3.開始對靜態slave做資料, 一拆為二
4.回放增量寫入,直到追上的所有增量,與原cluster基本保持同步
5.寫入切換,由原3 cluster 切換為6cluster

有沒有類似飛機空中加油的感覺,這是一個髒活,累活,容易出問題的活,為了避免這個,我們一般在最開始的時候,設計足夠多的sharding cluster來防止可能的cluster擴容這件事情

V5.0  雲端計算 騰飛(雲資料庫) 

雲端計算現在是各大IT公司內部作為節約成本的一個突破口,對於資料儲存的mysql來說,如何讓其成為一個saas(Software as a Service)是關鍵點。在MS的官方文件中,把構建一個足夠成熟的SAAS(MS簡單列出了SAAS應用的4級成熟度)所面臨的3個主要挑戰:可配置性,可擴充套件性,多使用者儲存結構設計稱為"three headed monster". 可配置性和多使用者儲存結構設計在Mysql saas這個問題中並不是特別難辦的一件事情,所以這裡重點說一下可擴充套件性。

Mysql作為一個saas服務,在架構演變為V4.0之後,依賴良好的sharding key設計, 已經不再存在擴充套件性問題,只是他在面對擴容縮容時,有一些髒活需要幹,而作為saas,並不能避免擴容縮容這個問題,所以只要能把V4.0的髒活變成 1. 擴容縮容對前端APP透明(業務程式碼不需要任何改動)  2.擴容縮容全自動化且對線上服務無影響 那麼他就拿到了作為Saas的門票.

對於架構實現的關鍵點,需要滿足對業務透明,擴容縮容對業務不需要任何改動,那麼就必須eat our own dog food,在你mysql saas內部解決這個問題,一般的做法是我們需要引入一個Proxy,Proxy來解析sql協議,按sharding key 來尋找cluster, 判斷是讀操作還是寫操作來請求主 或者 從,這一切內部的細節都由proxy來遮蔽。
這裡借淘寶的圖來列舉一下proxy需要幹哪些事情

百度公開的技術方案中也有類似的解決方案,見文章最後資料部分連結


對於架構實現的關鍵點,擴容縮容全自動化且對線上服務無影響; 擴容縮容對應到的資料操作即為資料拆分和資料合併,要做到完全自動化有非常多不同的實現方式,總體思路和V4.0介紹的瓶頸部分有關,目前來看這個問題比較好的方案就是實現一個偽裝slave的sync slave, 解析mysql同步協議,然後實現資料拆分邏輯,把全量資料進行拆分。具體架構見下圖:

其中Sync slave對於Original Master來說,和一個普通的Mysql Slave沒有任何區別,也不需要任何額外的區分對待。需要擴容/縮容時,掛上一個Sync slave,開始全量同步+增量同步,等待一段時間追資料。以擴容為例,若擴容後的服務和擴容前資料已經基本同步了,這時候如何做到切換對業務無影響? 其實關鍵點還是在引入的proxy,這個問題轉換為了如何讓proxy做熱切換後端的問題。這已經變成一個非常好處理的問題了.

另外值得關注的是:2014年5月28日——為了滿足當下對Web及雲應用需求,甲骨文宣佈推出MySQL Fabric,在對應的資料部分我也放了很多Fabric的資料,有興趣的可以看看,說不定會是以後的一個解決雲資料庫擴容縮容的手段

V more ?

等待革命...

其他資料

百度Dbproxy設計   http://tech.it168.com/a2012/0413/1337/000001337034.shtml
淘寶RDS 雲資料庫設計: http://blog.csdn.net/ywh147/article/details/8954625     http://www.infoq.com/cn/news/2012/10/taobao-ump
Mysql  Fabric
http://mysqlmusings.blogspot.jp/2013/09/brief-introduction-to-mysql-fabric.html
http://vnwrites.blogspot.jp/2013/09/mysqlfabric-sharding-introduction.html
http://vnwrites.blogspot.in/2013/09/mysqlfabric-sharding-example.html
http://vnwrites.blogspot.in/2013/09/mysqlfabric-sharding-migration.html
http://vnwrites.blogspot.jp/2013/09/mysqlfabric-sharding-maintenance.html