文正整理自：http://www.csdn.net/article/2014-06-10/2820160

可擴(kuò)展性

架構(gòu)的可擴(kuò)展性往往和并發(fā)是息息相關(guān)，沒(méi)有并發(fā)的增長(zhǎng)，也就沒(méi)有必要做高可擴(kuò)展性的架構(gòu)，這里對(duì)可擴(kuò)展性進(jìn)行簡(jiǎn)單介紹一下，常用的擴(kuò)展手段有以下兩種：

• Scale-up：縱向擴(kuò)展，通過(guò)替換為更好的機(jī)器和資源來(lái)實(shí)現(xiàn)伸縮，提升服務(wù)能力
• Scale-out：橫向擴(kuò)展,? 通過(guò)加節(jié)點(diǎn)（機(jī)器）來(lái)實(shí)現(xiàn)伸縮，提升服務(wù)能力

對(duì)于互聯(lián)網(wǎng)的高并發(fā)應(yīng)用來(lái)說(shuō)，無(wú)疑橫向擴(kuò)展才是出路，同時(shí)通過(guò)縱向購(gòu)買更高端的機(jī)器也一直是我們所避諱的問(wèn)題，也不是長(zhǎng)久之計(jì)。那么，在橫向擴(kuò)展的理論下，可擴(kuò)展性的理想狀態(tài)是什么？

可擴(kuò)展性的理想狀態(tài)

一個(gè)服務(wù)，當(dāng)面臨更高的并發(fā)的時(shí)候，能夠通過(guò)簡(jiǎn)單增加機(jī)器來(lái)提升服務(wù)支撐的并發(fā)度，且增加機(jī)器過(guò)程中對(duì)線上服務(wù)無(wú)影響（no down time），這就是可擴(kuò)展性的理想狀態(tài)！?

架構(gòu)的演變

V1.0? 簡(jiǎn)單網(wǎng)站架構(gòu)

一個(gè)簡(jiǎn)單的小型網(wǎng)站或者應(yīng)用背后的架構(gòu)可以非常簡(jiǎn)單，數(shù)據(jù)存儲(chǔ)只需要一個(gè)Mysql Instance就能滿足數(shù)據(jù)讀取和寫(xiě)入需求（這里忽略掉了數(shù)據(jù)備份的實(shí)例），處于這個(gè)時(shí)間段的網(wǎng)站，一般會(huì)把所有的信息存到一個(gè)Database Instance里面。

在這樣的架構(gòu)下，我們來(lái)看看數(shù)據(jù)存儲(chǔ)的瓶頸是什么？

• 數(shù)據(jù)量的總大小? 一個(gè)機(jī)器放不下
• 數(shù)據(jù)的索引（B+ Tree）一個(gè)機(jī)器的內(nèi)存放不下?
• 訪問(wèn)量（讀寫(xiě)混合）一個(gè)實(shí)例不能承受

只有當(dāng)以上3件事情任何一件或多件滿足時(shí)，我們才需要考慮往下一級(jí)演變。 從此我們可以看出，事實(shí)上對(duì)于很多小公司小應(yīng)用，這種架構(gòu)已經(jīng)足夠滿足他們的需求了，初期數(shù)據(jù)量準(zhǔn)確評(píng)估是杜絕過(guò)度設(shè)計(jì)很重要的一環(huán)，畢竟沒(méi)有人愿意為不可能發(fā)生的事情而浪費(fèi)自己的精力。

這里簡(jiǎn)單舉個(gè)我的例子，對(duì)于用戶信息這類表 （3個(gè)索引），16G內(nèi)存能放下，大概2000萬(wàn)行數(shù)據(jù)的索引，簡(jiǎn)單的讀和寫(xiě)混合訪問(wèn)量3000/s左右沒(méi)有問(wèn)題，你的應(yīng)用場(chǎng)景是否？

V2.0 垂直拆分

一般當(dāng)V1.0 遇到瓶頸時(shí)，首先最簡(jiǎn)便的拆分方法就是垂直拆分，何謂垂直？就是從業(yè)務(wù)角度來(lái)看，將關(guān)聯(lián)性不強(qiáng)的數(shù)據(jù)拆分到不同的Instance上，從而達(dá)到消除瓶頸的目標(biāo)。以圖中的為例，將用戶信息數(shù)據(jù)，和業(yè)務(wù)數(shù)據(jù)拆分到不同的三個(gè)實(shí)例上。對(duì)于重復(fù)讀類型比較多的場(chǎng)景，我們還可以加一層Cache，來(lái)減少對(duì)DB的壓力。

