主頁 > 知識庫 > 簡要解析Twitter服務(wù)器的數(shù)據(jù)請求處理架構(gòu)

簡要解析Twitter服務(wù)器的數(shù)據(jù)請求處理架構(gòu)

熱門標(biāo)簽:個人家庭地圖標(biāo)注教程 威海語音外呼系統(tǒng)廠家 百度高德騰訊地圖標(biāo)注公司 勝威電話外呼系統(tǒng)密碼 徐州穩(wěn)定外呼系統(tǒng)代理商 七臺河商家地圖標(biāo)注注冊 廣安電銷外呼系統(tǒng) 搜地圖標(biāo)注怎么找店鋪 百度地圖標(biāo)注不能編輯

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

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

三、三層架構(gòu)(three-tier architecture)
網(wǎng)站的架構(gòu)設(shè)計,傳統(tǒng)的做法是三層架構(gòu),所謂“傳統(tǒng)”不意味著“過時”,新潮的技術(shù)不成熟,傳統(tǒng)的路子更穩(wěn)健。
(1)表示層(presentation tier):apache web server,主要任務(wù)是解析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);當(dāng)然,訪問twitter的不僅僅是瀏覽器,可能還有手機(jī),由于可能存在其他協(xié)議,故可能存在其他processor。
邏輯層:當(dāng)用戶發(fā)布消息時,依次執(zhí)行:(1)存消息至msg表;(2)查用戶relation表,找出其followed_ids;(3)獲取followed_ids中用戶的狀態(tài);(4)在線的ids,將消息push進(jìn)一個隊列queue;(5)queue中的msg,更新ids的主頁;這里面要用到隊列,其實現(xiàn)方式有很多種,例如apache mina,twitter團(tuán)隊自己實現(xiàn)了一個kestrel。
數(shù)據(jù)層:twitter的核心是用戶;消息;用戶關(guān)系。圍繞這幾個核心,其核心數(shù)據(jù)的schema設(shè)計:(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)站響應(yīng)速度是影響用戶體驗最明顯的因素,而影響響應(yīng)速度最大的敵人又是磁盤I/O。twitter工程師認(rèn)為,良好體驗的網(wǎng)站平均響應(yīng)時間應(yī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通道),還有手機(jī)(API通道),而后者的比例占總流量的80%-90%。mysql cache之外,cache的重心會在API通道上。手機(jī)屏幕的主體,是一屏一屏的消息,不妨把整個頁面分割成若干局部,每個局部對應(yīng)一些/一條消息,這些就是fragment。人氣高的作者,緩存其頁面的fragment,可以提高讀取其發(fā)布消息效率,這就是fragment cache的使命。人氣旺的作者,人們也會訪問其主頁,這就是page cache的使命。實際結(jié)果,fragment cache的命中率為95%,page cache為40%。雖然page cache的命中率低,但由于是訪問主頁,其占用的空間是很大的,為了防止兩種cache相互影響,這兩種cache需要部署在不同的物理機(jī)器上。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)層,原因是他們認(rèn)為varnish操作復(fù)雜,擔(dān)心varnish崩潰造成系統(tǒng)的癱瘓,故采用了這種保守型部署方式。twitter沒有公開varnish的命中率,他們聲稱,使用了varnish之后,整站的負(fù)載下降了50%。

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

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

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

七、洪峰與云計算
不細(xì)說了,洪峰扛不住時,只能加機(jī)器。機(jī)器哪里來?租云計算平臺公司的設(shè)備。當(dāng)然,設(shè)備只需要在洪峰時租用,省錢呀。

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

標(biāo)簽:三明 云浮 婁底 威海 昭通 滁州 吳忠 臨沂

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《簡要解析Twitter服務(wù)器的數(shù)據(jù)請求處理架構(gòu)》,本文關(guān)鍵詞  簡要,解析,Twitter,服務(wù)器,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《簡要解析Twitter服務(wù)器的數(shù)據(jù)請求處理架構(gòu)》相關(guān)的同類信息!
  • 本頁收集關(guān)于簡要解析Twitter服務(wù)器的數(shù)據(jù)請求處理架構(gòu)的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章