www.tmsmall666.cn

 　　博客的名氣現(xiàn)在雖然慢慢下降，但是對于站長們來說依然是一個好的獲取知識和交流的平臺。隨著每月頁面瀏覽量突破150億次，Tumblr已經(jīng)名正言順地躋身博客類平臺中的名人堂。用戶們對它的簡潔、美觀以及對使用體驗的專注追求贊不絕口;它的相關社區(qū)也同樣氛圍溫馨、人氣爆棚?？傊?，人們喜歡這位博客家族中的新貴。

　　超過30%的月度增長不可能一帆風順，過程中的坎坷與挑戰(zhàn)也自然不言而喻，但最令人頭痛的還是可靠性問題。正是經(jīng)過技術(shù)人員的不懈努力，Tumblr才取得了如此驚人的規(guī)模及傲人的運行成績：每天5億次頁面瀏覽、每秒四萬次查詢請求峰值、每天新數(shù)據(jù)存儲量高達約3TB、總支持服務器達到1000余臺。

　　大多數(shù)成功的新興企業(yè)都面臨著相似的困擾，由于從初來乍到的新成員一躍成為萬眾矚目的焦點角色，一道巨大的危險鴻溝硬生生將原本孱弱的技術(shù)支持團隊推向了風口浪尖。招聘員工、擴大基礎設施、維護舊有基礎設施的同時，仍然只有寥寥數(shù)位工程師負責著每個月巨大的數(shù)據(jù)吞吐量。這樣的工作強度意味著筆者們在處理過程中必須有所側(cè)重，而做出這樣的選擇無疑相當艱難。Tumblr目前也陷入了這樣的困境，他們的做法是創(chuàng)建起一個由二十位精力充沛的工程師組成的技術(shù)小組，在應對日常事務的同時制訂出多種極富創(chuàng)意的解決方案。

　　Tumblr創(chuàng)立之初就將自己定位為典型的大型LAMP(即由定制組件構(gòu)成的系統(tǒng))應用程序。如今他們前進的方向是通過Scala、HBase、Redis、Kafka、Finagle以及以架構(gòu)為基礎的新穎單元共同打造出多種分布式服務模塊，借以構(gòu)成完整的Dashboard導航內(nèi)容。目前他們已經(jīng)開始嘗試修復PHP應用程序中的短期問題、將故障部分抽離出來并利用服務機制進行更正。

　　Tumblr發(fā)展的主題是在龐大的平臺規(guī)模之上實施成功轉(zhuǎn)型。即將LAMP堆棧轉(zhuǎn)變?yōu)橐惶赘咄黄菩蕴匦缘男露褩?，同時將原本適用于新興企業(yè)的小型團隊擴展為裝備精良、擅長開發(fā)工作的成熟團隊，進而為用戶帶來大量新功能及基礎設施。為了幫助筆者們更透徹地理解Tumblr實現(xiàn)這一方針的具體做法，Tumblr公司分布式系統(tǒng)工程師Blake Matheny分享了他的心得體會。以下是Blake對Tumblr做出的信息匯總：

　　Tumblr官方網(wǎng)址：http://www.tumblr.com/

　　統(tǒng)計

　　每天5億次頁面瀏覽量

　　每月150億次以上頁面瀏覽量

　　約20位技術(shù)工程師

　　每秒4萬次查詢請求峰值

　　Hadoop集群每天接受超過1TB的數(shù)據(jù)量

　　MySQL/HBase/Redis/Memcache等系統(tǒng)每天需要處理數(shù)以TB計的信息

　　每月用戶數(shù)量及處理負載增長30%

　　日常運行中涉及約1000個硬件節(jié)點

　　每個月每位工程師平均要面對上億次頁面訪問活動

　　每天新增的博文及帖子約為50GB。新的用戶關注列表每天帶來約2.7TB的數(shù)據(jù)存儲量

　　Dashboard系統(tǒng)每秒要應對百萬次寫入操作、5萬次讀取操作，這一數(shù)字還在不斷增長之中

　　軟件

　　開發(fā)工作在OS X上進行，日常運行則交給Linux系統(tǒng)(CentOS、Scientific)

　　Apache

　　PHP, Scala, Ruby

　　Redis, HBase, MySQL

　　Varnish, HA-Proxy, nginx,

　　Memcache, Gearman, Kafka, Kestrel, Finagle

　　Thrift, HTTP

　　Func - 一款安全且腳本化良好的遠程控制框架及API