在這樣的架構(gòu)下，我們來(lái)看看數(shù)據(jù)存儲(chǔ)的瓶頸是什么？

單實(shí)例單業(yè)務(wù)依然存在V1.0所述瓶頸：遇到瓶頸時(shí)可以考慮往本文更高V版本升級(jí)，若是讀請(qǐng)求導(dǎo)致達(dá)到性能瓶頸可以考慮往V3.0升級(jí)， 其他瓶頸考慮往V4.0升級(jí)。

V3.0? 主從架構(gòu)

此類架構(gòu)主要解決V2.0架構(gòu)下的讀問(wèn)題，通過(guò)給Instance掛數(shù)據(jù)實(shí)時(shí)備份的思路來(lái)遷移讀取的壓力，在MySQL的場(chǎng)景下就是通過(guò)主從結(jié)構(gòu)，主庫(kù)抗寫(xiě)壓力，通過(guò)從庫(kù)來(lái)分擔(dān)讀壓力，對(duì)于寫(xiě)少讀多的應(yīng)用，V3.0主從架構(gòu)完全能夠勝任。

在這樣的架構(gòu)下，我們來(lái)看看數(shù)據(jù)存儲(chǔ)的瓶頸是什么？很明了，寫(xiě)入量主庫(kù)不能承受。

V4.0? 水平拆分

對(duì)于V2.0、V3.0方案遇到瓶頸時(shí)，都可以通過(guò)水平拆分來(lái)解決，水平拆分和垂直拆分有較大區(qū)別，垂直拆分拆完的結(jié)果，在一個(gè)實(shí)例上是擁有全量數(shù)據(jù)的，而水平拆分之后，任何實(shí)例都只有全量的1/n的數(shù)據(jù)，以下圖UserInfo的拆分為例，將UserInfo拆分為3個(gè)Cluster，每個(gè)Cluster持有總量的1/3數(shù)據(jù)，3個(gè)Cluster數(shù)據(jù)的總和等于一份完整數(shù)據(jù)。

注：這里不再叫單個(gè)實(shí)例 而是叫一個(gè)Cluster 代表包含主從的一個(gè)小MySQL集群。

那么，這樣架構(gòu)中的數(shù)據(jù)該如何路由？

1. Range拆分?

sharding key按連續(xù)區(qū)間段路由，一般用在有嚴(yán)格自增ID需求的場(chǎng)景上，如UserId、UserId Range的小例子，以UserId 3000萬(wàn)為Range進(jìn)行拆分：1號(hào)Cluster的UserId是1-3000萬(wàn)，2號(hào)Cluster? UserId是 3001萬(wàn)-6000萬(wàn)。

2. List拆分

List拆分與Range拆分思路一樣，都是通過(guò)給不同的sharding key來(lái)路由到不同的Cluster，但是具體方法有些不同。List主要用來(lái)做sharding key不是連續(xù)區(qū)間的序列落到一個(gè)Cluster的情況，如以下場(chǎng)景：

假定有20個(gè)音像店，分布在4個(gè)有經(jīng)銷權(quán)的地區(qū)，如下表所示：?

?

?

地區(qū)?	商店ID 號(hào)?
北區(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ù)希望能夠把一個(gè)地區(qū)的所有數(shù)據(jù)組織到一起來(lái)搜索，這種場(chǎng)景List拆分可以輕松搞定

?

3. Hash拆分

通過(guò)對(duì)sharding key 進(jìn)行哈希的方式來(lái)進(jìn)行拆分，常用的哈希方法有除余，字符串哈希等等，除余如按UserId%n的值來(lái)決定數(shù)據(jù)讀寫(xiě)哪個(gè)Cluster，其他哈希類算法這里就不細(xì)展開(kāi)講了。

4. 數(shù)據(jù)拆分后引入的問(wèn)題

