最近互聯(lián)網(wǎng)都漲思維了，移動互聯(lián)網(wǎng)更是得瑟地不行，在風(fēng)口上嗷嗷地飄，PE/VC沒事兒就就往那兒蹭，而那物流網(wǎng)的天兒還剛蒙蒙亮，這就是我們這些攻城獅所處的有點兒霧霾的時代。這年頭攻城獅總有不寐的夜，為啥糾結(jié)呢?還不是讓數(shù)據(jù)給鬧的。這里一篇小文只是一盤關(guān)于數(shù)據(jù)的小菜，一款關(guān)于數(shù)據(jù)的管弦譜，怎么演奏，那得看自己，看情況，不解決啥實質(zhì)問題，該鬧還得鬧，該糾結(jié)還得糾結(jié)，誰讓你拱呢。

說倆詞兒

數(shù)據(jù)庫：就叫D吧，就是你可以把東西放D那兒，回頭兒你還可以從D把東西拿出來。跟火車站旁邊那個存包的一回事兒，而且也得要身份證，別忘了哈。

機構(gòu)：提供一個或多個服務(wù)的一組機器，他們協(xié)同完成一大類事。

下面就嘮點正嗑兒，說點行話吧。

問題的產(chǎn)生

任何存儲介質(zhì)，其存儲容量總歸是有限的。因此，隨著業(yè)務(wù)的發(fā)展，甚至突發(fā)的業(yè)務(wù)高峰，水平擴展能力總是不可回避的挑戰(zhàn)。這也必然要求數(shù)據(jù)是分布式存儲的，而解決問題的基本指導(dǎo)思想也必然是分而治之，否則那電費、流量費恐怕就不知道翻多少倍了，要命的是生意沒法做了，這年頭慢的東西就會被淘汰。

數(shù)據(jù)路由概念

在分布式環(huán)境中，對于一個請求而言，總是要決策到哪里去讀/寫，這就是數(shù)據(jù)路由問題，也是一個基本問題。寫操作決定了讀操作，因此寫操作中針對具體的設(shè)計目標如何分而治之就成為了問題的關(guān)鍵。但是反過來說也是正確的，讀的需求決定寫的方式，而且應(yīng)該這樣考慮，因為寫的目的不僅僅是存在那里，更是要考慮讀的過程如何發(fā)揮價值。換句話說，數(shù)據(jù)路由首先要解決寫到哪里和如何寫的問題，但它是為如何讀而準備的。關(guān)于寫的設(shè)計應(yīng)當(dāng)是服從于讀的方式、方法、形式和策略。就像接力賽一樣，你把接力棒放在前面隊友的手里就是寫，他接到了，跑了，就是讀，當(dāng)你遞過去的時候你在想什么?對了，就是應(yīng)該像你此刻那樣想。當(dāng)你在使用、架構(gòu)或自研某種廣義數(shù)據(jù)庫的時候，你首先考慮接棒了嗎?當(dāng)然這個問題涉及面更廣，這里僅僅侃侃“到哪里”的問題-雅名“數(shù)據(jù)路由”。老是做海底撈，憋不?別淹著，當(dāng)是潛伏哈。

問題的內(nèi)在特質(zhì)與歸結(jié)

設(shè)：

l 請求=R

l 服務(wù)=S，可以是一個服務(wù)實例，也可能是一個服務(wù)集群

顯然問題可以歸結(jié)為集合R到集合S的映射，數(shù)學(xué)上就是一個函數(shù)，f(R)=S。

要求對于任何特定的請求Rx，必須總是映射到特定的Sx，不論它們的元素如何變化，這就是問題的內(nèi)在特質(zhì)。你不能說，我存了個包在XX，到時候你讓我到Y(jié)Y去取，取完了那警察來了你替我哈。

挑戰(zhàn)

假定我們已經(jīng)實現(xiàn)了一種規(guī)則可以完成R到特定S的映射，該規(guī)則就是數(shù)據(jù)路由要實現(xiàn)的，但是隨著業(yè)務(wù)的發(fā)展，S必然會變大，這時候挑戰(zhàn)就來了，怎樣的規(guī)則才能動態(tài)地適應(yīng)這種改變呢?這就是挑戰(zhàn)所在。

