第1章 引言

隨著互聯(lián)網(wǎng)應(yīng)用的廣泛普及，海量數(shù)據(jù)的存儲(chǔ)和訪問成為了系統(tǒng)設(shè)計(jì)的瓶頸問題。對(duì)于一個(gè)大型的 互聯(lián)網(wǎng)應(yīng)用，每天幾十億的PV無疑對(duì)數(shù)據(jù)庫造成了相當(dāng)高的負(fù)載。對(duì)于系統(tǒng)的穩(wěn)定性和擴(kuò)展性造成了極大的問題。通過數(shù)據(jù)切分來提高網(wǎng)站性能，橫向擴(kuò)展數(shù)據(jù)層 已經(jīng)成為架構(gòu)研發(fā)人員首選的方式。水平切分?jǐn)?shù)據(jù)庫，可以降低單臺(tái)機(jī)器的負(fù)載，同時(shí)最大限度的降低了了宕機(jī)造成的損失。通過負(fù)載均衡策略，有效的降低了單臺(tái) 機(jī)器的訪問負(fù)載，降低了宕機(jī)的可能性；通過集群方案，解決了數(shù)據(jù)庫宕機(jī)帶來的單點(diǎn)數(shù)據(jù)庫不能訪問的問題；通過讀寫分離策略更是最大限度了提高了應(yīng)用中讀取 （Read）數(shù)據(jù)的速度和并發(fā)量。目前國內(nèi)的大型互聯(lián)網(wǎng)應(yīng)用中，大量的采用了這樣的數(shù)據(jù)切分方案，Taobao,Alibaba,Tencent，它們大 都實(shí)現(xiàn)了自己的分布式數(shù)據(jù)訪問層（DDAL）。以實(shí)現(xiàn)方式和實(shí)現(xiàn)的層次來劃分，大概分為兩個(gè)層次（Java應(yīng)用為例）：JDBC層的封裝，ORM框架層的 實(shí)現(xiàn)。就JDBC層的直接封裝而言，現(xiàn)在國內(nèi)發(fā)展較好的一個(gè)項(xiàng)目是被稱作“變形蟲”(Amoeba)的項(xiàng)目，由阿里集團(tuán)的研究院開發(fā)，現(xiàn)在仍然處于測(cè)試階 段（beta版），其運(yùn)行效率和生產(chǎn)時(shí)效性有待考究。就ORM框架層的實(shí)現(xiàn)而言，比如Taobao的基于ibatis和Spring的的分布式數(shù)據(jù)訪問 層，已有多年的應(yīng)用，運(yùn)行效率和生產(chǎn)實(shí)效性得到了開發(fā)人員和用戶的肯定。本文就是以O(shè)RM框架層為基礎(chǔ)而實(shí)現(xiàn)的分布式數(shù)據(jù)訪問層。本課題的難點(diǎn)在于分庫 后，路由規(guī)則的制定和選擇以及后期的擴(kuò)展性，比如：如何做到用最少的數(shù)據(jù)遷移量，達(dá)到擴(kuò)充數(shù)據(jù)庫容量（增加機(jī)器節(jié)點(diǎn)）的目的。核心問題將圍繞數(shù)據(jù)庫分庫分 表的路由規(guī)則和負(fù)載均衡策略展開。

第2章 基本原理和概念

2.1基本原理：

人類認(rèn)知問題的過程總是這樣的：what（什么）-?why(為什么)-?how(怎么

做)，接下來，本文將就這三個(gè)問題展開討論和研究：

2.1.1什么是數(shù)據(jù)切分

"Shard"這個(gè)詞英文的意思是"碎片"，而作為數(shù)據(jù)庫相關(guān)的技術(shù)用語，似乎最早見于大型多人在線角色扮演游戲中。"Sharding"姑且稱之為"分片"。Sharding 不是一門新技術(shù)，而是一個(gè)相對(duì)簡樸的軟件理念。眾所周知，MySQL 5之后才有了數(shù)據(jù)表分區(qū)功能，那么在此之前，很多 MySQL 的潛在用戶都對(duì) MySQL的擴(kuò)展性有所顧慮，而是否具備分區(qū)功能就成了衡量一個(gè)數(shù)據(jù)庫可擴(kuò)展性與否的一個(gè)關(guān)鍵指標(biāo)(當(dāng)然不是唯一指標(biāo))。數(shù)據(jù)庫擴(kuò)展性是一個(gè)永恒的話題，MySQL的推廣者經(jīng)常會(huì)被問到：如在單一數(shù)據(jù)庫上處理應(yīng)用數(shù)據(jù)捉襟見肘而需要進(jìn)行分區(qū)化之類的處理，是如何辦到的呢? 答案是：Sharding。 Sharding 不是一個(gè)某個(gè)特定數(shù)據(jù)庫軟件附屬的功能，而是在具體技術(shù)細(xì)節(jié)之上的抽象處理，是水平擴(kuò)展(Scale Out，亦或橫向擴(kuò)展、向外擴(kuò)展)的解決方案，其主要目的是為突破單節(jié)點(diǎn)數(shù)據(jù)庫服務(wù)器的 I/O 能力限制，解決數(shù)據(jù)庫擴(kuò)展性問題。