　　Git, Capistrano, Puppet, Jenkins

　　硬件

　　500 臺web服務器

　　200臺數(shù)據(jù)庫服務器(其中大多數(shù)作為故障發(fā)生時的后備資源存在)

　　47個資源池

　　30個區(qū)塊

　　30臺緩存服務器

　　22 臺redis服務器

　　15 臺varnish服務器

　　25個haproxy節(jié)點

　　8 個nginx反向代理服務器

　　14臺作業(yè)隊列服務器(kestrel+gearman)

　　架構(gòu)

　　比起其它社交型網(wǎng)絡，Tumblr擁有一套完全不同的使用模式。

　　每天有五千多萬篇博文發(fā)表，每一篇都有數(shù)百次的平均瀏覽量。并不是說少數(shù)熱門用戶具備的數(shù)百萬關注者拉升了平均瀏覽量，事實上每位Tumblr用戶基本都有成百上千的關注者。這與以往任何類型的社交網(wǎng)絡都有所不同，也恰恰是這種特性讓Tumblr面臨著史無前例的規(guī)?；简灐?/p>

　　Tumblr目前是用戶傾注時間第二多的熱門社交網(wǎng)絡，其內(nèi)容也極具吸引力。由于允許用戶自由分享圖片與視頻，因此博文的體積不再以字節(jié)計算。盡管用戶不一定總會發(fā)布體積龐大的內(nèi)容，但網(wǎng)站保證每個人都在需要時具備豐富自己文章的能力。人們樂于撰寫更為深刻的主題，這也讓關注者們找到了閱讀的樂趣，并持續(xù)花費大量時間訪問Tumblr。

　　用戶之間構(gòu)成一套完整的聯(lián)絡紐帶，因此他們常常會嘗試回溯Dashboard中數(shù)百頁之前的內(nèi)容。其它社交網(wǎng)絡則往往只提供信息流，用戶體驗只停留在驚鴻一瞥的層面上。

　　也就是說，由于用戶數(shù)量之大、每位用戶的平均閱讀數(shù)量之多以及用戶發(fā)起各類活動積極性之高，Tumblr需要處理的上傳信息龐大到令人驚愕。

　　Tumblr運行于一套托管站點中。設計者們?yōu)榫W(wǎng)站留出了充分的地理分布空間，以應對未來的發(fā)展需求。

　　Tumblr平臺由兩大組件構(gòu)成：Public Tumblelog與Dashboard系統(tǒng)。

　　Public Tumblelog 是一款面向公眾的博客。由于動態(tài)特性較弱，因此緩存更易于打理。

　　Dashboard在功能上與Twitter的timeline頗為相近。用戶將實時接收到自己關注對象的更新信息。

　　在規(guī)模特性上與其它博客載體頗為不同。緩存在這里的作用不再明顯，因為每條請求都各不相同，尤其是對于那些活躍的關注者而言。

　　運行中必須保持高度的實時性與一致性，不應顯示陳舊數(shù)據(jù)，且需要處理的數(shù)據(jù)量非常龐大。每天的博文內(nèi)容本身只有50GB，但關注者列表更新信息則高達2.7TB。媒體文件全部存儲于內(nèi)存中。

　　大多數(shù)用戶將Tumblr作為內(nèi)容型消費工具。每天頁面瀏覽量超過5億次，70%的瀏覽行為針對Dashboard系統(tǒng)。

　　Dashboard系統(tǒng)的可用性相當值得稱道。Tumblelog則一直有所欠缺，因為其中的某套原有基礎設施目前很難實施遷移。鑒于技術(shù)支持團隊的規(guī)模太小，他們不得不在規(guī)?；M程中優(yōu)先處理那些時間短、見效快的內(nèi)容。

　　過去的Tumblr

　　Tumblr起初立足于Rackspace公司，后者為每個自定義域名博客創(chuàng)建一套A記錄。到了2007年，他們已經(jīng)擁有極為龐大的用戶群體，為了實施整體遷移，他們開始嘗試獨立于Rackspace公司之外。這時他們的自定義域業(yè)務仍然由Rackspace負責，為了保持用戶的訪問方式，他們利用HAProxy與Varnish代理服務器將Rackspace域名轉(zhuǎn)向自己的服務器空間。類似的歷史遺留問題還有很多。

　　一套傳統(tǒng)的LAMP。

　　一直使用PHP，幾乎每位工程師都通過PHP處理編程工作。