數(shù)據(jù)在存儲上有時會有一個要求，那就是要力求數(shù)據(jù)的均衡分布而不是Skew，這就意味著特定的S存儲的數(shù)據(jù)需要再分配，這也內(nèi)在地要求數(shù)據(jù)路由具備及時調(diào)整映射的能力。聽著有點高大上，簡單類比，可以這么說，想象一個二維坐標系，X軸是數(shù)據(jù)系統(tǒng)的所有硬盤，Y軸是各自保存的數(shù)據(jù)量，畫一個曲線，如果它看上去像個心電圖，那是有病啊，應(yīng)該相對平直才好(跟現(xiàn)實相反哈)。你做架構(gòu)的時候，在這點上，那就是要把它整地“沒有生命體征”，一條線倍兒值，你厲害。拿HADOOP來說，要是BLOCK都集中在某些服務(wù)器上，其它都基本閑著，那就像一個人五官都糾結(jié)在一起，跟包子一樣，美不?答案正確，軟件設(shè)計的美與現(xiàn)實世界的美學(xué)它就那么任性地統(tǒng)一著。要不然，那結(jié)果就是小沈陽穿那蘇格蘭格裙的Style，跑偏了。

路由方式

通常路由都是通過制定一個這里統(tǒng)稱為Key的東西來指路，不同的產(chǎn)品叫法不同，如Key, Rowkey, Field等等。無所謂，皮兒不同，餡兒是一樣的。按照拱城獅看世界的極簡風(fēng)格來看，這個世界就是兩根手指頭就能表達，串和數(shù)，剩下的都是關(guān)系。這個Key，別管他穿啥馬甲，里子就這兩樣。

完全映射

映射執(zhí)行機構(gòu)，即數(shù)據(jù)路由機構(gòu)，包含R和S的所有元素，構(gòu)成全映射。缺點在于需要更大的內(nèi)存來提供高速的路由服務(wù)。并且要求快速地從大量的元素中找到特定元素。這就像你有點事到學(xué)校班里接你家少爺(假定你不知道在哪個班)，到學(xué)校了，人家給你一摞花名冊，你就一個名字一個名字地看，要是像字典一樣排序了還好，但你也得掃一遍。這個比擬的要點在于，所有的名字都在花名冊上，然后由一個具體的名字找到班級-119，最后人家告訴你119班在哪兒，看到?jīng)]，“到哪里”，路由就是給你指路的警察美女，人家那服務(wù)最后就是一句話，給你指路，別沒話找話哈。

范圍映射

R經(jīng)過某種換算得找到一個可落座的范圍，再從范圍映射到S。優(yōu)點在于數(shù)據(jù)路由機構(gòu)可以大大節(jié)約存儲，但要求快速的換算。HBase算是這樣的一個例子，它通過把按字典順序排序的rowkey為標識的行數(shù)據(jù)用基于3級B-Tree的LSM Tree組織起來來實現(xiàn)行的快速定位，找到Region就是范圍的映射。MongoDB也有對這種方式的支持。你要是靠把治療帕金森的藥推銷到兒童醫(yī)院問鼎年度銷售冠軍，那你絕對是一罐愛膚樂油，讓人醉了，顯然范圍沒有overlap。

哈希

該方式力求數(shù)據(jù)的均勻分布，性質(zhì)上基本就是隨機撒，對于大塊讀取連續(xù)的或一個范圍的數(shù)據(jù)是不利的。MongoDB支持根據(jù)哈希值來分散數(shù)據(jù)。

知道北京火車站吧，如果把人映射到進站口，那就是這種方式，一個人從那個口進，沒什么約定。至于在軟件的世界里，中間怎么哈希的，那方式多了去了。如果人都擁擠到特定的口，那就是北京站的管理層哈希砸了，它肯定會想法兒把它弄勻乎了。如果你一個公司的一群人真被哈了，比如說，你規(guī)定每個人的身份證號的尾數(shù)對應(yīng)著進站口號，那就得化整為零進去，進去后想再化零為整，那就得再做些功，所以也有缺點，如果你是具有獨特健身pattern的導(dǎo)游。

不可變S的映射