通過一系列的切分規(guī)則將數(shù)據(jù)水平分布到不同的DB或table中，在通過相應(yīng)的DB路由或者table路由規(guī)則找到需要查詢的具體的DB或者table，以進(jìn)行Query操作。這里所說的“sharding”通常是指“水平切分”，這也是本文討 論的重點(diǎn)。具體將有什么樣的切分方式呢和路由方式呢？行文至此，讀者難免有所疑問，接下來舉個(gè)簡單的例子：我們針對(duì)一個(gè)Blog應(yīng)用中的日志來說明， 比如日志文章（article）表有如下字段：

面對(duì)這樣的一個(gè)表，我們?cè)鯓忧蟹帜兀吭鯓訉⑦@樣的數(shù)據(jù)分布到不同的數(shù)據(jù)庫中的表中去呢？其實(shí) 分析blog的應(yīng)用，我們不難得出這樣的結(jié)論：blog的應(yīng)用中，用戶分為兩種：瀏覽者和blog的主人。瀏覽者瀏覽某個(gè)blog，實(shí)際上是在一個(gè)特定的 用戶的blog下進(jìn)行瀏覽的，而blog的主人管理自己的blog，也同樣是在特定的用戶blog下進(jìn)行操作的（在自己的空間下）。所謂的特定的用戶，用 數(shù)據(jù)庫的字段表示就是“user_id”。就是這個(gè)“user_id”，它就是我們需要的分庫的依據(jù)和規(guī)則的基礎(chǔ)。我們可以這樣做，將user_id為1～10000的所有的文章信息放入DB1中的article表中，將user_id為10001～20000的所有文章信息放入DB2中的article表中，以此類推，一直到DBn。這樣一來，文章數(shù)據(jù)就很自然的被分到了各個(gè)數(shù)據(jù)庫中，達(dá)到了數(shù)據(jù)切分的目的。接下來要解決的問題就是怎樣找 到具體的數(shù)據(jù)庫呢？其實(shí)問題也是簡單明顯的，既然分庫的時(shí)候我們用到了區(qū)分字段user_id，那么很自然，數(shù)據(jù)庫路由的過程當(dāng)然還是少不了user_id的。考慮一下我們剛才呈現(xiàn)的blog應(yīng)用，不管是訪問別人的blog還是管理自己的blog，總之我都要知道這個(gè)blog的用戶是誰吧，也 就是我們知道了這個(gè)blog的user_id，就利用這個(gè)user_id，利用分庫時(shí)候的規(guī)則，反過來定位具體的數(shù)據(jù)庫，比如user_id是234，利 用該才的規(guī)則，就應(yīng)該定位到DB1，假如user_id是12343，利用該才的規(guī)則，就應(yīng)該定位到DB2。以此類推，利用分庫的規(guī)則，反向的路由到具體 的DB，這個(gè)過程我們稱之為“DB路由”。

當(dāng)然考慮到數(shù)據(jù)切分的DB設(shè)計(jì)必然是非常規(guī)，不正統(tǒng)的DB設(shè)計(jì)。那么什么樣的DB設(shè)計(jì)是正統(tǒng)的DB設(shè)計(jì)呢？

我們平常規(guī)規(guī)矩矩用的基本都是。平常我們會(huì)自覺的按照范式來設(shè)計(jì)我們的數(shù)據(jù)庫，負(fù)載高點(diǎn)可能 考慮使用相關(guān)的Replication機(jī)制來提高讀寫的吞吐和性能，這可能已經(jīng)可以滿足很多需求，但這套機(jī)制自身的缺陷還是比較顯而易見的（下文會(huì)提 及）。上面提到的“自覺的按照范式設(shè)計(jì)”。考慮到數(shù)據(jù)切分的DB設(shè)計(jì)，將違背這個(gè)通常的規(guī)矩和約束，為了切分，我們不得不在數(shù)據(jù)庫的表中出現(xiàn)冗余字段，用 作區(qū)分字段或者叫做分庫的標(biāo)記字段，比如上面的article的例子中的user_id這樣的字段（當(dāng)然，剛才的例子并沒有很好的體現(xiàn)出user_id的 冗余性，因?yàn)閡ser_id這個(gè)字段即使就是不分庫，也是要出現(xiàn)的，算是我們撿了便宜吧）。當(dāng)然冗余字段的出現(xiàn)并不只是在分庫的場(chǎng)景下才出現(xiàn)的，在很多大 型應(yīng)用中，冗余也是必須的，這個(gè)涉及到高效DB的設(shè)計(jì)，本文不再贅述。

