摘要:
本文主要描述在網站的不同的併發訪問量級下Mysql架構的演變歷程。架構的可擴展性往往和併發是息息相關,沒有併發的增長,也就沒有必要做高可擴展性的架構。常用的擴展手段主要有Scale-up和Scale-out兩種,前者爲縱向擴展,主要通過替換爲更好的機器和資源來實現伸縮,提升服務能力;後者爲橫向擴展,通過加節點(機器)來實現伸縮,提升服務能力。對於互聯網的高併發應用來說,Scale-out纔是出路,通過縱向的買更高端的機器一直是我們所避諱的問題。在scale-out的理論下,可擴展性的理想狀態就是,對於一個服務,當面臨更高的併發需求時,能夠通過簡單增加機器來提升服務支撐的併發度,且增加機器過程中對線上服務無影響(no down time),這就是可擴展性的理想狀態!
聲明與致謝:
本文轉載於博客園博主大熊先生的《Mysql在大型網站的應用架構演變》一文。
一. 簡單網站架構 (V1.0)
一個簡單的小型網站或者應用背後的架構可以非常簡單, 數據存儲只需要一個mysql instance就能滿足數據讀取和寫入需求(這裏忽略掉了數據備份的實例),處於這個時間段的網站,一般會把所有的信息存到一個database instance裏面。注意,DAL爲 Data Access Layer 的縮寫,即數據訪問層。
在這樣的架構下,我們來看看數據存儲的瓶頸是什麼?
- 數據量的總大小,一個機器放不下時;
- 數據的索引(B+ Tree)一個機器的內存放不下時;
- 訪問量(讀寫混合)一個實例不能承受;
只有當以上3件事情任何一件或多件滿足時,我們才需要考慮往下一級演變。由此我們可以看出,事實上對於很多小公司小應用,這種架構已經足夠滿足他們的需求了,初期數據量的準確評估是杜絕過度設計很重要的一環,畢竟沒有人願意爲不可能發生的事情而浪費自己的精力。
這裏簡單舉個我的例子,對於用戶信息這類表(3個索引),16G內存能放下大概2000W行數據的索引,簡單的讀和寫混合訪問量3000/s左右沒有問題,你的應用場景是否有這麼高的需求?
二. 垂直拆分 (V2.0)
一般當V1.0 遇到瓶頸時,首先最簡便的拆分方法就是垂直拆分,何謂垂直?就是從業務角度來看,將關聯性不強的數據拆分到不同的instance上,從而達到消除瓶頸的目標。如下圖所示,將用戶信息數據和業務數據拆分到不同的三個實例上。對於重複讀類型比較多的場景,我們還可以加一層cache,來減少對DB的壓力。
在這樣的架構下,我們的數據存儲依然存在V1.0所述瓶頸,也就是說,還是單實例單業務的。遇到瓶頸時可以考慮往本文更高版本升級,若是讀請求導致達到性能瓶頸可以考慮往V3.0升級,其他瓶頸考慮往V4.0升級。
三. 主從架構 (V3.0)
此類架構主要解決V2.0架構下的 讀問題,通過給Instance掛數據實時備份的思路來遷移讀取的壓力,在Mysql的場景下就是通過主從結構,主庫抗寫壓力,通過從庫來分擔讀壓力,對於寫少讀多的應用,V3.0主從架構完全能夠勝任。
在這樣的架構下,數據存儲的瓶頸主要在於:寫入量主庫不能承受。
四. 水平拆分(V4.0)
當V2.0、V3.0方案遇到瓶頸時,都可以通過水平拆分來解決。水平拆分和垂直拆分有較大區別,垂直拆分拆完的結果,在一個實例上是擁有全量數據的,而水平拆分之後,任何實例都只有全量的1/n的數據,以下圖Userinfo的拆分爲例,將userinfo拆分爲3個cluster,每個cluster持有總量的1/3數據,3個cluster數據的總和等於一份完整數據。注意,這裏不再叫單個實例,而是叫一個cluster代表包含主從的一個小mysql集羣。
在這樣的架構下,數據如何路由成爲了一個關鍵問題。
1、數據路由
(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,其他哈希類算法這裏就不細展開講了。
2、數據拆分後引入的問題
數據水平拆分引入的問題主要是 只能通過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來保證直到成功爲止才停止重試操作)。
3、數據存儲的瓶頸
在這個拆分理念上搭建起來的架構,理論上不存在瓶頸(sharding key能確保各cluster流量相對均衡的前提下)。不過確實有一件噁心的事情,那就是cluster擴容的時候重做數據的成本,如我原來有3個cluster,但是現在我的數據增長比較快,我需要6個cluster,那麼我們需要將每個cluster 一拆爲二,一般的做法是:
(1). 摘下一個slave,停同步;
(2). 對寫記錄增量log,實現上可以採用業務方對寫操作,多一次寫持久化mq,或者mysql主創建trigger記錄寫等方式;
(3). 開始對靜態slave做數據,一拆爲二;
(4). 回放增量寫入,直到追上的所有增量,與原cluster基本保持同步;
(5). 寫入切換,由原3個cluster切換爲6個cluster。
有沒有類似飛機空中加油的感覺,這是一個髒活,累活,容易出問題的活,爲了避免這個,我們一般在最開始的時候設計足夠多的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的髒活變成:
- 擴容縮容對前端APP透明(業務代碼不需要任何改動);
-
擴容縮容全自動化且對在線服務無影響,那麼他就拿到了作爲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的資料,有興趣的可以看看,說不定會是以後的一個解決雲數據庫擴容縮容的手段。
六. 其他資料
百度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