Twitter服務器的數(shù)據(jù)請求處理的過程有哪些

本篇內(nèi)容主要講解“Twitter服務器的數(shù)據(jù)請求處理的過程有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Twitter服務器的數(shù)據(jù)請求處理的過程有哪些”吧!

一、twitter的核心業(yè)務
twitter的核心業(yè)務，在于following和be followed
（1）following-關(guān)注進入個人主頁，會看到你follow的人發(fā)表的留言（不超過140個字），這是following的過程；
（2）followed-被關(guān)注你發(fā)布一條留言，follow你的人將看到這條信息，這是be followed的過程；

二、twitter的業(yè)務邏輯
twitter的業(yè)務邏輯也不復雜。
following業(yè)務，查follow了哪些人，以及這些人發(fā)表的留言；
followed業(yè)務，前端js輪詢后端，看follow了的人有沒有新留言，有則更新（更新及時性取決于輪詢時間）；

三、三層架構(gòu)（three-tier architecture）
網(wǎng)站的架構(gòu)設計，傳統(tǒng)的做法是三層架構(gòu)，所謂“傳統(tǒng)”不意味著“過時”，新潮的技術(shù)不成熟，傳統(tǒng)的路子更穩(wěn)健。
（1）表示層（presentation tier）：apache web server，主要任務是解析http協(xié)議，將請求分發(fā)給邏輯層；
（2）邏輯層（logic tier）：mongrel rails server，利用rails現(xiàn)成的模塊，降低工作量；
（3）數(shù)據(jù)層（data tier）：mysql；
表示層：表示層的主要職能有2個：（1）http協(xié)議處理（http processor）；（2）分發(fā)器（dispatcher）；當然，訪問twitter的不僅僅是瀏覽器，可能還有手機，由于可能存在其他協(xié)議，故可能存在其他processor。
邏輯層：當用戶發(fā)布消息時，依次執(zhí)行：（1）存消息至msg表；（2）查用戶relation表，找出其followed_ids；（3）獲取followed_ids中用戶的狀態(tài)；（4）在線的ids，將消息push進一個隊列queue；（5）queue中的msg，更新ids的主頁；這里面要用到隊列，其實現(xiàn)方式有很多種，例如apache mina，twitter團隊自己實現(xiàn)了一個kestrel。
數(shù)據(jù)層：twitter的核心是用戶；消息；用戶關(guān)系。圍繞這幾個核心，其核心數(shù)據(jù)的schema設計：（1）用戶表userid, name, pass, status, …（2）消息表msgid, author_id, msg, time, …（3）用戶關(guān)系表relationid, following_ids, followed_ids。
無論如何，架構(gòu)框架清晰如下：

四、cache=cash即緩存等于收入
cache的使用對大型網(wǎng)站架構(gòu)至關(guān)重要，網(wǎng)站響應速度是影響用戶體驗最明顯的因素，而影響響應速度最大的敵人又是磁盤I/O。twitter工程師認為，良好體驗的網(wǎng)站平均響應時間應該在500ms左右，理想的時間是200-300ms。關(guān)于cache的使用，是twitter架構(gòu)的一大看點，帶cache的架構(gòu)清晰如下：

