軟體系結(jié)構(gòu) (南理工)10案例分析

軟件體系結(jié)構(gòu)案例分析

——Twitter簡(jiǎn)析趙學(xué)龍1/5/20241Twitter是什么？一種可以向你的朋友或者follower

發(fā)送短信息的免費(fèi)網(wǎng)絡(luò)效勞。是多種通信方式的綜合Email電子郵件instantmessenger短信blog博客Rss〔不同之處在于它的字?jǐn)?shù)限制在140字〕起源于“Whatareyoudoing？〞的答案現(xiàn)在是“what’shappening〞1/5/20242Twitter的起源與開(kāi)展隨著信息爆炸的加劇，微博客網(wǎng)站Twitter橫空出世了。從2006年5月Twitter上線，到2007年12月，一年半的時(shí)間里，Twitter用戶數(shù)從0增長(zhǎng)到6.6萬(wàn)。2021年12月，Twitter的用戶數(shù)到達(dá)5百萬(wàn)，消息數(shù)量就到達(dá)了10億條，2021年3月，Twitter的消息數(shù)量首次到達(dá)100億條，Twitter全球用戶數(shù)已達(dá)1億。Twitter的日均注冊(cè)數(shù)約為30萬(wàn)人，獨(dú)立訪問(wèn)量達(dá)1.8億。1/5/20243Twitter開(kāi)展目前，60%的Twitter新用戶現(xiàn)在來(lái)自美國(guó)以外，而其75%的流量也來(lái)自Twitter之外。新浪微博5百萬(wàn)用戶〔2021年3月〕〔2021年8月內(nèi)測(cè)〕QQ同時(shí)在線用戶1億〔2021年3月〕(2007年9月注冊(cè)用戶8.5億)用戶7.47億〔2021年1月，工信部〕中國(guó)上網(wǎng)人數(shù)4.04億〔2021年5月〕1/5/20244Twitter體系結(jié)構(gòu)Twitter網(wǎng)站的成功，先決條件是能夠同時(shí)給千萬(wàn)用戶提供效勞，而且提供效勞的速度要快。有觀點(diǎn)認(rèn)為，Twitter的業(yè)務(wù)邏輯簡(jiǎn)單，所以競(jìng)爭(zhēng)門(mén)檻低。Twitter的競(jìng)爭(zhēng)力，離不開(kāi)嚴(yán)謹(jǐn)?shù)南到y(tǒng)架構(gòu)設(shè)計(jì)。1/5/20245Twitter業(yè)務(wù)邏輯Twitter的核心業(yè)務(wù)邏輯，在于Following和Befollowed。進(jìn)入Twitter個(gè)人主頁(yè)，你會(huì)看到你following的那些作者，最近發(fā)表的微博客。所謂微博客，就是一那么短信，Twitter規(guī)定，短信的長(zhǎng)度不得超過(guò)140個(gè)字。這就是following的過(guò)程。當(dāng)你寫(xiě)了一那么短信并發(fā)表以后，你的followers會(huì)立刻在他們的個(gè)人主頁(yè)中看到你寫(xiě)的最新短信。這就是befollowed的過(guò)程。1/5/20246Twitter業(yè)務(wù)邏輯1.為每一個(gè)注冊(cè)用戶訂制一個(gè)Be-followed的表，主要內(nèi)容是每一個(gè)follower的ID。同時(shí)，也訂制一個(gè)Following的表，主要內(nèi)容是每一個(gè)following作者的ID。2.當(dāng)用戶翻開(kāi)自己的個(gè)人空間時(shí)，Twitter先查閱Following表，找到所有following的作者的ID。然后去數(shù)據(jù)庫(kù)讀取每一位作者最近寫(xiě)的短信。匯總后按時(shí)間順序顯示在用戶的個(gè)人主頁(yè)上。3.當(dāng)用戶寫(xiě)了一那么短信時(shí)，Twitter先查閱Be-followed表，找到所有followers的IDs。然后逐個(gè)更新那些followers的主頁(yè)。實(shí)現(xiàn)這個(gè)業(yè)務(wù)流程似乎很容易。1/5/20247Twitter業(yè)務(wù)邏輯從作者發(fā)表到讀者獲取，中間的延遲，取決于JavaScript更新的間隔，以及Twitter效勞器更新每個(gè)follower的主頁(yè)的時(shí)間。從系統(tǒng)架構(gòu)上來(lái)說(shuō)，似乎傳統(tǒng)的三層體系結(jié)構(gòu)〔Three-tierarchitecture〕足夠滿足這個(gè)業(yè)務(wù)邏輯的需要。事實(shí)上，最初的Twitter系統(tǒng)架構(gòu)，確實(shí)就是三層結(jié)構(gòu)。1/5/20248三層體系結(jié)構(gòu)三層架構(gòu)就是將整個(gè)業(yè)務(wù)應(yīng)用劃分為：表現(xiàn)層〔UI〕、業(yè)務(wù)邏輯層〔BLL〕、數(shù)據(jù)訪問(wèn)層〔DAL〕。區(qū)分層次的目的即為了“高內(nèi)聚，低耦合〞的思想。表現(xiàn)層〔UI〕：通俗講就是展現(xiàn)給用戶的界面，即用戶在使用一個(gè)系統(tǒng)的時(shí)候他的所見(jiàn)所得。業(yè)務(wù)邏輯層〔BLL〕：針對(duì)具體問(wèn)題的操作，也可以說(shuō)是對(duì)數(shù)據(jù)層的操作，對(duì)數(shù)據(jù)業(yè)務(wù)邏輯處理。數(shù)據(jù)訪問(wèn)層〔DAL〕：該層所做事務(wù)直接操作數(shù)據(jù)庫(kù)，針對(duì)數(shù)據(jù)的增添、刪除、修改、更新、查找等。網(wǎng)站的架構(gòu)設(shè)計(jì)，傳統(tǒng)的做法是三層結(jié)構(gòu)。所謂“傳統(tǒng)的〞，并不等同于“過(guò)時(shí)的〞。1/5/20249Twitter的體系結(jié)構(gòu)2006年5月Twitter剛上線的時(shí)候，為了簡(jiǎn)化網(wǎng)站的開(kāi)發(fā)，他們使用了Ruby-On-Rails工具，而Ruby-On-Rails的設(shè)計(jì)思想，就是三層結(jié)構(gòu)。1.表述層(PresentationTier)用的工具是ApacheWebServer，主要任務(wù)是解析HTTP協(xié)議，把來(lái)自不同用戶的，不同類(lèi)型的請(qǐng)求，分發(fā)給邏輯層。2.邏輯層(LogicTier〕用的工具是MongrelRailsServer，利用Rails現(xiàn)成的模塊，降低開(kāi)發(fā)的工作量。3.數(shù)據(jù)層(DataTier)用的工具是MySQL數(shù)據(jù)庫(kù)。1/5/202410數(shù)據(jù)層Twitter的效勞概括為兩個(gè)核心：用戶，短信。用戶與用戶之間的關(guān)系，是追與被追的關(guān)系，也就是Following和Befollowed。對(duì)于一個(gè)用戶來(lái)說(shuō)，他只讀自己“追〞的那些人寫(xiě)的短信。而他自己寫(xiě)的短信，只有那些“追〞自己的人才會(huì)讀。抓住這兩個(gè)核心，就不難理解Twitter的其它功能是如何實(shí)現(xiàn)的。1/5/202411數(shù)據(jù)層圍繞這兩個(gè)核心，就可以著手設(shè)計(jì)數(shù)據(jù)模式，也就是存放在數(shù)據(jù)層中的數(shù)據(jù)的組織方式。不妨設(shè)置三個(gè)表，1.用戶表：用戶ID，姓名，登錄名和密碼，狀態(tài)〔在線與否〕。2.短信表：短信ID，作者ID，正文〔定長(zhǎng)，140字〕，時(shí)間戳。3.用戶關(guān)系表，記錄追與被追的關(guān)系：用戶ID，他追的用戶IDs(Following)，追他的用戶IDs(Befollowed)。1/5/202412邏輯層當(dāng)用戶發(fā)表一條短信的時(shí)候，執(zhí)行以下五個(gè)步驟，1.把該短信記錄到“短信表〞中去。2.從“用戶關(guān)系表〞中取出追他的用戶的IDs。3.有些追他的用戶目前在線，另一些可能離線。在線與否的狀態(tài)，可以在“用戶表〞中查到。過(guò)濾掉那些離線的用戶的IDs。4.把那些追他的并且目前在線的用戶的IDs，逐個(gè)推進(jìn)一個(gè)隊(duì)列(Queue)中去。5.從這個(gè)隊(duì)列中，逐個(gè)取出那些追他的并且目前在線的用戶的IDs，并且更新這些人的主頁(yè)，也就是添加最新發(fā)表的這條短信。前三步容易解決，都是簡(jiǎn)單的數(shù)據(jù)庫(kù)操作。最后兩步，需要用到一個(gè)輔助工具，隊(duì)列。隊(duì)列的意義在于，別離了任務(wù)的產(chǎn)生與任務(wù)的執(zhí)行1/5/202413邏輯層簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)來(lái)實(shí)現(xiàn)隊(duì)列，例如動(dòng)態(tài)鏈表，甚至靜態(tài)數(shù)組就可以。為了支持聯(lián)絡(luò)多臺(tái)機(jī)器的、分布式的隊(duì)列。Twitter團(tuán)隊(duì)自己動(dòng)手實(shí)現(xiàn)了一個(gè)隊(duì)列：Kestrel。1/5/202414表現(xiàn)層表述層的主要職能：1.HTTP協(xié)議處理器(HTTPProcessor)，包括拆解接收到的用戶請(qǐng)求，以及封裝需要發(fā)出的結(jié)果。2.分發(fā)器(Dispatcher)，把接收到的用戶請(qǐng)求，分發(fā)給邏輯層的機(jī)器處理。如果邏輯層只有一臺(tái)機(jī)器，那么分發(fā)器無(wú)意義。但是如果邏輯層由多臺(tái)機(jī)器組成，什么樣的請(qǐng)求，發(fā)給邏輯層里面哪一臺(tái)機(jī)器，就大有講究了。邏輯層里眾多機(jī)器，可能各自專(zhuān)門(mén)負(fù)責(zé)特定的功能，而在同功能的機(jī)器之間，要分?jǐn)偣ぷ鳎关?fù)載均衡。1/5/202415表現(xiàn)層訪問(wèn)Twitter網(wǎng)站的，不僅僅是瀏覽器，而且還有，還有像QQ那樣的電腦桌面工具，另外還有各式各樣的網(wǎng)站插件。因此，Twitter的訪問(wèn)者與Twitter網(wǎng)站之間的通訊協(xié)議，不一定是HTTP，也存在其它協(xié)議。三層Twitter架構(gòu)，主要是針對(duì)HTTP協(xié)議的終端。但是對(duì)于其它協(xié)議的終端，Twitter的架構(gòu)沒(méi)有明顯地劃分成三段，而是把表述層和邏輯層合二為一，在Twitter的文獻(xiàn)中，這二合一經(jīng)常被稱(chēng)為“API〞。1/5/202416Twitter三層體系結(jié)構(gòu)這么知名的網(wǎng)站，架構(gòu)就這么簡(jiǎn)單？真正的Twitter架構(gòu)與差距不大，不一樣的地方在于加了一些簡(jiǎn)單的緩存(Cache)1/5/202417Cache==Cash緩存等于現(xiàn)金。雖然這話有點(diǎn)夸張，但是正確使用緩存，對(duì)于大型網(wǎng)站的建設(shè)，是至關(guān)重要的大事。網(wǎng)站在回應(yīng)用戶請(qǐng)求時(shí)的反響速度，是影響用戶體驗(yàn)的一大因素。而影響速度的原因有很多，其中一個(gè)重要的原因在于硬盤(pán)的讀寫(xiě)(DiskIO)。硬盤(pán)的讀寫(xiě)，速度比內(nèi)存的慢了百萬(wàn)倍20211/5/202418好的網(wǎng)站Twitter工程師認(rèn)為，一個(gè)用戶體驗(yàn)良好的網(wǎng)站，當(dāng)一個(gè)用戶請(qǐng)求到達(dá)以后，應(yīng)該在平均500ms以內(nèi)完成回應(yīng)。而Twitter的理想，是到達(dá)200ms-300ms的反響速度。因此在網(wǎng)站架構(gòu)上，Twitter大規(guī)模地，多層次多方式地使用緩存。Twitter在緩存使用方面的實(shí)踐，以及從這些實(shí)踐中總結(jié)出來(lái)的經(jīng)驗(yàn)教訓(xùn)，是Twitter網(wǎng)站架構(gòu)的一大看點(diǎn)。1/5/202419哪里需要緩存？越是DiskIO頻繁的地方，越需要緩存。有沒(méi)有必要把這幾個(gè)核心的數(shù)據(jù)庫(kù)表統(tǒng)統(tǒng)存放到緩存中去？1.用戶表：2.短信表：3.用戶關(guān)系表Twitter的做法是把這些表拆解，把其中讀寫(xiě)最頻繁的列放進(jìn)緩存。1/5/202420緩存VectorCacheIDs緩存。即新發(fā)表的短信的IDs，熱門(mén)短信的IDs，相關(guān)作者的IDs，訂閱這些作者的讀者的IDs。RowCache