數(shù)據(jù)水平拆分引入的問(wèn)題主要是只能通過(guò)sharding key來(lái)讀寫(xiě)操作，例如以UserId為sharding key的切分例子，讀UserId的詳細(xì)信息時(shí)，一定需要先知道UserId，這樣才能推算出在哪個(gè)Cluster進(jìn)而進(jìn)行查詢，假設(shè)我需要按UserName進(jìn)行檢索用戶信息，需要引入額外的反向索引機(jī)制（類似HBase二級(jí)索引），如在Redis上存儲(chǔ)username->userid的映射，以UserName查詢的例子變成了先通過(guò)查詢username->userid，再通過(guò)userid查詢相應(yīng)的信息。

實(shí)際上這個(gè)做法很簡(jiǎn)單，但是我們不要忽略了一個(gè)額外的隱患，那就是數(shù)據(jù)不一致的隱患。存儲(chǔ)在Redis里的username->userid和存儲(chǔ)在MySQL里的userid->username必須需要是一致的，這個(gè)保證起來(lái)很多時(shí)候是一件比較困難的事情，舉個(gè)例子來(lái)說(shuō)，對(duì)于修改用戶名這個(gè)場(chǎng)景，你需要同時(shí)修改Redis和Mysql。這兩個(gè)東西是很難做到事務(wù)保證的，如MySQL操作成功，但是Redis卻操作失敗了（分布式事務(wù)引入成本較高）。對(duì)于互聯(lián)網(wǎng)應(yīng)用來(lái)說(shuō)，可用性是最重要的，一致性是其次，所以能夠容忍小量的不一致出現(xiàn). 畢竟從占比來(lái)說(shuō)，這類的不一致的比例可以微乎其微到忽略不計(jì)。（一般寫(xiě)更新也會(huì)采用mq來(lái)保證直到成功為止才停止重試操作）

在這樣的架構(gòu)下，我們來(lái)看看數(shù)據(jù)存儲(chǔ)的瓶頸是什么？

在這個(gè)拆分理念上搭建起來(lái)的架構(gòu)，理論上不存在瓶頸（sharding key能確保各Cluster流量相對(duì)均衡的前提下)。不過(guò)確有一件惡心的事情，那就是Cluster擴(kuò)容的時(shí)候重做數(shù)據(jù)的成本，如我原來(lái)有3個(gè)Cluster，但是現(xiàn)在我的數(shù)據(jù)增長(zhǎng)比較快，我需要6個(gè)Cluster，那么我們需要將每個(gè)Cluster 一拆為二，一般的做法是：

摘下一個(gè)slave，停同步

對(duì)寫(xiě)記錄增量log（實(shí)現(xiàn)上可以業(yè)務(wù)方對(duì)寫(xiě)操作多一次寫(xiě)持久化mq或者M(jìn)ySQL主創(chuàng)建trigger記錄寫(xiě)等等方式）

開(kāi)始對(duì)靜態(tài)slave做數(shù)據(jù)一拆為二

回放增量寫(xiě)入，直到追上的所有增量，與原Cluster基本保持同步

寫(xiě)入切換，由原3 Cluster 切換為6 Cluster

有沒(méi)有類似飛機(jī)空中加油的感覺(jué)，這是一個(gè)臟活，累活，容易出問(wèn)題的活，為了避免這個(gè)，我們一般在最開(kāi)始的時(shí)候，設(shè)計(jì)足夠多的sharding cluster來(lái)防止可能的Cluster擴(kuò)容這件事情。

V5.0? 云計(jì)算 騰飛（云數(shù)據(jù)庫(kù)）

云計(jì)算現(xiàn)在是各大IT公司內(nèi)部作為節(jié)約成本的一個(gè)突破口，對(duì)于數(shù)據(jù)存儲(chǔ)的MySQL來(lái)說(shuō)，如何讓其成為一個(gè)SaaS是關(guān)鍵點(diǎn)。在MS的官方文檔中，把構(gòu)建一個(gè)足夠成熟的SaaS（MS簡(jiǎn)單列出了SAAS應(yīng)用的4級(jí)成熟度）所面臨的3個(gè)主要挑戰(zhàn)：可配置性，可擴(kuò)展性，多用戶存儲(chǔ)結(jié)構(gòu)設(shè)計(jì)稱為"three headed monster"。可配置性和多用戶存儲(chǔ)結(jié)構(gòu)設(shè)計(jì)在MySQL SaaS這個(gè)問(wèn)題中并不是特別難辦的一件事情，所以這里重點(diǎn)說(shuō)一下可擴(kuò)展性。