哪里需要cache？IO越頻繁的地方，越需要cache。數(shù)據(jù)庫是IO訪問最頻繁處，三大核心表是否有必要放入內(nèi)存中？twitter的做法是，將表拆分，將其中訪問最頻繁的字段裝入cache。
（1）vector cache and row cache即數(shù)組cache與行cache
數(shù)組緩存：新發(fā)表消息的msgids，相關(guān)作者的ids，這些id的訪問頻率很高，存放它們的cache稱為vector cache；
行緩存：消息正文的行cache；內(nèi)存有限的情況下，優(yōu)先vector cache，實際結(jié)果vector cache的命中率是99%，row cache為95%；
（2）fragment cache and page cache
訪問twitter的用戶除了網(wǎng)頁（web通道），還有手機（API通道），而后者的比例占總流量的80%-90%。mysql cache之外，cache的重心會在API通道上。手機屏幕的主體，是一屏一屏的消息，不妨把整個頁面分割成若干局部，每個局部對應一些/一條消息，這些就是fragment。人氣高的作者，緩存其頁面的fragment，可以提高讀取其發(fā)布消息效率，這就是fragment cache的使命。人氣旺的作者，人們也會訪問其主頁，這就是page cache的使命。實際結(jié)果，fragment cache的命中率為95%，page cache為40%。雖然page cache的命中率低，但由于是訪問主頁，其占用的空間是很大的，為了防止兩種cache相互影響，這兩種cache需要部署在不同的物理機器上。twitter的fragment cache和page cache都是使用的memcached。
（3）http accelerator加速器
web通道的緩存問題也需要解決，分析之后，web通道的壓力主要來自搜索。面臨突發(fā)事件時，讀者們會搜索相關(guān)信息，而不會理會這些信息的作者是不是自己follow的那些人。為了降低搜索壓力，可以將搜索關(guān)鍵詞與搜索內(nèi)容cache起來。這里，twitter的工程師使用了varnish。有趣的是，varnish通常部署在web server外層，先訪問varnish，其中沒有相關(guān)的內(nèi)容，才訪問web server；twitter的工程師卻將varnish放在apache web server的內(nèi)層，原因是他們認為varnish操作復雜，擔心varnish崩潰造成系統(tǒng)的癱瘓，故采用了這種保守型部署方式。twitter沒有公開varnish的命中率，他們聲稱，使用了varnish之后，整站的負載下降了50%。

五、抗洪需要隔離
twitter架構(gòu)的另一大看點是其消息隊列：隔離用戶的操作，將流量高峰攤平。
餐廳客滿時，對于新來的顧客，雖然不能服務，但不是拒之門外，而是讓他們現(xiàn)在休息廳等待。
用戶訪問twitter時，接待他的是apache web server，而apache不能接待無限多的用戶。2009年1月20日，奧巴馬發(fā)表就職演說，twitter流量猛增，此時如何是好。
面對洪峰，如何保證網(wǎng)站不奔潰？迅速接納，但推遲服務。
apache收到請求，轉(zhuǎn)發(fā)給Mongrel，由Mongrel負責實際處理，apache則騰出手來，迎接下一位用戶。但apache能夠接待的用戶數(shù)總是有限的，它的并發(fā)數(shù)受apache能夠容納的工作進程數(shù)量，這里不細究apache內(nèi)部原理，圖如下：

六、數(shù)據(jù)流與控制流
快速接納，推遲服務，只是緩兵之計，目的是讓用戶不至于收到503（service unavailable）。
真正的抗洪能力，體現(xiàn)在蓄洪與泄洪兩個方面：
（1）twitter有龐大的memcached集群，能大容量蓄洪；
（2）twitter自己的kestrel消息隊列，作為引流泄洪手段，傳遞控制指令（引流和渠道）；洪峰到達時，twitter控制數(shù)據(jù)流，將數(shù)據(jù)及時疏散到多個機器，避免壓力集中，造成系統(tǒng)癱瘓。
下面舉例說明twitter內(nèi)部流程，假設有兩個作者，通過瀏覽器發(fā)消息，一個讀者也通過瀏覽器閱讀他們的消息。

（1）登陸apache web server，apache分配一個工作進程為其服務，登陸，查id，寫cookie等；
（2）上傳新寫的消息，把作者id，消息等轉(zhuǎn)發(fā)給Mongrel，apache等待Mongrel回復，以便更新作者主頁，將新寫的消息更新上去；
（3）Mongrel收到消息后，分配一個msgid，將msgid與作者id等緩存到vector memcached上去；同時，Mongrel讓vector memcached查找作者被哪些人follow，緩存如果沒有命中會去后端mysql查找，并入cache；讀者ids會返回給Mongrel，Mongrel把msgid與短信正文緩存至row memcached；
（4）Mongrel通知kestrel消息隊列服務器，每個作者及讀者都有一個隊列（沒有則創(chuàng)建）；Mongrel將msgid放入讀者的隊列，以及作者本人的隊列；
（5）某一臺Mongrel，它可能正在處理某一個id的隊列，就會往返回該id用戶的主頁上添加上此條信息；（6）Mongrel將更新后作者的主頁給前端等待著的apache，apache則返回瀏覽器。

