微博feed系統(tǒng)的push和pull模式和時(shí)間分區(qū)拉模式架構(gòu)探討

微博feed系統(tǒng)的push和pull模式和時(shí)間分區(qū)拉模式架構(gòu)探討

摘要:sns系統(tǒng)，微博系統(tǒng)都應(yīng)用到了feed（每條微博或者sns里的新鮮事等我們稱作feed）系統(tǒng)，不管是或者國內(nèi)的新浪微博，人人網(wǎng)等，在各種技術(shù)社區(qū)，技術(shù)大會上都在分享自己的feed架構(gòu)，也就是推拉模式（timyang上次也分享了新浪微薄的模...

全球唯一顯示溫度純鋼鈦戒指

360度超炫液晶，老外狂訂

3E^恒溫電熱鞋

sns系統(tǒng)，微博系統(tǒng)都應(yīng)用到了feed（每條微博或者sns里的新鮮事等我們稱作feed）系統(tǒng)，不管是或者國內(nèi)的新浪微博，人人網(wǎng)等，在各種技術(shù)社區(qū)，技術(shù)大會上都在分享自己的feed架構(gòu)，也就是推拉模式（timyang上次也分享了新浪微薄的模式）。下面我們就微博的feed推拉（push,pull）模式做一下探討，并提出新的時(shí)間分區(qū)拉模式。

眾所周知，在微博中，當(dāng)你發(fā)表一篇微博，那么所有關(guān)注你的followers（粉絲）都會在一定的時(shí)間內(nèi)收到你的微薄，這有點(diǎn)像群發(fā)一封郵件，所有的抄送者都會在一定的時(shí)間內(nèi)收到。到這里，你可能覺得沒有什么難度。我們看下下面的截圖：

測試版

新浪微博

?國m

545%主2594751.攔絲2085

姚晨。新浪認(rèn)證

演員.《港伏》m翠萍蝕滴者

圖一：新浪微博姚晨

NameFenng

Location

3O.209214J20L19&216

Web

/

Bio做技示的，-說起來，也B個=^AdWorkatDXY.cnasCTO(aka,打雜的)，EvangelistDatabaseGeekWeb2.0WebArchUnixOpenSourceAlipayOW)JobsDiggTwitter.

2,525 19,869856

Allowingrollowerslisted

Fenng

Following畫 Lists-叫/

Also:ollov/?dby@freevpnin；'D,?isllei,(^houzhyu,and1C-others

圖二：twitter上馮大輝

新浪微博的姚晨粉絲有2594751,她發(fā)表任何一篇微博，都需要2594751個粉絲在一定的時(shí)間內(nèi)收到，twitter的馮大輝發(fā)表一篇的話，需要19868個followers收到。

相反，姚晨需要收到他關(guān)注的545個人的所有更新，馮大輝需要收到他關(guān)注的2525個人的所有更新。到這里，你是不是感覺到有那么一點(diǎn)點(diǎn)小挑戰(zhàn)呢？

下面我們看下微博一般的整體結(jié)構(gòu)圖：

用戶 用戶 用戶

用戶 用戶

圖三：微博整體結(jié)構(gòu)

圖中展示了微博的整體數(shù)據(jù)流程，先了解下整體的數(shù)據(jù)結(jié)構(gòu)，沒有涉及到followers等的推拉模式處理。下面我們再看下推模式（push）：

feeds

球d

followersuid

timeline

其他字段（字段盡可能

feeds

Ed

follov^/ersuid

timeline

其他字段（字段盡可能

feeds

球d

folloversuid

timeline

其他字段（字段盡可能

但已出與堵（=ha.rding）,美佶.非件的inbox

圖四：推模式結(jié)構(gòu)推模式需要把一篇微博推送給所有關(guān)注他的人（推給所有的粉絲），比如姚晨，我們就需要推送給2594751個用戶的feeds表中。當(dāng)然，feeds表可以很好的進(jìn)行sharding，存儲也都是一些數(shù)字型的字段，存儲空間可能不是很大，用戶在查詢自己關(guān)注的所有人的feed時(shí)，速度快，性能非常高，但是推送量會非常大，姚晨發(fā)表一篇，就會產(chǎn)生200多萬條數(shù)據(jù)。試想，一個大量用戶的微薄系統(tǒng)通過使用推模式，是不是會產(chǎn)生非常驚人的數(shù)據(jù)呢？

