新浪架構(gòu)師談微博架構(gòu)文章

微博平臺(tái)首席架構(gòu)師楊衛(wèi)華演講新浪科技訊11月16日下午消息，由新浪微博()±辦的中國首屆微博開發(fā)者大會(huì)在北京舉行，這是國內(nèi)微博行業(yè)的首場技術(shù)盛宴。作為國內(nèi)微博市場的絕對領(lǐng)軍者，新浪微博將在此次大會(huì)上公布一系列針對開發(fā)者的扶持政策，以期與第三方開發(fā)者聯(lián)手推動(dòng)微博行業(yè)的整體發(fā)展。視頻：中國首屆微博開發(fā)者大會(huì)楊衛(wèi)華演講媒體來源：新浪科技以下為演講實(shí)錄：大家下午好，在座的大部分都是技術(shù)開發(fā)者，技術(shù)開發(fā)者往往對微博這個(gè)產(chǎn)品非常關(guān)心。最晚的一次，是12點(diǎn)多收到一個(gè)郵件說想了解一下微博底層是怎么構(gòu)架的。很多技術(shù)人員對微博的構(gòu)架非常感興趣，就是一個(gè)明星他有300萬粉絲，這個(gè)技術(shù)怎么來實(shí)現(xiàn)？今天在這里跟大家分享一下微博的底層機(jī)構(gòu)，讓大家對微博的底層技術(shù)有更好的了解。另外不管是做客戶端、Web1.0、Web2.0、論壇、博客都要考慮架構(gòu)的問題，架構(gòu)實(shí)際上是有一些共性的。今天我通過講解微博里面的一些架構(gòu)，分析一下架構(gòu)里面哪些共性大家可以參考。首先給大家介紹一下微博架構(gòu)發(fā)展的歷程。新浪微博在短短一年時(shí)間內(nèi)從零發(fā)展到五千萬用戶，我們的基層架構(gòu)也發(fā)展了3個(gè)大的版本。第一版就LAMP架構(gòu)，優(yōu)點(diǎn)是可以非?？斓膶?shí)現(xiàn)我們的系統(tǒng)。我們看一下技術(shù)特點(diǎn)，微博這個(gè)產(chǎn)品從架構(gòu)上來分析，它需要解決的是發(fā)表和訂閱的問題。我們第一版采用的是推消息模式，假如說我們一個(gè)明星用戶他有10萬個(gè)粉絲，那就是說用戶發(fā)表一條微博的時(shí)候，我們把這個(gè)微博消息存成10萬份，這樣就是很簡單了，第一版的架構(gòu)實(shí)際上就是這兩行字。第一版的技術(shù)細(xì)節(jié)，典型的LAMP架構(gòu)，是使用MyISAM搜索引擎，它的優(yōu)點(diǎn)就是速度非常快。另外一個(gè)是MPSS，就是多個(gè)端口可以布置在同一服務(wù)器上。為什么使用MPSS？假如說我們做一個(gè)互聯(lián)網(wǎng)應(yīng)用，這個(gè)應(yīng)用里面有三個(gè)單元，我們可以由2種部署方式。我們可以把三個(gè)單元分別部署在三臺(tái)服務(wù)器上，另外一種部署模式就是這三個(gè)單元部署在每個(gè)服務(wù)器上都有。我推薦第2種方法。這個(gè)方法解決了兩個(gè)問題，一個(gè)是負(fù)載均衡，因?yàn)槊恳粋€(gè)單元都有多個(gè)節(jié)點(diǎn)處理，另外一個(gè)是可以防止單點(diǎn)故障。如果我們按照模式1來做的話，任何一個(gè)節(jié)點(diǎn)有故障就會(huì)影響我們系統(tǒng)服務(wù)，如果模式二的話，任何一個(gè)結(jié)點(diǎn)發(fā)生故障我們的整體都不會(huì)受到影響的。我們微博第一版上線之后，用戶非常喜歡這個(gè)產(chǎn)品，用戶數(shù)增長非常迅速。我們技術(shù)上碰到幾個(gè)問題。第一個(gè)問題是發(fā)表會(huì)出現(xiàn)延遲現(xiàn)象，尤其是明星用戶他的粉絲多系統(tǒng)需要處理很長時(shí)間。另外系統(tǒng)在處理明星用戶發(fā)表時(shí)系統(tǒng)繁忙可能會(huì)影響到其他的用戶，因?yàn)槠渌挠脩敉粫r(shí)間發(fā)表的話，也會(huì)受到這個(gè)系統(tǒng)的影響。我們就考慮這個(gè)系統(tǒng)怎么改進(jìn)。首先是推模式，這肯定是延遲的首要原因，我們要把這個(gè)問題解決掉。其次我們的用戶越來越多，這個(gè)數(shù)據(jù)庫表從一百萬到一億，數(shù)據(jù)規(guī)模不一樣處理方式是有差別的。我們第一版單庫單表的模式，當(dāng)用戶數(shù)量增多的時(shí)候，它不能滿足就需要進(jìn)行拆分。第二個(gè)是鎖表的問題，我們考慮的是更改引擎。另外一個(gè)是發(fā)表過慢，我們考慮的是異步模式。第二版我們進(jìn)行了模塊化，我們首先做了一個(gè)分層，最底層叫基礎(chǔ)層，首先對數(shù)據(jù)做了拆分，圖上最右邊是發(fā)表做了異步模式。第二個(gè)服務(wù)層，我們把微博基礎(chǔ)的單元設(shè)計(jì)成服務(wù)層一個(gè)一個(gè)模塊，最大改進(jìn)是對推模式進(jìn)行了改進(jìn)。首先看一下投遞模式的優(yōu)化，首先我們要思考推模式，如果我們做一下改進(jìn)把用戶分成有效和無效的用戶。我們一個(gè)用戶比如說有一百個(gè)粉絲，我發(fā)一條微博的時(shí)候不需要推給一百個(gè)粉絲，因?yàn)榭赡苡?0個(gè)粉絲不會(huì)馬上來看，這樣同步推送給他們，相當(dāng)于做無用功。我們把用戶分成有效和無效之后，我們把他們做一下區(qū)分，比如說當(dāng)天登陸過的人我們分成有效用戶的話，只需要發(fā)送給當(dāng)天登陸過的粉絲，這樣壓力馬上就減輕了，另外投遞的延遲也減小了。我們再看數(shù)據(jù)的拆分，數(shù)據(jù)拆分有很多方式，很多互聯(lián)網(wǎng)產(chǎn)品最常用的方法，比如說如可以按照用戶的UID來拆分。但是微博用戶的一個(gè)特點(diǎn)就是說大家訪問的都是最近的數(shù)據(jù)，所以我們考慮微博的數(shù)據(jù)我們按照時(shí)間拆分，比如說一個(gè)月放一張表，這樣就解決了我們不同時(shí)間的維度可以有不同的拆分方式。第二個(gè)考慮就是要把內(nèi)容和索引分開存放。假如說一條微博發(fā)表的uid,微博id是索引數(shù)據(jù)，140個(gè)字的內(nèi)容是內(nèi)容數(shù)據(jù)。假如我們分開的話，內(nèi)容就簡單的變成了一種keyvalue的方式，key-value是最容易擴(kuò)展的一種數(shù)據(jù)。索引數(shù)據(jù)的拆分具有挑戰(zhàn)，比如說一個(gè)用戶發(fā)表了一千條微博，這一千條微博我們接口前端要分頁訪問，比如說用戶需要訪問第五頁，那我們需要迅速定位到這個(gè)記錄。假如說我們把這個(gè)索引拆分成一個(gè)月一張表，我們記錄上很難判斷第五頁在哪張表里，我們需要加載所有的索引表。如果這個(gè)地方不能拆分，那我們系統(tǒng)上就會(huì)有一個(gè)非常大的瓶頸。最后我們想了一個(gè)方法，就是索引上做了一個(gè)二次索引，把每個(gè)月記錄的偏移記下來，就是一個(gè)月這個(gè)用戶發(fā)表了多少條，ID是哪里，就是按照這些數(shù)據(jù)迅速把記錄找出來。異步處理，發(fā)表是一個(gè)非常繁重的操作，它要入庫、統(tǒng)計(jì)索引、進(jìn)入后臺(tái)，如果我們要把所有的索引都做完用戶需要前端等待很長的時(shí)間，如果有一個(gè)環(huán)節(jié)失敗的話，用戶得到的提示是發(fā)表失敗，但是入庫已經(jīng)成功，這樣會(huì)帶來數(shù)據(jù)不一致問題。所以我們做了一個(gè)異步操作，就是發(fā)表成功我們就提示成功，然后在后臺(tái)慢慢的消息隊(duì)列慢慢的做完。另外新浪發(fā)表了一個(gè)很重要的產(chǎn)品叫做MemcacheQ，我們?nèi)ツ曜隽艘粋€(gè)對大規(guī)模部署非常有利的指令，就是statsqueue，適合大規(guī)模運(yùn)維。第二版我們做了這些改進(jìn)之后，微博的用戶和訪問量并沒有停止，還有很多新的問題出現(xiàn)。比如說系統(tǒng)問題，單點(diǎn)故障導(dǎo)致的雪崩，第二個(gè)是訪問速度問題因?yàn)閲鴥?nèi)網(wǎng)絡(luò)環(huán)境復(fù)雜，會(huì)有用戶反映說在不同地區(qū)訪問圖片、js這些速度會(huì)有問題。另外一個(gè)是數(shù)據(jù)壓力以及峰值，MySql復(fù)制延遲、慢查詢，另外就是熱門事件，比如說世界杯，可能會(huì)導(dǎo)致用戶每秒發(fā)表的內(nèi)容達(dá)到幾千條。我們考慮如何改進(jìn)，首先系統(tǒng)方面允許任意模塊失敗。另外靜態(tài)內(nèi)容，第一步我們用CDN來加速，另外數(shù)據(jù)的壓力以及峰值，我們需要將數(shù)據(jù)、功能、部署盡可能的拆分，然后提前進(jìn)行容量規(guī)劃。另一方面我們還有平臺(tái)化的需求，去年11月我們就說要做開放平臺(tái)，開放平臺(tái)的需求是有差異的，Web系統(tǒng)它有用戶行為才有請求，但是API系統(tǒng)特別是客戶端的應(yīng)用，只要用戶一開機(jī)就會(huì)有請求，直到他關(guān)閉電腦這種請求一直會(huì)不間斷的過來，另外用戶行為很難預(yù)測。系統(tǒng)規(guī)模在持續(xù)的增大，另外也有平臺(tái)化的需求，我們新架構(gòu)應(yīng)該怎么做才能滿足這些需要？我們看一下同行，比如說Google怎么樣考慮這個(gè)問題的？Google首席科學(xué)家講過一句話，就是一個(gè)大的復(fù)雜的系統(tǒng)，應(yīng)該要分解成很多小的服務(wù)。比如說我們在G執(zhí)行一個(gè)搜索查詢的話，實(shí)際上這個(gè)操作會(huì)調(diào)動(dòng)內(nèi)部一百多個(gè)服務(wù)。因此，我們第三版的考慮就是先有服務(wù)才有接口最后才有應(yīng)用，我們才能把這個(gè)系統(tǒng)做大。現(xiàn)在我們看一下第三版，首先我們把底層的東西分成基礎(chǔ)服務(wù)，基礎(chǔ)服務(wù)里面有分布式的存儲(chǔ)，我們做了一些去中心化、自動(dòng)化的操作。在基礎(chǔ)服務(wù)之上有平臺(tái)服務(wù)，我們把微博常用的應(yīng)用做成各種小的服務(wù)。然后我們還有應(yīng)用服務(wù)，這個(gè)是專門考慮平臺(tái)各種應(yīng)用的需求。最上面我們有API，API就是新浪微博各種第三方應(yīng)用都在上面跑。平臺(tái)服務(wù)和應(yīng)用服務(wù)是分開的，這樣實(shí)現(xiàn)了模塊隔離，即使應(yīng)用服務(wù)訪問量過大的話，平臺(tái)服務(wù)不會(huì)首先影響。另外我們把微博的引擎進(jìn)行了改進(jìn)，實(shí)現(xiàn)了一個(gè)分層關(guān)系。用戶的關(guān)注關(guān)系，我們改成一個(gè)多惟度的索引結(jié)構(gòu)，性能極大的提高。第四個(gè)層面就是計(jì)數(shù)器的改進(jìn)，新版我們改成了基于偏移的思路，就是一個(gè)用戶他原來讀的一個(gè)ID比如說是10000，系統(tǒng)最系的ID是10002的話，我們很清楚他有兩條未讀。原來的版本是采用絕對計(jì)數(shù)的，這個(gè)用戶有幾條未讀都是用一個(gè)存儲(chǔ)結(jié)構(gòu)的話，就容易產(chǎn)生一致性的問題，采用這種偏移的技術(shù)基本上不會(huì)出錯(cuò)。另外基礎(chǔ)服務(wù)DB冷熱分離多維度拆分，在微博里面我們是按照時(shí)間拆分的，但是一個(gè)大型的系統(tǒng)里面有很多業(yè)務(wù)需要有不同的考慮。比如說私信這個(gè)就不能按照時(shí)間來拆分，這個(gè)按照UID來拆分可能更簡單。然后我們突出存儲(chǔ)還做了一個(gè)去中心化，就是用戶上傳圖片的速度會(huì)極大的提高，另外察看其他用戶的圖片速度也會(huì)極大的提高。另外是動(dòng)態(tài)內(nèi)容支持多IDC同時(shí)更新，這個(gè)是在國內(nèi)比較新穎的。下面給大家介紹一下新浪微博怎么樣打造一個(gè)高性能架構(gòu)。到目前為止有五千萬用戶使用新浪微博，最高發(fā)表3000條以上每秒，然后一個(gè)明星用戶發(fā)表的話，會(huì)被幾百萬用戶同時(shí)讀到。這些問題的本質(zhì)是我們架構(gòu)需要考慮高訪問量、海量數(shù)據(jù)的情況下三個(gè)問題。易于擴(kuò)展、低延遲、高可用和異地分布。我們每天有數(shù)十億次外部網(wǎng)頁以及API接口的需求，我們知道微博的特點(diǎn)是用戶請求是無法cache的。因此面對這個(gè)需求我們怎么樣擴(kuò)展？幾點(diǎn)思路。第一我們的模塊設(shè)計(jì)上要去狀態(tài)，我們?nèi)我庖粋€(gè)單元可以支持任意節(jié)點(diǎn)。另外是去中心化，避免單點(diǎn)及瓶頸。另外是可線性擴(kuò)展。最后一個(gè)是減少模塊。我們要做一個(gè)高性能的系統(tǒng)，要具備一個(gè)低延遲、高實(shí)時(shí)性，微博要做到高實(shí)時(shí)性這是核心的價(jià)值，實(shí)時(shí)性的核心就是讓數(shù)據(jù)離CPU最近，避免磁盤的IO。我們看淘寶核心系統(tǒng)專家余鋒說過的一句話“CPU訪問L1就像從書桌拿一本書，L2是從書架拿一本書，L3是從客廳桌子上拿一本書，訪問主存就像騎車去社區(qū)圖書館拿一書”。我們微博如果要做到非常實(shí)時(shí)的話，我們就需要把數(shù)據(jù)盡量離CPU節(jié)點(diǎn)最近。所以我們看一下cache設(shè)計(jì)里面怎么達(dá)到這個(gè)目標(biāo)。首先INBOX，這個(gè)數(shù)據(jù)我們需要放再一個(gè)最快的地方，因?yàn)橛脩綦S時(shí)訪問。OutBOX里面的最近發(fā)表就是Llcache,還有一個(gè)是中期的，這個(gè)因?yàn)樵L問少一點(diǎn)，它可以被踢。最后一部分內(nèi)容體有三部分。L0是本地的，我們需要把一些經(jīng)常訪問的，比如說明星發(fā)表微博的內(nèi)容體本地化，因?yàn)樗辉L問的概率非常大。然后L1里面存放著最近發(fā)表的，還有一個(gè)是中期的。我們通常用L2就可以了，L1我們可以理解成它就是一個(gè)RAM存儲(chǔ)。一個(gè)好的架構(gòu)還需要舉行高可用性。我們看一下業(yè)界的指標(biāo)，S3是99.9%，EC2是99.5%，我們另外一個(gè)同行Facebook在這方面它是沒有承諾的，就是接口可用寫。微博平臺(tái)目前承諾的是99.95%，就是說一天365天故障率應(yīng)該小于9小時(shí)。這個(gè)怎么達(dá)到？第一我們要做容量規(guī)劃，要做好監(jiān)控以及入口的管理，就是說有些服務(wù)如果訪問量過了的話，我們要有一個(gè)開關(guān)可以攔住他。我們通過這個(gè)圖表可以清楚的看到，比如說我們要做L1的cache，我們剩余空間有多少，比如說80%，就說明這個(gè)數(shù)據(jù)有可能會(huì)丟失，有可能會(huì)對我們的系統(tǒng)造成影響。另外一個(gè)層面就是接口監(jiān)控，我們目前有Google維度的接口監(jiān)控，包括訪問錯(cuò)誤失敗率。然后要做架構(gòu)，給大家一個(gè)很重要的經(jīng)驗(yàn)分享，就是說監(jiān)控的指標(biāo)盡量量化。比如說他延遲30秒是小問題，如果是延遲10分鐘我們就要立即采取措施了，就是所有可以量化的指標(biāo)都要量化。然后我們看監(jiān)控怎么樣更好的做？我們看亞馬遜的VP說過的一句話，就是說監(jiān)控系統(tǒng)確實(shí)特別好，可以立即告訴我們哪里有故障，但是有20%的概率我們?nèi)耸菚?huì)出錯(cuò)的。所以我們一個(gè)大型系統(tǒng)就應(yīng)該要為自動(dòng)化設(shè)計(jì)，就是說盡可能的將一些運(yùn)作自動(dòng)化。比如說發(fā)布安裝、服務(wù)、啟用、停止。我們再看另外一句，Google的工程師是怎么做的。他是這么做的，比如說第一周是處理線上的業(yè)務(wù)，這一周他處理了很多事情，處理了很多系統(tǒng)的情況，剩下幾周時(shí)間沒有別的工作，他只要把這一周碰到的情況用程序的方法來解決，下次再碰到這種情況很簡單的一個(gè)按鈕就可以處理了。我們目前也在向自動(dòng)化這方面努力，就是我們的工具在持續(xù)增加。另外一個(gè)異地分布，在國內(nèi)網(wǎng)絡(luò)環(huán)境下，比如說IDC災(zāi)難，機(jī)房檢修甚至是機(jī)房掉電，我們也碰到過中國最好的機(jī)房也會(huì)掉電，所以要每個(gè)服務(wù)單元都能支持多機(jī)房部署。另外做多機(jī)房部署有一個(gè)好處，就是用戶的訪問速度會(huì)提高。多IDC分布靜態(tài)內(nèi)容就不說了，基本上大的互聯(lián)網(wǎng)公司都會(huì)做，它非常成熟基本上沒有什么問題，比如說圖片等等的靜態(tài)內(nèi)容。動(dòng)態(tài)內(nèi)容的CDN分布是業(yè)內(nèi)的難點(diǎn)，國內(nèi)很少有公司能夠做到非常成熟的多機(jī)房動(dòng)態(tài)內(nèi)容發(fā)布的成熟方案，它的核心就是分布式存儲(chǔ)。一款理想的分布式存儲(chǔ)產(chǎn)品它有哪些需求呢？首先它要支持海量規(guī)模、可擴(kuò)展、高性能、低延遲、高可用。第二個(gè)是需要多機(jī)房分布，能夠滿足國內(nèi)負(fù)責(zé)的網(wǎng)絡(luò)環(huán)境，還要具備異地容災(zāi)能力。第三個(gè)就是要調(diào)用簡單，具備豐富數(shù)據(jù)庫特性。因此分布式存儲(chǔ)需要解決一個(gè)多對多的數(shù)據(jù)復(fù)制。如果要做復(fù)制無非是三種策略，第一個(gè)是Master/Slave，但是它也兩個(gè)缺點(diǎn)，第一個(gè)是Master是中心化的，如果Master在北京那廣州訪問就非常慢。第二個(gè)缺點(diǎn)是有單點(diǎn)風(fēng)險(xiǎn)的，比如說Master在北京，能立即遷到廣州嗎？這樣有個(gè)時(shí)間窗口的數(shù)據(jù)就丟失了，而且需要人工的干預(yù)，而且日常廣州的用戶訪問北京的Master是有很大延遲問題的，所以一般來說要做的非常優(yōu)秀是不會(huì)考慮第一種方案的。第二種就是Multi-Master方案，它需要應(yīng)用避免沖突，就是我們不能多處改變。這個(gè)對于微博來說不會(huì)特別難，我們的用戶通常只會(huì)再一個(gè)地方發(fā)表微博，用戶不會(huì)同時(shí)在廣州又在北京發(fā)表或者是修改自己的資料，這樣的話我們應(yīng)用上就已經(jīng)避免了這種情況。第三個(gè)就是Paxos就是可以達(dá)到強(qiáng)一致寫，就是一條數(shù)據(jù)如果成功肯定是多個(gè)機(jī)房都成功了，這個(gè)也顯而易見就是延遲性非常大。因此總結(jié)一下Multi-Master是最成熟的策略，但是它現(xiàn)在沒有成熟的產(chǎn)品，因?yàn)榇_實(shí)沒有。我們再來看微博的方案，所以我們自己實(shí)現(xiàn)了一個(gè)多機(jī)房同步的方案。就是我們前端應(yīng)用將數(shù)據(jù)寫到數(shù)據(jù)庫，再通過一個(gè)消息代理，相當(dāng)于通過我們自己開發(fā)的一個(gè)技術(shù)，將數(shù)據(jù)廣播到多個(gè)機(jī)房。這個(gè)不但可以做到兩個(gè)機(jī)房，而且可以做到三個(gè)、四個(gè)。具體的方式就是通過消息廣播方式將數(shù)據(jù)多點(diǎn)分布，就是說我們的數(shù)據(jù)提交給一個(gè)代理，這個(gè)代理幫我們把這些數(shù)據(jù)同步到多個(gè)機(jī)房，那我們應(yīng)用不需要關(guān)心這個(gè)數(shù)據(jù)是怎么樣同步過去的。用這種消息代理方式有什么好處呢？可以看一下Yahoo是怎么來做的？第一個(gè)是數(shù)據(jù)提供之后沒有寫到db之后是不會(huì)消失的，我只要把數(shù)據(jù)提交成功就可以了，不需要關(guān)心數(shù)據(jù)怎么到達(dá)機(jī)房。第二個(gè)特點(diǎn)YMB是一款消息代理的產(chǎn)品，但是它唯一神奇的地方是為廣域網(wǎng)設(shè)計(jì)的，它可以把多機(jī)房應(yīng)用歸到內(nèi)部，我們應(yīng)用不需要關(guān)注這個(gè)問題。這個(gè)原理跟我們目前自己開發(fā)的技術(shù)相似。然后我們再看一下目前即將推出的微博平臺(tái)的新架構(gòu)。我們知道API大部分的請求都為了獲取最新的數(shù)據(jù)。API請求有一個(gè)特點(diǎn)，它大目前調(diào)用都是空返回的，比如說一款手機(jī)的客戶端每隔一分鐘它都要調(diào)用服務(wù)器一下，就是有沒有新數(shù)據(jù)，大目前的調(diào)用都是空返回，就是說不管服務(wù)器有沒有數(shù)據(jù)都要調(diào)用一次。這次詢問到下一次詢問中間，如果有新的數(shù)據(jù)來了，你是不會(huì)馬上知道的。因此我們想API能不能改用推的方式，就是客戶端不需要持續(xù)的調(diào)用，如果有新數(shù)據(jù)就會(huì)推過去。技術(shù)特點(diǎn)，顯而易見低延遲，就是從發(fā)表到接受1秒內(nèi)完成，實(shí)際上可能用不了1秒。然后服務(wù)端的連接就是高并發(fā)長連接服務(wù)，就是多點(diǎn)都連接在我們的服務(wù)器上，這個(gè)比傳統(tǒng)的API要大很多。我們看一下推送架構(gòu)怎么從架構(gòu)底層做到實(shí)時(shí)性的。從左上角的一條微博在我們系統(tǒng)發(fā)布之后，我們把它放在一個(gè)消息隊(duì)列里面，然后會(huì)有一個(gè)消息隊(duì)列的處理程序把它拿過來，處理以后放到db里面。假如說我們不做持久化，因?yàn)槲覀兺扑蛿?shù)據(jù)也不能丟失，我們就要寫一個(gè)很復(fù)雜的程序，將數(shù)據(jù)異步去存，這樣就會(huì)非常復(fù)雜，而且系統(tǒng)也會(huì)有不穩(wěn)定的因素。從另外一個(gè)角度來說，我們做持久化也是做過測試的。我們推送整個(gè)流程可以做到100毫秒和200毫秒之間，就是說我們在這個(gè)時(shí)間能把數(shù)據(jù)推送出去。我們再看一下內(nèi)部細(xì)節(jié)，就是我們收到數(shù)據(jù)之后首先要經(jīng)過最上面RECEIVER。然后推到我們的引擎里面，這個(gè)引擎會(huì)做兩個(gè)事情，首先會(huì)把用戶的關(guān)系拿過來，然后按照用戶關(guān)系馬上推送給他相應(yīng)的粉絲。所以我們調(diào)用方已經(jīng)在那兒等待了，我們需要有一個(gè)喚醒操作，就是說在接口這兒把它喚醒，然后把它發(fā)送過去。最后是一個(gè)高并發(fā)的長連服務(wù)器，就是一臺(tái)服務(wù)器支持10萬以上的并發(fā)連接。最右邊中間有一個(gè)圓圈叫做StreamBuffer，我們需要StreamBuffer是要保存用戶最近的數(shù)據(jù)。因?yàn)橛脩艨赡軙?huì)有斷線的，比如說他發(fā)送數(shù)據(jù)的時(shí)候斷線半分鐘，我們需要把這