　　創(chuàng)立之初只擁有一臺web服務器、一臺數(shù)據(jù)庫服務器以及一套PHP應用程序。

　　為了完成規(guī)?；瘮U展，他們開始使用memcache，接著引入前端緩存，然后是將HAProxy置于緩存之前，最后采用MySQL分區(qū)。MySQL分區(qū)體系的加入使整體服務效果邁上新的臺階。

　　力圖將所有處理負載控制在一臺服務器的承受能力之內(nèi)。在過去的一年中，他們借助C語言開發(fā)出兩款后端服務：ID生成器與Staircar，Dashboard通知功能則利用Redis實現(xiàn)。

　　Dashboard采用分散-集中式處理方案，當用戶訪問Dashboard時事件將自動予以顯示。而讓用戶關注對象的新事件以推送形式顯示又花了技術(shù)團隊六個月的時間。由于數(shù)據(jù)以時間為標準排序，因此分區(qū)設計方案的表現(xiàn)并不盡如人意。

　　如今的Tumblr

　　出于提高租用及開發(fā)速度的考量，如今采用JVM中央方案。

　　目標是將所有存在于PHP應用中的內(nèi)容遷移至服務項目中，并將PHP應用本身作為新建的層置于服務之上，用于負責請求驗證及介紹說明等工作。

　　選擇使用Scala與Finagle。

　　公司內(nèi)部擁有大量擅長Ruby及PHP開發(fā)工作的成員，因此Scala的推廣也就更為輕松。

　　Finagle的使用也是他們選擇Scala的重要原因之一。這是一套來自Twitter的庫，能夠處理大多數(shù)由分布式設施帶來的技術(shù)難題，包括分布式跟蹤、服務項目搜索以及服務項目注冊等。當然這些功能筆者們也不必全部采用，根據(jù)實際需求選擇即可，反正都是免費的。

　　一旦與JVM環(huán)境相結(jié)合，F(xiàn)inagle能夠提供他們所需要的一切基本要素(例如Thrift、ZooKeeper等等)。

　　Foursquare及Twitter一直在使用Finagle，Scala也始終效力于Meetup網(wǎng)站。

　　與Thrift應用程序接口一樣，F(xiàn)inagle也帶來了相當優(yōu)異的性能表現(xiàn)。

　　希望得到像Netty那樣的運行效果，又不想涉及Java，因此Scala是最好的選擇。

　　采用Finagle是因為它功能強勁、所需知識并不冷門，使用中不涉及過多網(wǎng)絡代碼而且能為分布式系統(tǒng)提供一切所需功能。

　　Node.js沒有入選的原因在于，它在JVM環(huán)境下對于技術(shù)團隊的規(guī)模要求比較高。Node.js在開發(fā)方面缺乏標準化及最佳實踐選項，測試用代碼也相對較少。而Scala允許筆者們使用任何現(xiàn)有Java代碼。而且在不要求過多知識儲備的基礎上，Scala能夠輕松應對未來可能出現(xiàn)的擴展性要求，同時保障5毫秒響應時間、49秒雙機集群切換以及平均每秒四萬次、峰值四十萬次的請求處理。同時Java體系中的大量資源也可為筆者們所用。

　　內(nèi)部服務項目正由以C語言/libevent函式庫為基礎向Scala/Finagle為基礎轉(zhuǎn)變。

　　采用更新的HBase以及Redis等非關系類數(shù)據(jù)存儲機制，但目前大多數(shù)數(shù)據(jù)存儲在一套高度分區(qū)下的MySQL架構(gòu)中。尚沒有用HBase徹底替代MySQL。

　　HBase憑借數(shù)以億計的URL以及全部歷史數(shù)據(jù)與分析結(jié)果支持自身的URL簡寫功能，運行表現(xiàn)一直穩(wěn)固可靠。HBase主要用于處理高寫入請求情況，例如每秒上百萬次寫入動作的Dashboard重置操作。HBase沒有被用來替代MySQL的原因在于，Tumblr目前的技術(shù)支持團隊尚無法在HBase上完成全部業(yè)務需求，因此他們最終決定先在規(guī)模較小的非關鍵性項目上進行試用，盡量積累使用經(jīng)驗。

　　以MySQL及分區(qū)機制為基礎，將按時間排序的所有數(shù)據(jù)納入同一個分區(qū)的過程始終麻煩不斷。讀取及復制操作也由于子集群寫入動作的同時發(fā)生而常常出現(xiàn)滯后現(xiàn)象。