七、洪峰與云計算
不細說了，洪峰扛不住時，只能加機器。機器哪里來？租云計算平臺公司的設備。當然，設備只需要在洪峰時租用，省錢呀。

八、push與pull的折衷
可以看到，Mongrel的工作流程：
（1）將相關(guān)ids放入vector memcached和row memecached就算消息發(fā)布成功，而不負責mysql數(shù)據(jù)庫的存入；
（2）將相關(guān)msgid放入kestrel消息隊列就算消息推送成功；Mongrel沒有使用任何方式去通知作者、讀者，讓他們重新拉取消息。
上述工作方式，反映了twitter架構(gòu)設計分拆的理念：
（1）將一個完整的流程分拆成獨立工作的子流程，一個工作可以由各個服務負責（三層架構(gòu)本身是一種分拆）；
（2）多機器之間協(xié)作，細化數(shù)據(jù)流與控制流，并強調(diào)其分離；
twitter業(yè)務流程的分隔，是一種事件驅(qū)動式的設計，主要體現(xiàn)在兩個方面：
（1）Mongrel與mysql的分離，前者不直接插手mysql的操作，而委托memcached全權(quán)負責；
（2）上傳、下載邏輯分離：只通過kestrel隊列來傳遞指令；
每時每刻都有用戶在Twitter上發(fā)表內(nèi)容，Twitter工作是規(guī)劃如何組織內(nèi)容并把它發(fā)送用戶的粉絲。
實時是真正的挑戰(zhàn)，5秒內(nèi)將消息呈現(xiàn)給粉絲是現(xiàn)階段的目標。
投遞意味著內(nèi)容、投入互聯(lián)網(wǎng)，然后盡可能快的發(fā)送接收。
投遞將歷時數(shù)據(jù)放入存儲棧，推送通知，觸發(fā)電子郵件，iOS、黑莓及Android手機都能被通知到，還有短信。
Twitter是世界上活躍中最大的信息發(fā)送機。
推薦是內(nèi)容產(chǎn)生并快速傳播的巨大動力。
兩種主要的時間軸：用戶的及主頁的。
用戶的時間軸特定用戶發(fā)送的內(nèi)容。
主頁時間表是一段時間內(nèi)所有你關(guān)注用戶發(fā)布的內(nèi)容。
線上規(guī)則是這樣的：@別人是若被@的人你未關(guān)注的話將被隔離出來，回復一個轉(zhuǎn)發(fā)可以被過濾掉。
這樣在Twitter對系統(tǒng)是個挑戰(zhàn)。
1.Pull模式
有針對性的時間軸。像twitter.com主頁和home_timeline的API。你請求它才會得到數(shù)據(jù)。拉請求的不少：通過REST API請求從Twitter獲取數(shù)據(jù)。
查詢時間軸，搜索的API。查詢并盡可能快的返回所有匹配的推特。
2.Push模式
Twitter運行著一個最大的實時事件系統(tǒng)，出口帶寬22MB/秒。
和Twitter建立一個連接，它將把150毫秒內(nèi)的所有消息推送給你。
幾乎任何時候，Push服務簇上大約有一百萬個連接。
像搜索一樣往出口發(fā)送，所有公共消息都通過這種方式發(fā)送。
不，你搞不定。(實際上處理不了那么多)
用戶流連接。 TweetDeck 和Twitter的Mac版都經(jīng)過這里。登錄的時，Twitter會查看你的社交圖，只會推送那些你關(guān)注的人的消息，重建主頁時間軸，而不是在持久的連接過程中使用同一個時間軸 。
查詢API，Twitter收到持續(xù)查詢時，如果有新的推特發(fā)布并且符合查詢條件，系統(tǒng)才會將這條推特發(fā)給相應的連接。
3.高觀點下的基于Pull（拉取方式）的時間軸：
短消息(Tweet)通過一個寫API傳遞進來。通過負載平衡以及一個TFE(短消息前段)，以及一些其它的沒有被提到的設施。
這是一條非常直接的路徑。完全預先計算主頁的時間軸。所有的業(yè)務邏輯在短消息進入的時候就已經(jīng)被執(zhí)行了。
緊接著扇出（向外發(fā)送短消息）過程開始處理。進來的短消息被放置到大量的Redis集群上面。每個短息下在三個不同的機器上被復制3份。在Twitter 每天有大量的機器故障發(fā)生。
扇出查詢基于Flock的社交圖服務。Flock 維護著關(guān)注和被關(guān)注列表。
Flock 返回一個社交圖給接受者，接著開始遍歷所有存儲在Redis 集群中的時間軸。
Redis 集群擁有若干T的內(nèi)存。
同時連接4K的目的地。
在Redis 中使用原生的鏈表結(jié)構(gòu)。
假設你發(fā)出一條短消息，并且你有20K個粉絲。扇出后臺進程要做的就是在Redis 集群中找出這20K用戶的位置。接著它開始將短消息的ID 注入到所有這些列表中。因此對于每次寫一個短消息，都有跨整個Redis集群的20K次的寫入操作。
存儲的是短消息的ID, 最初短消息的用戶ID, 以及4個字節(jié)，標識這條短消息是重發(fā)還是回復還是其它什么東東。
你的主頁的時間軸駐扎在Redis集群中，有800條記錄長。如果你向后翻很多頁，你將會達到上限。內(nèi)存是限制資源決定你當前的短消息集合可以多長。
每個活躍用戶都存儲在內(nèi)存中，用于降低延遲。
活躍用戶是在最近30天內(nèi)登陸的twitter用戶，這個標準會根據(jù)twitter的緩存的使用情況而改變。
只有你主頁的時間軸會存儲到磁盤上。
如果你在Redis 集群上失敗了，你將會進入一個叫做重新構(gòu)建的流程。
     查新社交圖服務。找出你關(guān)注的人。對每一個人查詢磁盤，將它們放入Redis中。
     MySQL通過Gizzard 處理磁盤存儲，Gizzard 將SQL事務抽象出來，提供了全局復制。
