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

說倆詞兒

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

機構：提供一個或多個服務的一組機器，他們協同完成一大類事。

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

問題的產生

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

數據路由概念

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

問題的內在特質與歸結

設：

l 請求=R

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

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

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

挑戰

假定我們已經實現了一種規則可以完成R到特定S的映射，該規則就是數據路由要實現的，但是隨著業務的發展，S必然會變大，這時候挑戰就來了，怎樣的規則才能動態地適應這種改變呢?這就是挑戰所在。

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

路由方式

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

完全映射

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

范圍映射

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

哈希

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

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

不可變S的映射

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

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

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

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

實時監測

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

浮云下的展望-智能擴展

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

結束語

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