下面看下拉模式（pull）

memcached

feedswhereuidin

Ed

-^rWauthoruid

timwline（食表時(shí)間）

箴導(dǎo)id（唯一通:臆瑁實(shí)彼內(nèi)容

key(uidlist)

value({

datalastquerydatatimelinezlastqu&rytime

SELECTidFROM

[follevyinguidlist)ANDtimeline>(lastquerytime；/'feeds查

圖五：拉模式拉模式只需要用戶發(fā)表微博時(shí)，存儲一條微博數(shù)據(jù)到feeds表中（feeds表可以是一個臨時(shí)表，只保存近期可接受范圍的數(shù)據(jù)）.用戶每次查詢feed時(shí)都會去查詢feeds表。比如姚晨打開自己的微薄首頁，就產(chǎn)生：SELECTidFROMfeedswhereuidin（followinguidlist）ORDERBYidDESCLIMITn（查詢最新的n條），緩存到memcacheduidlist=＞（data:idlist,timeline:上次查詢出來的最新的一條數(shù)據(jù)的時(shí)間｝

再次刷新：SELECTidFROMfeedswhereuidin（followinguidlist）ANDtimeline＞（memcached存儲的上次的timeline）ORDERBYidDESCLIMITn

這種模式實(shí)現(xiàn)起來也是比較簡單和容易的，只是在查詢的時(shí)候需要多考慮下緩存的結(jié)構(gòu)。但是feeds表會產(chǎn)生很大的壓力，怎么說feeds表也要保存最近十天半個月的數(shù)據(jù)吧，對于一個大點(diǎn)的系統(tǒng)，這會產(chǎn)生比較大的數(shù)據(jù)，如果following的人數(shù)比較多，數(shù)據(jù)庫的壓力就會非常大。而且一般在線的用戶，客戶端都會定期掃描，又會增加很大的壓力，這在查詢性能上沒有推模式的效率高。

下面我們在對拉模式做一下改進(jìn)優(yōu)化

memeached

feeds（Sin：時(shí)|司的〕

微■虐authoruid

timeline陵表時(shí)間）

feeds（近期的）

成?d

微■虐authoruid

timeline陵表時(shí)間）

涵實(shí)體內(nèi)容

timeline梭表時(shí)間］

key(uidlist)

valued

datazlastquerydatatimeline:lastquerytime

feeds(比較長時(shí)期)

Slid

微埔authoruid

SELECTid-ROMfeeds

whereuidin(fedIowinguidlist)ANDtimeline>(lastquerytime)//feeds

11IJi7c

查詢(根據(jù)上次的

querytim日輯定要查詞的

圖五：拉模式（pull）-改進(jìn)（時(shí)間分區(qū)拉模式）

拉模式的改進(jìn)主要是在feeds的存儲上，使用按照時(shí)間進(jìn)行分區(qū)存儲。分為最近時(shí)間段（比如最近一個小時(shí)），近期的，比較長時(shí)期等等。我們再來看下查詢的流程，比如姚晨登陸微博首頁，假設(shè)緩存中沒有任何數(shù)據(jù)，那么我們可以查詢比較長時(shí)期的feeds表，然后進(jìn)入緩存。下一次查詢，通過查詢緩存中的數(shù)據(jù)的timeline，如果timeline還在最近一個小時(shí)內(nèi)，那么只需要查詢最近一個小時(shí)的數(shù)據(jù)的feed表，最近一個小時(shí)的feeds表比圖四的feeds表可要小很多，查詢起來速度肯定快幾個數(shù)量級了。

改進(jìn)模式的重點(diǎn)在于feeds的時(shí)間分區(qū)存儲，根據(jù)上次查詢的timeline來決定查詢應(yīng)該落在那個表。一般情況下，經(jīng)常在線的用戶，頻繁使用的客戶端掃描操作，經(jīng)常登錄的用戶，都會落在最近的feeds表區(qū)間，查詢都是比較高效的。只有那些十天，半個月才登錄一次的用戶需要去查詢比較長時(shí)間的feeds大表，一旦查詢過了，就又會落在最近時(shí)間區(qū)域，所以效率也是非常高的。

關(guān)于時(shí)間的分區(qū)，需要根據(jù)數(shù)據(jù)量，用戶訪問特點(diǎn)進(jìn)行一個合理的切分。如果數(shù)據(jù)發(fā)表量非常大，可以進(jìn)行更多的分區(qū)