2.1.2為什么要數(shù)據(jù)切分

上面對(duì)什么是數(shù)據(jù)切分做了個(gè)概要的描述和解釋，讀者可能會(huì)疑問，為什么需要數(shù)據(jù)切分呢？像Oracle這樣成熟穩(wěn)定的數(shù)據(jù)庫，足以支撐海量數(shù)據(jù)的存儲(chǔ)與查詢了？為什么還需要數(shù)據(jù)切片呢？的確，Oracle的DB確實(shí)很成熟很穩(wěn)定，但是高昂的使 用費(fèi)用和高端的硬件支撐不是每一個(gè)公司能支付的起的。試想一下一年幾千萬的使用費(fèi)用和動(dòng)輒上千萬元的小型機(jī)作為硬件支撐，這是一般公司能支付的起的嗎？即 使就是能支付的起，假如有更好的方案，有更廉價(jià)且水平擴(kuò)展性能更好的方案，我們?yōu)槭裁床贿x擇呢？

但是，事情總是不盡人意。平常我們會(huì)自覺的按照范式來設(shè)計(jì)我們的數(shù)據(jù)庫，負(fù)載高點(diǎn)可能考慮使 用相關(guān)的Replication機(jī)制來提高讀寫的吞吐和性能，這可能已經(jīng)可以滿足很多需求，但這套機(jī)制自身的缺陷還是比較顯而易見的。首先它的有效很依賴 于讀操作的比例，Master往往會(huì)成為瓶頸所在，寫操作需要順序排隊(duì)來執(zhí)行，過載的話Master首先扛不住，Slaves的數(shù)據(jù)同步的延遲也可能比較 大，而且會(huì)大大耗費(fèi)CPU的計(jì)算能力，因?yàn)閣rite操作在Master上執(zhí)行以后還是需要在每臺(tái)slave機(jī)器上都跑一次。這時(shí)候Sharding可能會(huì)成為雞肋了。Replication搞不定，那么為什么Sharding可以工作呢？道理很簡單，因?yàn)樗梢院芎玫臄U(kuò)展。我們知道每臺(tái)機(jī)器無論配置多么好它都有自身的 物理上限，所以當(dāng)我們應(yīng)用已經(jīng)能觸及或遠(yuǎn)遠(yuǎn)超出單臺(tái)機(jī)器的某個(gè)上限的時(shí)候，我們惟有尋找別的機(jī)器的幫助或者繼續(xù)升級(jí)的我們的硬件，但常見的方案還是橫向擴(kuò) 展,通過添加更多的機(jī)器來共同承擔(dān)壓力。我們還得考慮當(dāng)我們的業(yè)務(wù)邏輯不斷增長，我們的機(jī)器能不能通過線性增長就能滿足需求？Sharding可以輕松的將計(jì) 算，存儲(chǔ)，I/O并行分發(fā)到多臺(tái)機(jī)器上，這樣可以充分利用多臺(tái)機(jī)器各種處理能力，同時(shí)可以避免單點(diǎn)失敗，提供系統(tǒng)的可用性，進(jìn)行很好的錯(cuò)誤隔離。

綜合以上因素，數(shù)據(jù)切分是很有必要的，且我們?cè)诖擞懻摰臄?shù)據(jù)切分也是將MySql作為背景 的。基于成本的考慮，很多公司也選擇了Free且Open的MySql。對(duì)MySql有所了解的開發(fā)人員可能會(huì)知道，MySQL 5之后才有了數(shù)據(jù)表分區(qū)功能，那么在此之前，很多 MySQL 的潛在用戶都對(duì) MySQL的擴(kuò)展性有所顧慮，而是否具備分區(qū)功能就成了衡量一個(gè)數(shù)據(jù)庫可擴(kuò)展性與否的一個(gè)關(guān)鍵指標(biāo)(當(dāng)然不是唯一指標(biāo))。數(shù)據(jù)庫擴(kuò)展性是一個(gè)永恒的話題，MySQL的推廣者經(jīng)常會(huì)被問到：如在單一數(shù)據(jù)庫上處理應(yīng)用數(shù)據(jù)捉襟見肘而需要進(jìn)行分區(qū)化之類的處理，是如何辦到的呢?答案也是Sharding，也就是我們所說的數(shù)據(jù)切分方案。

我們用免費(fèi)的MySQL和廉價(jià)的Server甚至是PC做集群，達(dá)到小型機(jī)+大型商業(yè)DB的效果，減少大量的資金投入，降低運(yùn)營成本，何樂而不為呢？所以，我們選擇Sharding，擁抱Sharding。

2.1.3怎么做到數(shù)據(jù)切分