MySQL作為一個(gè)SaaS服務(wù)，在架構(gòu)演變?yōu)閂4.0之后，依賴良好的sharding key設(shè)計(jì)，已經(jīng)不再存在擴(kuò)展性問(wèn)題，只是他在面對(duì)擴(kuò)容縮容時(shí)，有一些臟活需要干，而作為SaaS，并不能避免擴(kuò)容縮容這個(gè)問(wèn)題，所以只要能把V4.0的臟活變成：第1，擴(kuò)容縮容對(duì)前端APP透明（業(yè)務(wù)代碼不需要任何改動(dòng)）；第2，擴(kuò)容縮容全自動(dòng)化且對(duì)在線服務(wù)無(wú)影響。如果實(shí)現(xiàn)了這兩點(diǎn)，那么他就拿到了作為SaaS的門票。

對(duì)于架構(gòu)實(shí)現(xiàn)的關(guān)鍵點(diǎn)，需要滿足對(duì)業(yè)務(wù)透明，擴(kuò)容縮容對(duì)業(yè)務(wù)不需要任何改動(dòng)，那么就必須eat our own dog food，在你MySQL SaaS內(nèi)部解決這個(gè)問(wèn)題，一般的做法是我們需要引入一個(gè)Proxy，Proxy來(lái)解析SQL協(xié)議，按sharding key來(lái)尋找Cluster，判斷是讀操作還是寫(xiě)操作來(lái)請(qǐng)求Master或者Slave，這一切內(nèi)部的細(xì)節(jié)都由Proxy來(lái)屏蔽。

對(duì)于架構(gòu)實(shí)現(xiàn)的關(guān)鍵點(diǎn)，擴(kuò)容縮容全自動(dòng)化且對(duì)在線服務(wù)無(wú)影響； 擴(kuò)容縮容對(duì)應(yīng)到的數(shù)據(jù)操作即為數(shù)據(jù)拆分和數(shù)據(jù)合并，要做到完全自動(dòng)化有非常多不同的實(shí)現(xiàn)方式，總體思路和V4.0介紹的瓶頸部分有關(guān)，目前來(lái)看這個(gè)問(wèn)題比較好的方案就是實(shí)現(xiàn)一個(gè)偽裝Slave的Sync Slave，解析MySQL同步協(xié)議，然后實(shí)現(xiàn)數(shù)據(jù)拆分邏輯，把全量數(shù)據(jù)進(jìn)行拆分。具體架構(gòu)見(jiàn)下圖：

其中Sync Slave對(duì)于Original Master來(lái)說(shuō)，和一個(gè)普通的Mysql Slave沒(méi)有任何區(qū)別，也不需要任何額外的區(qū)分對(duì)待。需要擴(kuò)容/縮容時(shí)，掛上一個(gè)Sync slave，開(kāi)始全量同步+增量同步，等待一段時(shí)間追數(shù)據(jù)。以擴(kuò)容為例，若擴(kuò)容后的服務(wù)和擴(kuò)容前數(shù)據(jù)已經(jīng)基本同步了，這時(shí)候如何做到切換對(duì)業(yè)務(wù)無(wú)影響？ 其實(shí)關(guān)鍵點(diǎn)還是在引入的Proxy，這個(gè)問(wèn)題轉(zhuǎn)換為了如何讓Proxy做熱切換后端的問(wèn)題。這已經(jīng)變成一個(gè)非常好處理的問(wèn)題了。

另外值得關(guān)注的是：2014年5月28日——為了滿足當(dāng)下對(duì)Web及云應(yīng)用需求，甲骨文宣布推出MySQL Fabric，在對(duì)應(yīng)的資料部分我也放了很多Fabric的資料，有興趣的可以看看，說(shuō)不定會(huì)是以后的一個(gè)解決云數(shù)據(jù)庫(kù)擴(kuò)容縮容的手段。?

V more ?

等待革命……

淘寶用例?

• 淘寶RDS 云數(shù)據(jù)庫(kù)設(shè)計(jì)：?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?

本文轉(zhuǎn)自 張沖andy 博客園博客，原文鏈接：?http://www.cnblogs.com/andy6/p/5789252.html? ，如需轉(zhuǎn)載請(qǐng)自行聯(lián)系原作者

總結(jié)

以上是生活随笔為你收集整理的mysql 在大型应用中的架构演变的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。