Mysql在大型網(wǎng)站的應用架構(gòu)演變 - 大熊先生|互聯(lián)網(wǎng)后端技術(shù) - 博客園
http://www.cnblogs.com/Creator/p/3776110.html
寫在最前:
本文主要描述在網(wǎng)站的不同的并發(fā)訪問量級下，Mysql架構(gòu)的演變
可擴展性的理想狀態(tài)
一個服務昭娩，當面臨更高的并發(fā)的時候黎比，能夠通過簡單增加機器來提升服務支撐的并發(fā)度，且增加機器過程中對線上服務無影響(no down time)偏窝，這就是可擴展性的理想狀態(tài)钢坦！
這里簡單舉個我的例子兔港，對于用戶信息這類表 （3個索引），16G內(nèi)存能放下大概2000W行數(shù)據(jù)的索引，簡單的讀和寫混合訪問量3000/s左右沒有問題合是，你的應用場景是否
V3.0 主從架構(gòu)
此類架構(gòu)主要解決V2.0架構(gòu)下的讀問題了罪，通過給Instance掛數(shù)據(jù)實時備份的思路來遷移讀取的壓力，在Mysql的場景下就是通過主從結(jié)構(gòu)端仰，主庫抗寫壓力捶惜，通過從庫來分擔讀壓力，對于寫少讀多的應用荔烧，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ū)間段路由，一般用在有嚴格自增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è)務希望能夠把一個地區(qū)的所有數(shù)據(jù)組織到一起來搜索，這種場景List拆分可以輕松搞定
3.Hash拆分
通過對sharding key 進行哈希的方式來進行拆分仿贬，常用的哈希方法有除余,字符串哈希等等纽竣，除余如按userid%n 的值來決定數(shù)據(jù)讀寫哪個cluster，其他哈希類算法這里就不細展開講了茧泪。
在這樣的架構(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è)務方對寫操作 多一次寫持久化mq 或者mysql主創(chuàng)建trigger記錄寫 等等方式）3.開始對靜態(tài)slave做數(shù)據(jù), 一拆為二4.回放增量寫入,直到追上的所有增量,與原cluster基本保持同步5.寫入切換缠借，由原3 cluster 切換為6cluster 有沒有類似飛機空中加油的感覺，這是一個臟活宜猜，累活泼返，容易出問題的活，為了避免這個姨拥，我們一般在最開始的時候绅喉，設計足夠多的sharding cluster來防止可能的cluster擴容這件事情