存放短信正文使用的工具都是開(kāi)源的MemCached實(shí)踐結(jié)果：VectorCache的命中率是99%，RowCache的命中率是95%1/5/202421緩存FragmentCache緩存熱門(mén)作者寫(xiě)的短信的布局頁(yè)面(Fragment)，就可以提高網(wǎng)站整體的讀取效率。PageCache：緩存熱門(mén)作者主頁(yè)。與FragmentCache主機(jī)分開(kāi)使用的工具都是開(kāi)源的MemCached實(shí)際結(jié)果：FragmentCache的命中率是95%PageCache的命中率是40%API通道受理的流量占總流量的80%-90%

1/5/202422緩存HTTPAccelerator

Web通道的壓力，主要來(lái)自于搜索。尤其是面臨突發(fā)事件時(shí)，讀者們會(huì)搜索相關(guān)短信，而不理會(huì)這些短信的作者，是不是自己“追〞的那些作者。

要降低搜索的壓力，就是把搜索關(guān)鍵詞，及其對(duì)應(yīng)的搜索結(jié)果，緩存起來(lái)。使用的工具開(kāi)源工程VarnishVarnish的操作比較復(fù)雜，為了降低崩潰造成整個(gè)網(wǎng)站癱瘓的可能性1/5/202423緩存ApacheWebServer的主要任務(wù)，是解析HTTP，以及分發(fā)任務(wù)。不同的MongrelRailsServer負(fù)責(zé)不同的任務(wù)。但是絕大多數(shù)MongrelRailsServer，都要與VectorCache和RowCache聯(lián)系，讀取數(shù)據(jù)。RailsServer通過(guò)Rails插件〔CacheMoney〕與MemCached聯(lián)系。1/5/202424緩存雖然Twitter沒(méi)有公開(kāi)Varnish的命中率是多少，使用了Varnish以后，導(dǎo)致整個(gè)Twitter網(wǎng)站的負(fù)載下降了50%，1/5/202425Twitter體系結(jié)構(gòu)消息隊(duì)列(MessageQueue)隔離用戶請(qǐng)求與相關(guān)操作，均衡流量頂峰通過(guò)讓Apache進(jìn)程空循環(huán)的方法，迅速接納用戶的訪問(wèn)，推遲效勞，說(shuō)白了是個(gè)緩兵之計(jì)，目的是讓用戶不至于收到“HTTP503〞錯(cuò)誤提示，“503錯(cuò)誤〞是指“效勞不可用(ServiceUnavailable)〞，也就是網(wǎng)站拒絕訪問(wèn)。1/5/202426消息隊(duì)列(MessageQueue)其中洪峰時(shí)刻，Twitter網(wǎng)站每秒鐘收到350條新短信，這個(gè)流量洪峰維持了大約5分鐘。根據(jù)統(tǒng)計(jì)，平均每個(gè)Twitter用戶被120人“追〞，這就是說(shuō)，這350條短信，平均每條都要發(fā)送120次。這意味著，在這5分鐘的洪峰時(shí)刻，Twitter網(wǎng)站每秒鐘需要發(fā)送350x120=42,000條短信。2021年1月20日星期二，美國(guó)總統(tǒng)BarackObama就職并發(fā)表演說(shuō)。1/5/202427消息隊(duì)列(MessageQueue)面對(duì)洪峰，如何才能保證網(wǎng)站不崩潰？方法是迅速接納，但是推遲效勞。打個(gè)比方，在晚餐頂峰時(shí)段，餐館常?？蜐M。對(duì)于新來(lái)的顧客，餐館效勞員不是拒之門(mén)外，而是讓這些顧客在休息廳等待。這就是所說(shuō)的“燙平流量頂峰〞。1/5/202428消息隊(duì)列(MessageQueue)當(dāng)一位用戶訪問(wèn)Twitter網(wǎng)站時(shí)，接待他的是ApacheWebServer。Apache做的事情非常簡(jiǎn)單，它把用戶的請(qǐng)求解析以后，轉(zhuǎn)發(fā)給MongrelRailsSever，由Mongrel負(fù)責(zé)實(shí)際的處理。而Apache騰出手來(lái)，迎接下一位用戶。這樣就防止了在洪峰期間，用戶連接不上Twitter網(wǎng)站的為難局面。1/5/202429消息隊(duì)列(MessageQueue)雖然Apache的工作簡(jiǎn)單，但是并不意味著Apache可以接待無(wú)限多的用戶。原因是Apache解析完用戶請(qǐng)求，并且轉(zhuǎn)發(fā)給MongrelServer以后，負(fù)責(zé)解析這個(gè)用戶請(qǐng)求的進(jìn)程(process)，并沒(méi)有立刻釋放，而是進(jìn)入空循環(huán)，等待MongrelServer返回結(jié)果。1/5/202430Apache內(nèi)部的進(jìn)程機(jī)制Apache能夠容納的并發(fā)的連接數(shù)量(concurrentconnections)，實(shí)際上受制于Apache能夠容納的進(jìn)程數(shù)量。圖中每個(gè)Worker代表一個(gè)進(jìn)程。Apache能夠容納多少個(gè)并發(fā)連接呢？有實(shí)驗(yàn)結(jié)果是4,000個(gè)。如何增加呢？1/5/202431消息隊(duì)列(MessageQueue)通過(guò)讓Apache進(jìn)程空循環(huán)的方法，迅速接納用戶的訪問(wèn)，推遲效勞，說(shuō)白了是個(gè)緩兵之計(jì)，目的是讓用戶不至于收到“HTTP503〞錯(cuò)誤提示，“503錯(cuò)誤〞是指“效勞不可用(ServiceUnavailable)〞，也就是網(wǎng)站拒絕訪問(wèn)。1/5/202432Kestrel消息隊(duì)列對(duì)于Twitter系統(tǒng)來(lái)說(shuō)，龐大的效勞器集群，尤其是以MemCached為主的眾多的緩存，表達(dá)了蓄洪的容量。引流的手段是Kestrel消息隊(duì)列，用于傳遞控制指令。渠道是機(jī)器與機(jī)器之間的數(shù)據(jù)傳輸通道，尤其是通往MemCached的數(shù)據(jù)通道。渠道的優(yōu)劣，在于是否通暢。Twitter系統(tǒng)的抗洪措施，表達(dá)在有效地控制數(shù)據(jù)流，保證在洪峰到達(dá)時(shí)，能夠及時(shí)把數(shù)據(jù)疏散到多個(gè)機(jī)器上去，從而防止壓力過(guò)度集中，造成整個(gè)系統(tǒng)的癱瘓。1/5/202433Twitter網(wǎng)站內(nèi)部流程假設(shè)有兩個(gè)作者，通過(guò)瀏覽器，在Twitter網(wǎng)站上發(fā)表短信。有一個(gè)讀者，也通過(guò)瀏覽器，訪問(wèn)網(wǎng)站并閱讀他們寫(xiě)的短信。1/5/202434Twitter網(wǎng)站內(nèi)部流程1.作者的瀏覽器與網(wǎng)站建立連接，ApacheWebServer分配一個(gè)進(jìn)程(WorkerProcess)。作者登錄，Twitter查找作者的ID，并作為Cookie，記憶在HTTP郵包的頭屬性里。1/5/202435Twitter網(wǎng)站內(nèi)部流程2.瀏覽器上傳作者新寫(xiě)的短信(Tweet)，Apache收到短信后，把短信連同作者ID，轉(zhuǎn)發(fā)給MongrelRailsServer。然后Apache進(jìn)程進(jìn)入空循環(huán)，等待Mongrel的回復(fù)，以便更新作者主頁(yè)，把新寫(xiě)的短信添加上去。1/5/202436Twitter網(wǎng)站內(nèi)部流程3.Mongrel收到短信后，給短信分配一個(gè)ID，然后把短信ID與作者ID，緩存到VectorMemCached效勞器上去。1/5/202437Twitter網(wǎng)站內(nèi)部流程3.Mongrel收到短信后，給短信分配一個(gè)ID，然后把短信ID與作者ID，緩存到VectorMemCached效勞器上去。接著，Mongrel把短信ID與短信正文，緩存到RowMemCached效勞器上去。同時(shí)，Mongrel讓VectorMemCached查找，有哪些讀者“追〞這位作者。如果VectorMemCached沒(méi)有緩存這些信息，VectorMemCached自動(dòng)去MySQL數(shù)據(jù)庫(kù)查找，得到結(jié)果后，緩存起來(lái)，以備日后所需。然后，把讀者IDs回復(fù)給Mongrel。1/5/202438Twitter網(wǎng)站內(nèi)部流程4.Mongrel通知Kestrel消息隊(duì)列效勞器，為每個(gè)作者及讀者開(kāi)設(shè)一個(gè)隊(duì)列，隊(duì)列的名稱(chēng)中隱含用戶ID。如果Kestrel效勞器中已經(jīng)存在這些隊(duì)列，那就延用以往的隊(duì)列。對(duì)應(yīng)于每個(gè)短信，Mongrel已經(jīng)從VectorMemCached那里知道，有哪些讀者追這條短信的作者。Mongrel把這條短信的ID，逐個(gè)放進(jìn)每位讀者的隊(duì)列，以及作者本人的隊(duì)列。