最常見的就是hash-mod方式，最大的缺點在于不具備擴容能力。優(yōu)點在于路由過程資源占用很小?，F(xiàn)實中也有存在，比如說，但凡說集群的shard/partition等數(shù)值不可變的情況都屬于此類。ElasticSearch大體上就是屬于這種情況，對于一個Index，一旦建立了，就不能改變其shard數(shù)量?？蓪嵅俚臄U容方法就是建立更多的Index，但這要求在Index之上建立更上一層的路由。交警美女上面還有個交警大叔呢，你得先約他，記著哈，別急。

其實沒有什么最好的方案，一切都取決于需求的定位或設(shè)計目標是什么，簡而言之，結(jié)果導(dǎo)向的。比如說，重寫輕讀和重讀輕寫在整體設(shè)計上就會意味著不同的指導(dǎo)意義。側(cè)重順序讀還是隨機讀也會影響整體設(shè)計，當(dāng)然適用的場景也就有分別了。說俗點，那你得為接棒的服務(wù)，遞的時候就得想著接。

時間是個人們杜撰的偉大概念，基本上信息系統(tǒng)都離不開，而且讀的時候基本上都跟它有關(guān)，還而且，經(jīng)常關(guān)注的就是最近一段時間的東西，別說你就愛吃蔫兒菜啊。但是磚家說了，如果你給這樣一個系統(tǒng)做個心電圖，那圖的節(jié)奏看著可能就跟著雷劈了差不多。這只是一個時間維度。

人，他貪啊，其實現(xiàn)實世界的需求是，點、線、面、體甚至更高維度的信息可能同時都需要。這里以時間線為例，提一丟丟拙案，那些造NoSQL或者別的什么東西的大牛們，對于那些人家認為新鮮的，能不能把那個叫Replica的隨便設(shè)個想要的數(shù)量，甚至于智能地自主決策，別一刀切行不，這樣起碼并發(fā)壓力圖看著不雷劈了。對，最新的大片兒你得多備幾份，看的人多嗎，當(dāng)口的生意你不做，年終了你想讓人家抽富士蘋果啊，我看中。

實時監(jiān)測

在整個數(shù)據(jù)服務(wù)體系中，對CPU、內(nèi)存和磁盤空間的監(jiān)測是必要的，至少它可以提醒人工擴容的必要性，以及壓力或數(shù)據(jù)量的不均衡性，以便采取應(yīng)對措施。廣義講，任何分布式系統(tǒng)，如果沒有一個中樞神經(jīng)系統(tǒng)，比如說NameNode,HMaster和Mongos等(在這一點上，目前他們做的可能還不是特別好)，掌握著各個節(jié)點與讀寫路由決策相關(guān)的關(guān)鍵指標，那就只能無理決策了，閉著眼睛拍腦門，“反正我沒看見，都在那了，自己看”。畢竟每個節(jié)點時刻在發(fā)生著變化，刻舟求劍必然淹死在紅海里，只有動態(tài)閉環(huán)反饋才能保持均衡。一碗水端平，難，你造吧。

浮云下的展望-智能擴展

近兩年，云計算甚囂塵上，也漲翅膀了，會飛了。如果你的數(shù)據(jù)系統(tǒng)存在一個全面的健康監(jiān)測機構(gòu)，使得通過一些規(guī)則設(shè)定實現(xiàn)全自動的擴展成為可能，那就有點智能了。例如在一定條件下，通過Python調(diào)用OpenStack API完成虛機和數(shù)據(jù)庫等的安裝、配置、優(yōu)化及初始化。這可能是當(dāng)下云服務(wù)商努力的方向之一。記著，如果你的產(chǎn)品設(shè)計能讓人變懶，那就對路了，信不，你孫子肯定比你懶。從呱呱墜地開始一直到一縷青煙，人的一切的事，就是通過一個click，一個手勢，一句話，一個眼神甚至一個念頭，立馬變成現(xiàn)實，風(fēng)就是往這兒吹地。要不你到盤古大廈樓頂吹吹風(fēng)，來個真實體驗。

結(jié)束語

在當(dāng)今數(shù)據(jù)量Big bang的時代，如果您有幸致力于自主研發(fā)或使用數(shù)據(jù)處理系統(tǒng)，希望這碟小菜您還覺得有一丟丟嚼頭，浪費你視覺神經(jīng)細胞了，我可沒@U奧。