本文主要描述在網(wǎng)站的不同的并發(fā)訪問量級下或颊，Mysql架構(gòu)的演變
可擴展性
架構(gòu)的可擴展性往往和并發(fā)是息息相關(guān)茶宵，沒有并發(fā)的增長倍踪，也就沒有必要做高可擴展性的架構(gòu)梯捕，這里對可擴展性進行簡單介紹一下匙瘪，常用的擴展手段有以下兩種Scale-up : 縱向擴展铆铆，通過替換為更好的機器和資源來實現(xiàn)伸縮，提升服務(wù)能力Scale-out : 橫向擴展, 通過加節(jié)點（機器）來實現(xiàn)伸縮丹喻，提升服務(wù)能力 對于互聯(lián)網(wǎng)的高并發(fā)應(yīng)用來說薄货，無疑Scale out才是出路，通過縱向的買更高端的機器一直是我們所避諱的問題驻啤，也不是長久之計菲驴，在scale out的理論下，可擴展性的理想狀態(tài)是什么骑冗？
可擴展性的理想狀態(tài)
一個服務(wù)赊瞬，當(dāng)面臨更高的并發(fā)的時候先煎，能夠通過簡單增加機器來提升服務(wù)支撐的并發(fā)度，且增加機器過程中對線上服務(wù)無影響(no down time)巧涧，這就是可擴展性的理想狀態(tài)薯蝎！
架構(gòu)的演變
V1.0 簡單網(wǎng)站架構(gòu)
一個簡單的小型網(wǎng)站或者應(yīng)用背后的架構(gòu)可以非常簡單, 數(shù)據(jù)存儲只需要一個mysql instance就能滿足數(shù)據(jù)讀取和寫入需求（這里忽略掉了數(shù)據(jù)備份的實例），處于這個時間段的網(wǎng)站谤绳，一般會把所有的信息存到一個database instance里面占锯。
在這樣的架構(gòu)下，我們來看看數(shù)據(jù)存儲的瓶頸是什么缩筛？1.數(shù)據(jù)量的總大小 一個機器放不下時2.數(shù)據(jù)的索引（B+ Tree）一個機器的內(nèi)存放不下時3.訪問量(讀寫混合)一個實例不能承受
只有當(dāng)以上3件事情任何一件或多件滿足時消略，我們才需要考慮往下一級演變。 從此我們可以看出瞎抛，事實上對于很多小公司小應(yīng)用艺演，這種架構(gòu)已經(jīng)足夠滿足他們的需求了，初期數(shù)據(jù)量的準(zhǔn)確評估是杜絕過度設(shè)計很重要的一環(huán)桐臊，畢竟沒有人愿意為不可能發(fā)生的事情而浪費自己的經(jīng)歷胎撤。這里簡單舉個我的例子，對于用戶信息這類表 （3個索引）断凶，16G內(nèi)存能放下大概2000W行數(shù)據(jù)的索引伤提，簡單的讀和寫混合訪問量3000/s左右沒有問題，你的應(yīng)用場景是否
V2.0 垂直拆分
一般當(dāng)V1.0 遇到瓶頸時认烁，首先最簡便的拆分方法就是垂直拆分肿男，何謂垂直？就是從業(yè)務(wù)角度來看砚著，將關(guān)聯(lián)性不強的數(shù)據(jù)拆分到不同的instance上次伶，從而達(dá)到消除瓶頸的 目標(biāo)痴昧。以圖中的為例稽穆，將用戶信息數(shù)據(jù)，和業(yè)務(wù)數(shù)據(jù)拆分到不同的三個實例上赶撰。對于重復(fù)讀類型比較多的場景舌镶，我們還可以加一層cache，來減少對DB的壓 力豪娜。
在這樣的架構(gòu)下餐胀，我們來看看數(shù)據(jù)存儲的瓶頸是什么？
1.單實例單業(yè)務(wù) 依然存在V1.0所述瓶頸
遇到瓶頸時可以考慮往本文更高V版本升級, 若是讀請求導(dǎo)致達(dá)到性能瓶頸可以考慮往V3.0升級瘤载， 其他瓶頸考慮往V4.0升級
V3.0 主從架構(gòu)
此類架構(gòu)主要解決V2.0架構(gòu)下的讀問題否灾，通過給Instance掛數(shù)據(jù)實時備份的思路來遷移讀取的壓力，在Mysql的場景下就是通過主從結(jié)構(gòu)鸣奔，主庫抗寫壓力墨技，通過從庫來分擔(dān)讀壓力惩阶，對于寫少讀多的應(yīng)用，V3.0主從架構(gòu)完全能夠勝任
在這樣的架構(gòu)下扣汪，我們來看看數(shù)據(jù)存儲的瓶頸是什么断楷？
1.寫入量主庫不能承受
V4.0 水平拆分
對于V2.0 V3.0方案遇到瓶頸時，都可以通過水平拆分來解決崭别，水平拆分和垂直拆分有較大區(qū)別冬筒，垂直拆分拆完的結(jié)果，在一個實例上是擁有全量數(shù)據(jù)的茅主，而水平拆分之 后舞痰，任何實例都只有全量的1/n的數(shù)據(jù)，以下圖Userinfo的拆分為例诀姚，將userinfo拆分為3個cluster匀奏，每個cluster持有總量的 1/3數(shù)據(jù)，3個cluster數(shù)據(jù)的總和等于一份完整數(shù)據(jù)（注：這里不再叫單個實例 而是叫一個cluster 代表包含主從的一個小mysql集群）
數(shù)據(jù)如何路由学搜？
1.Range拆分
sharding key按連續(xù)區(qū)間段路由娃善，一般用在有嚴(yán)格自增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不是連續(xù)區(qū)間的序列落到一個cluster的情況聚磺，如以下場景： 假定有20個音像店，分布在4個有經(jīng)銷權(quán)的地區(qū)炬丸，如下表所示：
地區(qū) | 商店ID 號
北區(qū) | 3, 5, 6, 9, 17
東區(qū) | 1, 2, 10, 11, 19, 20
西區(qū) | 4, 12, 13, 14, 18
中心區(qū) | 7, 8, 15, 16
業(yè)務(wù)希望能夠把一個地區(qū)的所有數(shù)據(jù)組織到一起來搜索瘫寝，這種場景List拆分可以輕松搞定
3.Hash拆分
通過對sharding key 進行哈希的方式來進行拆分，常用的哈希方法有除余,字符串哈希等等稠炬，除余如按userid%n 的值來決定數(shù)據(jù)讀寫哪個cluster焕阿，其他哈希類算法這里就不細(xì)展開講了。
數(shù)據(jù)拆分后引入的問題：
數(shù)據(jù)水平拆分引入的問題主要是只能通過sharding key來讀寫操作首启，例如以userid為sharding key的切分例子暮屡，讀userid的詳細(xì)信息時，一定需要先知道userid,這樣才能推算出再哪個cluster進而進行查詢毅桃，假設(shè)我需要按 username進行檢索用戶信息褒纲，需要引入額外的反向索引機制（類似HBASE二級索引），如在redis上存儲 username->userid的映射钥飞，以username查詢的例子變成了先通過查詢username->userid莺掠，再通過 userid查詢相應(yīng)的信息。實際上這個做法很簡單读宙，但是我們不要忽略了一個額外的隱患彻秆，那就是數(shù)據(jù)不一致的隱患。存儲在redis里的username->userid和存儲 在mysql里的userid->username必須需要是一致的，這個保證起來很多時候是一件比較困難的事情唇兑，舉個例子來說墓律，對于修改用戶名這 個場景，你需要同時修改redis和mysql,這兩個東西是很難做到事務(wù)保證的,如mysql操作成功 但是redis卻操作失敗了（分布式事務(wù)引入成本較高）,對于互聯(lián)網(wǎng)應(yīng)用來說幔亥，可用性是最重要的耻讽，一致性是其次，所以能夠容忍小量的不一致出現(xiàn). 畢竟從占比來說帕棉，這類的不一致的比例可以微乎其微到忽略不計（一般寫更新也會采用mq來保證直到成功為止才停止重試操作）
在這樣的架構(gòu)下针肥，我們來看看數(shù)據(jù)存儲的瓶頸是什么？
在這個拆分理念上搭建起來的架構(gòu)香伴，理論上不存在瓶頸（sharding key能確保各cluster流量相對均衡的前提下),不過確有一件惡心的事情慰枕，那就是cluster擴容的時候重做數(shù)據(jù)的成本，如我原來有3個 cluster即纲，但是現(xiàn)在我的數(shù)據(jù)增長比較快具帮，我需要6個cluster，那么我們需要將每個cluster 一拆為二低斋，一般的做法是1.摘下一個slave,停同步,2.對寫記錄增量log（實現(xiàn)上可以業(yè)務(wù)方對寫操作 多一次寫持久化mq 或者mysql主創(chuàng)建trigger記錄寫 等等方式）3.開始對靜態(tài)slave做數(shù)據(jù), 一拆為二4.回放增量寫入,直到追上的所有增量,與原cluster基本保持同步5.寫入切換蜂厅，由原3 cluster 切換為6cluster
有沒有類似飛機空中加油的感覺，這是一個臟活膊畴，累活掘猿，容易出問題的活，為了避免這個唇跨，我們一般在最開始的時候稠通，設(shè)計足夠多的sharding cluster來防止可能的cluster擴容這件事情
V5.0 云計算 騰飛
云計算現(xiàn)在是各大IT公司內(nèi)部作為節(jié)約成本的一個突破口，對于數(shù)據(jù)存儲的mysql來說买猖，如何讓其成為一個saas（Software as a Service）是關(guān)鍵點改橘。在MS的官方文檔中，把構(gòu)建一個足夠成熟的SAAS(MS簡單列出了SAAS應(yīng)用的4級成熟度)所面臨的3個主要挑戰(zhàn)：可配置性玉控，可擴展性飞主，多用戶存儲結(jié)構(gòu)設(shè)計稱為”three headed monster”. 可配置性和多用戶存儲結(jié)構(gòu)設(shè)計在Mysql saas這個問題中并不是特別難辦的一件事情，所以這里重點說一下可擴展性奸远。
Mysql作為一個saas服務(wù)既棺，在架構(gòu)演變?yōu)閂4.0之后，依賴良好的sharding key設(shè)計, 已經(jīng)不再存在擴展性問題懒叛，只是他在面對擴容縮容時，有一些臟活需要干耽梅，而作為saas,并不能避免擴容縮容這個問題薛窥，所以只要能把V4.0的臟活變成 1. 擴容縮容對前端APP透明(業(yè)務(wù)代碼不需要任何改動) 2.擴容縮容全自動化且對在線服務(wù)無影響 那么他就拿到了作為Saas的門票.
對于架構(gòu)實現(xiàn)的關(guān)鍵點，需要滿足對業(yè)務(wù)透明，擴容縮容對業(yè)務(wù)不需要任何改動诅迷，那么就必須eat our own dog food佩番，在你mysql saas內(nèi)部解決這個問題，一般的做法是我們需要引入一個Proxy,Proxy來解析sql協(xié)議罢杉，按sharding key 來尋找cluster, 判斷是讀操作還是寫操作來請求主 或者 從趟畏，這一切內(nèi)部的細(xì)節(jié)都由proxy來屏蔽。
這里借淘寶的圖來列舉一下proxy需要干哪些事情
百度也有類似的解決方案滩租，見文章最后資料部分鏈接
對于架構(gòu)實現(xiàn)的關(guān)鍵點赋秀，擴容縮容全自動化且對在線服務(wù)無影響； 擴容縮容對應(yīng)到的數(shù)據(jù)操作即為數(shù)據(jù)拆分和數(shù)據(jù)合并律想，要做到完全自動化有非常多不同的實現(xiàn)方式猎莲，總體思路和V4.0介紹的瓶頸部分有關(guān)，這里就不細(xì)展開講 了技即。以擴容為例著洼，擴容后的服務(wù)和擴容前數(shù)據(jù)已經(jīng)基本同步了，這時候如何做到切換對業(yè)務(wù)無影響而叼？ 其實關(guān)鍵點還是在引入的proxy,這個問題轉(zhuǎn)換為了如何讓proxy做熱切換后端的問題身笤。這已經(jīng)變成一個非常好處理的問題了.
另外值得關(guān)注的是：2014年5月28日——為了滿足當(dāng)下對Web及云應(yīng)用需求，甲骨文宣布推出MySQL Fabric葵陵，在對應(yīng)的資料部分我也放了很多Fabric的資料展鸡，有興趣的可以看看，說不定會是以后的一個方向