　　創(chuàng)建出一套通用型服務框架。

　　事先花費大量時間制訂方案，用以解決分布式系統(tǒng)在管理時出現(xiàn)的操作問題。

　　創(chuàng)建一套用于服務項目的Rails橋架，作為引導內(nèi)部服務的模板使用。

　　所有服務項目從運行的角度來看都完全一致。各服務的狀態(tài)檢查、監(jiān)控、啟用以及中止都以同樣的方式進行。

　　創(chuàng)建過程中使用的工具為SBT(一款Scala創(chuàng)建工具)，同時用到的還有其它一些插件及輔助內(nèi)容，旨在為包括git項目標注、倉庫信息發(fā)布等公共活動提供支持。大多數(shù)開發(fā)人員不必深入了解系統(tǒng)的創(chuàng)建過程。

　　前端層使用HAProxy，Varnish則服務于公共博客，二者共計占用40臺設備。

　　Apache及各類PHP應用程序由500臺網(wǎng)絡服務器予以支持。

　　數(shù)據(jù)庫服務器共有200臺。大部分數(shù)據(jù)庫服務器用于提高整體可用性。由于使用標準化硬件配置，因此平均無故障工作時間相當令人滿意。硬件設備的損耗大大超出預期，因此技術(shù)人員準備了大量后備物資以應對不時之需。

　　六項用于支持PHP應用程序的后端服務。一個專項小組專門負責開發(fā)此類后端服務。每隔兩到三周都會有一款新服務推出，例如Dashboard通知、Dashboard輔助索引、URL簡寫工具以及用于分區(qū)處理的緩存代理器等。

　　在MySQL分區(qū)方面投入大量時間以及人力物力。盡管MongoDB目前在紐約(Tumblr的總部所在地)風靡一時，但他們?nèi)匀徊捎昧藬U展性更好的MySQL。

　　Gearman，一款作業(yè)隊列系統(tǒng)，被用于處理運行時間較長且無人照看的工作內(nèi)容。

　　可用性評估以實際使用效果為標準。用戶能夠正常訪問自定義域名或是Dashboard嗎?另外故障率也是評估中的一項因素。

　　就長期運行狀況來看，具備最高優(yōu)先級的項目必須首先得到修復。目前故障模式已經(jīng)得到有效的分析與系統(tǒng)性解決，其目的是同時從用戶及應用程序的角度來評估整體運行狀態(tài)。如果一條請求中的某部分沒有得到充分響應，那么這套評估機制必須迅速查明原因。

　　最初的角色模式是由Finagle負責支持的，但后來這種方式被棄之不用，取而代之的是一套無需照看的作業(yè)隊列。另外，Twitter的實用庫中包含一套名為Futures的服務實施方案。當某個線程池需要被調(diào)用時，F(xiàn)utures服務將立即建立一個future池，這時所有待處理內(nèi)容都將被提交至future池中以進行異步執(zhí)行。

　　由于自身特性的原因，Scala并不適合處理共享狀態(tài)。Finagle則可以默認為適合處理此類情況，因為Twitter已經(jīng)將付諸實際應用。在Scala及Finagle中都應盡量避免可變狀態(tài)調(diào)用架構(gòu)的情況。不能讓設備長期處于運行狀態(tài)。狀態(tài)信息采集自數(shù)據(jù)庫，并在使用后重新寫入數(shù)據(jù)庫。這么做的優(yōu)勢是，開發(fā)人員們不必擔心線程或者鎖定問題。

　　22臺Redis服務器。每臺服務器運行8到32個實例，也就是說共計有數(shù)百個Redis實例用于生產(chǎn)流程。

　　后端存儲機制用于為Dashboard通知功能提供支持。

　　通知功能本身類似于關注筆者們博文的某位用戶。通知會顯示在用戶的Dashboard中，這樣筆者們就能及時了解其它用戶的最新動態(tài)。

　　極高的寫入頻率使得MySQL有些力不從心。

　　通知內(nèi)容無需長期存在，因此即使用戶掉線也不會出現(xiàn)突然涌入大量提示消息的窘境，這樣一來Redis就成為實現(xiàn)通知功能的選擇之一。

　　盡量為技術(shù)人員創(chuàng)造機會，讓他們學習Redis的相關知識并熟悉其工作原理。

　　由于Redis擁有強大的社區(qū)體系，因此無論遇上什么問題都能在這里找到解決方法。