1/5/202439Twitter網(wǎng)站內(nèi)部流程5.同一臺(tái)MongrelServer，或者另一臺(tái)MongrelServer，在處理某個(gè)Kestrel隊(duì)列中的消息前，從這個(gè)隊(duì)列的名稱(chēng)中解析出相應(yīng)的用戶ID，這個(gè)用戶，既可能是讀者，也可能是作者。然后Mongrel從Kestrel隊(duì)列中，逐個(gè)提取消息，解析消息中包含的短信ID。并從RowMemCached緩存器中，查找對(duì)應(yīng)于這個(gè)短信ID的短信正文。

這時(shí)，Mongrel既得到了用戶的ID，也得到了短信正文。接下去Mongrel就著手更新用戶的主頁(yè)，添加上這條短信的正文。1/5/202440Twitter網(wǎng)站內(nèi)部流程6.Mongrel把更新后的作者的主頁(yè)，傳遞給正在空循環(huán)的Apache的進(jìn)程。該進(jìn)程把作者主頁(yè)主動(dòng)傳送(push)給作者的瀏覽器。如果讀者的瀏覽器事先已經(jīng)登錄Twitter網(wǎng)站，建立連接，那么Apache給該讀者也分配了一個(gè)進(jìn)程，該進(jìn)程也處于空循環(huán)狀態(tài)。Mongrel把更新后的讀者的主頁(yè)，傳遞給相應(yīng)進(jìn)程，該進(jìn)程把讀者主頁(yè)主動(dòng)傳遞給讀者的瀏覽器。。1/5/202441流量洪峰美國(guó)年度橄欖球決賽，綽號(hào)超級(jí)碗(SuperBowl)。SuperBowl在美國(guó)的收視率，相當(dāng)于中國(guó)的央視春節(jié)晚會(huì)。對(duì)于Twitter來(lái)說(shuō)，可以預(yù)料的是，比賽進(jìn)行過(guò)程中，Twitter流量必然大漲。比賽越劇烈，流量越高漲。Twitter無(wú)法預(yù)料的是，流量究竟會(huì)漲到多少，尤其是洪峰時(shí)段，流量會(huì)到達(dá)多少。1/5/202442流量洪峰根據(jù)統(tǒng)計(jì)，在2021年SuperBowl比賽進(jìn)行中，每分鐘的流量與當(dāng)日平均流量相比，平均高出40%。在比賽最劇烈時(shí)，更高達(dá)150%以上。與一周前，2021年1月27日，一個(gè)平靜的星期天的同一時(shí)段相比，流量的波動(dòng)從平均10%，上漲到40%，最高波動(dòng)從35%，上漲到150%以上。1/5/202443流量洪峰由此可見(jiàn)，Twitter流量的波動(dòng)十分可觀。對(duì)于Twitter公司來(lái)說(shuō)，如果預(yù)先購(gòu)置足夠的設(shè)備，以承受流量的變化，尤其是重大事件導(dǎo)致的洪峰流量，那么這些設(shè)備在大局部時(shí)間處于閑置狀態(tài)，非常不經(jīng)濟(jì)。但是如果缺乏足夠的設(shè)備，那么面對(duì)重大事件，Twitter系統(tǒng)有可能崩潰，造成的后果是用戶流失。怎么辦？方法是變買(mǎi)為租。Twitter公司自己購(gòu)置的設(shè)備，其規(guī)模以應(yīng)付無(wú)重大事件時(shí)的流量壓力為限。同時(shí)租賃云計(jì)算平臺(tái)公司的設(shè)備，以應(yīng)付重大事件來(lái)臨時(shí)的洪峰流量。計(jì)算資源實(shí)時(shí)分配，自動(dòng)分配計(jì)算資源。1/5/202444流量洪峰但是租來(lái)的計(jì)算資源怎么用？大局部用于增加ApacheWebServer。每個(gè)訪問(wèn)Twitter網(wǎng)站的瀏覽器，都與網(wǎng)站保持長(zhǎng)連接。目的是一旦有人發(fā)表新的短信，Twitter網(wǎng)站在500ms以內(nèi)，把新短信push給他的讀者。問(wèn)題是在沒(méi)有更新的時(shí)候，每個(gè)長(zhǎng)連接占用一個(gè)Apache的進(jìn)程，而這個(gè)進(jìn)程處于空循環(huán)。所以，絕大多數(shù)Apache進(jìn)程，在絕大多數(shù)時(shí)間里，處于空循環(huán)，因此占用了大量資源。事實(shí)上，通過(guò)ApacheWebServers的流量，雖然只占Twitter總流量的10%-20%，但是Apache卻占用了Twitter整個(gè)效勞器集群的50%的資源1/5/202445洪峰流量當(dāng)一個(gè)來(lái)自瀏覽器的用戶請(qǐng)求到達(dá)Twitter后臺(tái)系統(tǒng)的時(shí)候，第一個(gè)迎接它的，是ApacheWebServer。第二個(gè)是MongrelRailsServer。Mongrel既負(fù)責(zé)處理上傳的請(qǐng)求，也負(fù)責(zé)處理下載的請(qǐng)求。Mongrel處理上傳和下載的業(yè)務(wù)邏輯非常簡(jiǎn)潔，但是簡(jiǎn)潔的表象之下，卻蘊(yùn)含著反常規(guī)的設(shè)計(jì)1/5/202446洪峰流量當(dāng)Mongrel收到新短信后，分配一個(gè)新的短信ID。然后把新短信的ID，連同作者ID，緩存進(jìn)VectorMemCached效勞器。接著，把短信ID以及正文，緩存進(jìn)RowMemCached效勞器。接著，Mongrel把新短信的ID，逐個(gè)放進(jìn)“追〞這位作者的所