通過復制3次，當一臺機器遇到問題，不需要在每個數(shù)據(jù)中心重新構(gòu)建那臺機器上的時間軸。
如果一條短消息是另外一條的轉(zhuǎn)發(fā)，那么一個指向原始短消息的指針將會存儲下來。
當你查詢你主頁的時間軸時候，時間軸服務將會被查詢。時間軸服務只會找到一臺你的時間軸所在的機器。
     高效的運行3個不同的哈希環(huán)，因為你的時間軸存儲在3個地方。
     它們找到最快的第一個，并且以最快速度返回。
     需要做的妥協(xié)就是，扇出將會花費更多的時間，但是讀取流程很快。大概從冷緩存到瀏覽器有2秒種時間。對于一個API調(diào)用，大概400ms。
因為時間軸只包含短消息ID, 它們必須”合成”這些短消息，找到這些短消息的文本。因為一組ID可以做一個多重獲取，可以并行地從T-bird 中獲取短消息。
Gizmoduck 是用戶服務，Tweetypie 是短消息對象服務。每個服務都有自己的緩存。用戶緩存是一個memcache集群 擁有所有用戶的基礎信息。Tweetypie將大概最近一個半月的短消息存儲在memcache集群中。這些暴露給內(nèi)部的用戶。
在邊界將會有一些讀時過濾。例如，在法國過濾掉納粹內(nèi)容，因此在發(fā)送之前，有讀時內(nèi)容剝離工作。

到此，相信大家對“Twitter服務器的數(shù)據(jù)請求處理的過程有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學習！