說到數(shù)據(jù)切分，再次我們講對(duì)數(shù)據(jù)切分的方法和形式進(jìn)行比較詳細(xì)的闡述和說明。

數(shù)據(jù)切分可以是物理上的，對(duì)數(shù)據(jù)通過一系列的切分規(guī)則將數(shù)據(jù)分布到不同的DB服務(wù)器上，通過路由規(guī)則路由訪問特定的數(shù)據(jù)庫，這樣一來每次訪問面對(duì)的就不是單臺(tái)服務(wù)器了，而是N臺(tái)服務(wù)器，這樣就可以降低單臺(tái)機(jī)器的負(fù)載壓力。

數(shù)據(jù)切分也可以是數(shù)據(jù)庫內(nèi)的，對(duì)數(shù)據(jù)通過一系列的切分規(guī)則，將數(shù)據(jù)分布到一個(gè)數(shù)據(jù)庫的不同表 中，比如將article分為article_001,article_002等子表，若干個(gè)子表水平拼合有組成了邏輯上一個(gè)完整的article表，這 樣做的目的其實(shí)也是很簡單的。舉個(gè)例子說明，比如article表中現(xiàn)在有5000w條數(shù)據(jù)，此時(shí)我們需要在這個(gè)表中增加（insert）一條新的數(shù) 據(jù)，insert完畢后，數(shù)據(jù)庫會(huì)針對(duì)這張表重新建立索引，5000w行數(shù)據(jù)建立索引的系統(tǒng)開銷還是不容忽視的。但是反過來，假如我們將這個(gè)表分成100個(gè)table呢，從article_001一直到article_100，5000w行數(shù)據(jù)平均下來，每個(gè)子表里邊就只有50萬行數(shù)據(jù)，這時(shí)候我們向一張 只有50w行數(shù)據(jù)的table中insert數(shù)據(jù)后建立索引的時(shí)間就會(huì)呈數(shù)量級(jí)的下降，極大了提高了DB的運(yùn)行時(shí)效率，提高了DB的并發(fā)量。當(dāng)然分表的好 處還不知這些，還有諸如寫操作的鎖操作等，都會(huì)帶來很多顯然的好處。

綜上，分庫降低了單點(diǎn)機(jī)器的負(fù)載；分表，提高了數(shù)據(jù)操作的效率，尤其是Write操作的效率。行文至此我們依然沒有涉及到如何切分的問題。接下來，我們將對(duì)切分規(guī)則進(jìn)行詳盡的闡述和說明。

上文中提到，要想做到數(shù)據(jù)的水平切分，在每一個(gè)表中都要有相冗余字符作為切分依據(jù)和標(biāo)記字段，通常的應(yīng)用中我們選用user_id作為區(qū)分字段，基于此就有如下三種分庫的方式和規(guī)則：（當(dāng)然還可以有其他的方式）

按號(hào)段分：

(1) user_id為區(qū)分，1～1000的對(duì)應(yīng)DB1，1001～2000的對(duì)應(yīng)DB2，以此類推；

優(yōu)點(diǎn)：可部分遷移

缺點(diǎn)：數(shù)據(jù)分布不均

(2)hash取模分：

對(duì)user_id進(jìn)行hash（或者如果user_id是數(shù)值型的話直接使用user_id的值也可），然后用一個(gè)特定的數(shù)字，比如應(yīng)用中需要將一個(gè)數(shù)據(jù)庫切分成4個(gè)數(shù)據(jù)庫的話，我們就用4這個(gè)數(shù)字對(duì)user_id的hash值進(jìn)行取模運(yùn)算，也 就是user_id%4,這樣的話每次運(yùn)算就有四種可能：結(jié)果為1的時(shí)候?qū)?yīng)DB1；結(jié)果為2的時(shí)候?qū)?yīng)DB2；結(jié)果為3的時(shí)候?qū)?yīng)DB3；結(jié)果為0的時(shí) 候?qū)?yīng)DB4，這樣一來就非常均勻的將數(shù)據(jù)分配到4個(gè)DB中。

優(yōu)點(diǎn)：數(shù)據(jù)分布均勻

缺點(diǎn)：數(shù)據(jù)遷移的時(shí)候麻煩，不能按照機(jī)器性能分?jǐn)倲?shù)據(jù)

(3)在認(rèn)證庫中保存數(shù)據(jù)庫配置

就是建立一個(gè)DB，這個(gè)DB單獨(dú)保存user_id到DB的映射關(guān)系，每次訪問數(shù)據(jù)庫的時(shí)候都要先查詢一次這個(gè)數(shù)據(jù)庫，以得到具體的DB信息，然后才能進(jìn)行我們需要的查詢操作。

優(yōu)點(diǎn)：靈活性強(qiáng)，一對(duì)一關(guān)系

缺點(diǎn)：每次查詢之前都要多一次查詢，性能大打折扣

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com