　　為Redis創(chuàng)建一個以Scala futures為基礎的接口，這項功能現(xiàn)在正逐漸轉(zhuǎn)到Cell架構(gòu)當中。

　　URL簡寫工具將Redis作為一級緩存，并把HBase當成長效存儲機制。

　　Dashboard的輔助索引圍繞Redis進行創(chuàng)建。

　　Redis作為Gearman的持久化層存在，并用到了由Finagle創(chuàng)建的緩存代理器。

　　慢慢由緩存向Redis遷移。希望能夠以一套快取服務作為最終方案，其性能表現(xiàn)應與緩存方案一致。

　　內(nèi)部傳輸線

　　內(nèi)部應用程序需要訪問活動流。每個活動流的內(nèi)容都與用戶行為相關，例如創(chuàng)建、刪除博文或者喜歡、反感某些博文等。挑戰(zhàn)在于如何將這樣規(guī)模的數(shù)據(jù)實時加以分散。要達到這一目的，需要足以支持大規(guī)模內(nèi)部擴展的工具以及擁有可靠生態(tài)系統(tǒng)輔助的應用程序。此外還要確立分布式系統(tǒng)的中心點。

　　之前信息的分布化由Scribe/Hadoop負責。服務項目要首先登入Scribe并開始追蹤，然后將數(shù)據(jù)傳輸至應用程序端。這種模式讓可擴展性成為空談，尤其是在用戶每秒創(chuàng)建上千篇博文的峰值時段。應該盡量避免用戶追蹤文件并進行打印。

　　創(chuàng)建一套類似于信息公交車這樣的內(nèi)部傳輸線，服務項目與應用程序通過Thrift與傳輸線進行交互。

　　利用來自LinkedIn網(wǎng)站的Kafka來存儲消息。內(nèi)部用戶使用HTTP流直接從傳輸線上閱讀內(nèi)容。不使用MySQL的原因在于，分區(qū)工作本身就過于頻繁，因此不適合讓其承擔大量數(shù)據(jù)流。

　　Tumblr的傳輸線模式靈活性極強，Twitter所使用的傳輸線則相形見絀，其中的數(shù)據(jù)常常面臨丟失。

　　傳輸線流能夠及時進行回溯，它會保存一周以內(nèi)的所有數(shù)據(jù)。在連接時，它可以正確找回最后一次閱讀的位置。

　　允許同時連入多個客戶端，而且每個客戶端所看到的內(nèi)容都各不相同。每個客戶端擁有獨立的客戶端ID，這要歸功于Kafka所支持的用戶組概念。用戶組中的每一個用戶不僅會看到與自己相關的消息，并且消息內(nèi)容絕不重復?？梢岳猛粋€用戶ID創(chuàng)建多個客戶端，這些客戶端所看到的內(nèi)容同樣不會重復。也就是說數(shù)據(jù)以獨立且并行的方式進行處理。Kafka通過ZooKeeper定期為用戶設置檢查點，以記錄用戶的當前閱讀進度。

　　Dashboard收件箱的Cell設計

　　目前為Dashboard功能提供支持的分散-集中模式存在著一定局限性，不久之后就會轉(zhuǎn)而采用更先進的方案。

　　解決方案是讓收件箱采用以Cell為基礎的新型架構(gòu)，這與Facebook的Messages功能頗為相似。

　　收件箱可以說是分散-集中模式的對立面。由關注者的博文及近期動態(tài)所構(gòu)成的Dashboard版面，按時間順序及邏輯方式存儲在一起。

　　由于收件箱的功能特性，分散-集中模式帶來的問題在這里不攻自破。筆者們只會詢問收件箱中保存著哪些內(nèi)容，這完全不涉及關注者、用戶好友之類亂七八糟的關系。這樣的情況將持續(xù)很長一段時間。

　　對Dashboard內(nèi)容進行重寫是相當困難的。雖然數(shù)據(jù)擁有分布式特性，但它同時也擁有交互式特性，因此用戶無法實現(xiàn)局部更新功能。

　　數(shù)據(jù)總量之大簡直超乎想象。每一條消息平均要發(fā)送給成百上千位不同用戶，這比Facebook的工作負擔更重。大量數(shù)據(jù)加上高分布率再加上多個數(shù)據(jù)中心協(xié)同運作，整個流程的復雜程度由此可見一斑。

　　每秒百萬次寫入操作及五萬次讀取操作，這么高強度的交互活動帶來了高達2.7TB的數(shù)據(jù)集增長量，還不算復制或是壓縮等處理工作。由24個字節(jié)構(gòu)成的百萬次寫入操作給收件箱帶來海量信息。

　　以上所有工作由一套應用程序負責，因此保證程序的正常運作就顯得至關重要。

　　Cell單元。

　　每個Cell單元都是一套獨立的裝置，其中包含了大量用戶的全部相關數(shù)據(jù)。用戶Dashboard版面所需要的一切數(shù)據(jù)都由Cell單元提供。

　　用戶以映射的方式與Cell單元連通，每個數(shù)據(jù)中心都運行著大量Cell單元。

　　每個Cell單元都擁有自己的一套HBase集群、服務集群以及Redis緩存集群。

　　用戶與Cell單元相對應，所有Cell單元都通過傳輸線中的上傳數(shù)據(jù)調(diào)用博客信息。

　　每個Cell單元都以Finagle為基礎，并通過傳輸線以及Thrift上的服務請求構(gòu)成HBase數(shù)據(jù)信息。

　　當某位用戶進入Dashboard版面，就會從特定Cell單元中調(diào)出多個相關用戶的信息;服務器節(jié)點通過HBase讀取相關用戶的Dashboard內(nèi)容并將數(shù)據(jù)傳回當前登錄用戶。

　　后臺任務從傳輸線中獲取信息，并生成對應列表及處理請求。

　　Cell單元中的博客信息會調(diào)用Redis緩存層。

　　請求指令流：當某位用戶發(fā)布博文，該篇博文即會被寫入傳輸線;所有Cell單元從中讀取博文內(nèi)容并將其轉(zhuǎn)寫入文章數(shù)據(jù)庫中;接著Cell單元會檢查該文用戶的關注者中有哪些處于自身單元內(nèi)部，最終將尋獲的關注者收件箱以及博文ID共同進行上傳。

　　Cell單元設計的優(yōu)勢所在：

　　請求指令的大量同時出現(xiàn)勢必對并行處理能力要求極高，這就使得設備組件必須彼此獨立，然而獨立性也會導致交互過程無法完成。Cell單元設計使并行處理工作成為一個獨立體系內(nèi)部的事務，并能夠在用戶群體不斷增長的情況下隨時保持強大的可調(diào)節(jié)能力。

　　Cell單元天然具備故障隔離能力。某個Cell單元出錯不會對其它單元造成任何嚴重影響。

　　Cell單元使更新內(nèi)容測試、信息發(fā)布以及軟件版本測試工作得以有條不紊地進行。

　　容易被大家忽略的關鍵性環(huán)節(jié)是：所有文章都會被復制到每一個Cell單元中去。

　　每個Cell單元都存儲著一套獨立的全局文章副本。每個Cell單元都能夠為Dashboard版面提供令人滿意的內(nèi)容。應用程序并不會查詢所有文章ID，它只會為登錄ID查詢相關文章，這樣一來用戶將能夠在自己的Dashboard版面中看到所有信息。每一個Cell單元都擁有填充Dashboard所必需的全部數(shù)據(jù)，因此不必進行什么跨單元通訊。

　　共使用了兩套HBase列表：一套用于存儲文章副本，而另一套則為Cell單元中的每個用戶保存博文ID，列表之間的內(nèi)容基本無甚關聯(lián)。第二套列表的作用是為用戶的Dashboard版面提供顯示內(nèi)容，也就是說不必追蹤該用戶所關注的每位其它用戶。另外，利用這種機制，如果筆者們在另一臺設備上閱讀或瀏覽某篇文章，系統(tǒng)將不會認為筆者們是在重復讀取同樣的內(nèi)容。無論通過何種方式，筆者們的閱讀進度都將保存在收件箱模塊的狀態(tài)一項中。

　　文章不會被直接置于收件箱中，因為這么多文章累積起來容量實在驚人。因此只將ID放入收件箱，而文章內(nèi)容則由Cell單元保存。這種方式大幅度降低了所需存儲空間，并讓用戶收件箱中的內(nèi)容按時間順序變得非常簡便。這么做的缺點是每個Cell單元都需要包含完整的文章副本。但令人驚訝的是，文章本身的體積總量遠遠小于映射所需的存儲空間。每天每個Cell單元中的文章內(nèi)容增量約為50GB，但收件箱內(nèi)容的增量卻高達每天2.7TB。由此可見，用戶的閱讀量比寫入量大得多。

　　用戶的Dashboard中并不顯示文章內(nèi)容，只包含基本的文章ID;因此數(shù)據(jù)增量的主體是不斷膨脹的ID。

　　即使用戶的關注者名單發(fā)生變更，這種設計仍然完全應付得來，因為所有文章都已經(jīng)存在于Cell單元中。如果Cell單元中只保存來自關注者的文章，那么一旦關注者名單有所變動，單元中的數(shù)據(jù)將不足以及時做出反應，同時將引發(fā)一系列不可避免的信息填充活動。

　　另有一套備選方案，利用一套獨立的文章集群存儲博文內(nèi)容。這種設計的缺點在于，一旦這套集群出現(xiàn)故障，那么整個網(wǎng)站都將陷入癱瘓。相比之下，采用Cell單元設計、將所有文章復制到每一個單元當中的做法使整個架構(gòu)牢固而可靠。

　　對于那些關注人數(shù)以百萬計且相當活躍的用戶，會根據(jù)他們的訪問模式獲得特定的用戶服務。

　　不同的用戶往往使用不同的訪問模式以及與個人習慣相符的分布模式。Tumblr為用戶準備了兩種不同的分布模式：一種適合人氣超高的熱門用戶、另一種則適合任何類型的用戶。

　　數(shù)據(jù)的處理方式也根據(jù)用戶類型的變化而有所不同。來自活躍用戶的文章實際上不會真正予以發(fā)布，而只是有選擇地呈現(xiàn)給其他用戶。

　　Tumblr在處理大量關注其他使用者的用戶時，采用的方法與處理擁有大量關注者的用戶非常類似。

　　每個Cell單元的大小很難確定。單元的大小會影響到網(wǎng)站的故障機率，而單元中所包含用戶的數(shù)量則是最關鍵的因素。需要在用戶的使用期望與支撐這種期望的成本支出之間找到一個平衡點。

　　從傳輸線中讀取信息是網(wǎng)絡問題的核心內(nèi)容。在Cell單元內(nèi)部，網(wǎng)絡流量始終處于可管理的狀態(tài)。

　　由于Cell單元的數(shù)量日益增加，最終Cell單元組的概念被添加進來。這是一套分層復制規(guī)劃，同時也有利于將數(shù)據(jù)信息遷移到多個數(shù)據(jù)中心當中。

　　成為一顆立足于紐約的耀眼新星

　　紐約的環(huán)境背景相當特殊，其中充斥著大量財務與廣告因素。作為一家缺乏經(jīng)驗的新興企業(yè)，Tumblr在人才招聘及設備租用方面都面臨著挑戰(zhàn)。

　　在過去幾年中，紐約市一直致力于扶植新興企業(yè)。紐約大學與哥倫比亞大學制訂了完善的計劃，鼓勵在校學生到新興企業(yè)中去實習，而不是一頭扎進華爾街。Bloomberg市長也將支持科技發(fā)展作為紐約市的一項基本戰(zhàn)略。

　　團隊構(gòu)成

　　團隊：基礎設施、平臺、SRE(即系統(tǒng)調(diào)整及修復)、產(chǎn)品、網(wǎng)絡運行以及服務支持。

　　基礎設施：5層及以下。IP地址及以下、DNS、硬件供應。

　　平臺：核心應用程序開發(fā)、SQL分區(qū)、服務、網(wǎng)絡運行。

　　SRE: 存在于服務團隊與網(wǎng)絡運行團隊之間，致力于解決迫在眉睫的系統(tǒng)可靠性及可擴展性問題。

　　服務團隊：致力于發(fā)展戰(zhàn)略層面的問題，處理周期一般為一到兩個月。

　　網(wǎng)絡運行：負責問題檢測與響應以及相關調(diào)整工作。

　　軟件開發(fā)

　　一切工作以一套專門將PHP應用程序分布到各處的rsync腳本集合為基礎。一旦設備總數(shù)達到200臺，系統(tǒng)就會發(fā)生故障——部署流程無比緩慢、設備自身也停滯在各種各樣的配置狀態(tài)中。

　　在此之后，Tumblr決定將部署流程(包括開發(fā)、啟用及生產(chǎn)等環(huán)節(jié))利用Capistrano創(chuàng)建在服務堆棧中。這在數(shù)十臺設備協(xié)作的情況下沒有問題，但通過SSH讓數(shù)百臺設備彼此連接后，問題再一次出現(xiàn)。

　　現(xiàn)在所有設備上都運行著一套調(diào)整軟件，這套軟件以紅帽Func為基礎，本質(zhì)上是一個用于將指令分配到各主機處的輕量型API。規(guī)?；匾脖徊渴鹪贔unc內(nèi)部。

　　開發(fā)工作在Func層面上進行，并采用“在某個主機組上執(zhí)行某操作”的直觀表述，這就成功回避了對SSH的依賴。例如筆者們希望在A組中部署軟件，那么管理員只需選定目標節(jié)點集合并運行部署指令，即可完成任務。

　　部署指令通過Capistrano進行實施，并能夠以git檢查或者倉庫輸出的形式生效。擴展性方面也有所保障，因為指令面向的交互對象為HTTP。之所以采用Capistrano，是因為它能在良好的版本控制之下支持簡單目錄，這種特性使其與PHP應用程序之間的配合更為默契。以版本控制更新活動使得每個目錄都包含安全散列算法，這樣技術(shù)人員也能夠方便地核對當前版本是否正確。

　　Func API的作用是回饋狀態(tài)，通知系統(tǒng)哪些設備正在運行哪些版本的軟件。

　　任何服務項目都能夠安全地加以重啟，因為默認狀態(tài)下項目將首先逐漸斷開連接、之后才實施重啟動作。

　　每項功能在投付使用之前，都會在獨立環(huán)境下進行測試。

　　開發(fā)工作

　　Tumblr所秉承的理論是讓每位用戶都能使用自己想要的工具，但隨著用戶群體的激增，這種想法實在難以為繼。招聘精明強干的技術(shù)人員不是件容易的事，因此他們開始對堆棧進行標準化改造，旨在讓技術(shù)工作更好上手、團隊培養(yǎng)更加高效、產(chǎn)品問題的處理更加迅速并在上述內(nèi)容的基礎上建立業(yè)務運作。

　　整個開發(fā)過程與Scrum比較相似。選擇的是工作量較小的輕量級模式。

　　每位開發(fā)人員都擁有一臺經(jīng)過預先配置的開發(fā)專用設備。設備更新工作則通過Puppet實現(xiàn)。

　　開發(fā)用設備可以隨時回收并進行變更及測試，接著重新投入使用并最終執(zhí)行生產(chǎn)任務。

　　開發(fā)人員們常用的文本編輯器是Vim和Textmate。

　　PHP應用程序的測試以代碼審核的方式進行。

　　他們在服務項目端部署了一套測試用基礎設施，其中包括hooks、Jenkins以及連續(xù)性集成與通行創(chuàng)建系統(tǒng)。

　　招聘流程

　　面試階段一般不會涉及數(shù)學、分析以及腦力測驗。提出的問題主要圍繞著求職者所申請的職位展開。他們是否聰慧?能否順利完成份內(nèi)的工作?但評估求職者能否“順利完成份內(nèi)工作”有一定難度?？傊嬖嚨哪康氖钦页錾碡摬拍艿男氯?，而不是有意排除一定比例的求職者。

　　編碼能力是考核的一大重點。他們會針對示例代碼提出問題，在電話面試的過程中也常常利用Collabedit考驗求職者的共享代碼編寫能力。

　　面試本身并不具有對抗性，他們只是在嘗試發(fā)現(xiàn)優(yōu)秀的人才。求職者們可以在面試中使用像谷歌這樣的輔助工具來解決問題，因為Tumblr相信善于使用外界助力的開發(fā)人員才是能夠獨當一面的上上之選，所以在考核中并不禁止使用輔助手段。

　　鑒于Tumblr所要應對的數(shù)據(jù)流量相當巨大，因此招徠在規(guī)模化業(yè)務方面具備豐富經(jīng)驗的人才正是當務之急。事實上在全球范圍內(nèi)，還沒有幾家企業(yè)需要處理如此規(guī)模的日常工作。

　　舉例來說，他們需要一款新的ID生成器，要求服務運行環(huán)境為JVM，在每秒一萬條請求的使用頻率下保證響應時間低于1毫秒，并且要在內(nèi)存限定為500MB的前提下保證高可用性。結(jié)果在招聘過程中，他們發(fā)現(xiàn)了幾位牛人，不僅嚴格按照給定條件執(zhí)行、還將響應延遲降低到新的水平。這也最終使得Tumblr愿意花費大量時間對JVM運行環(huán)境進行調(diào)整。

　　正是因為他們的這種精神，所以才會有他們現(xiàn)在的成功!

重慶中技互聯(lián)網(wǎng)信息咨詢有限公司 www.tmsmall666.cn