什么是feed流?什么是讀擴(kuò)散?什么是寫擴(kuò)散?

任何脫離業(yè)務(wù)的架構(gòu)設(shè)計(jì)都是耍流氓，今天和大家聊聊這幾個(gè)話題。

哪些產(chǎn)品是feed流典型業(yè)務(wù)?

微博，微信朋友圈，Pinterest是典型的feed流業(yè)務(wù)，系統(tǒng)中的每一條消息就是一個(gè)feed。

這類業(yè)務(wù)有什么特點(diǎn)?

(1)有好友關(guān)系，例如關(guān)注，粉絲;

(2)我們的主頁(yè)由別人發(fā)布的feed組成。

這類業(yè)務(wù)的核心業(yè)務(wù)動(dòng)作是什么?

(1)關(guān)注，取關(guān);

(2)發(fā)布feed;

(3)拉取自己的主頁(yè)feed流。

這類業(yè)務(wù)的核心元數(shù)據(jù)是什么?

(1)關(guān)系數(shù)據(jù);

(2)feed數(shù)據(jù)。

feed流的“拉取”與“推送”實(shí)現(xiàn)，是個(gè)怎么回事?

feed流業(yè)務(wù)最大的特點(diǎn)是“我們的主頁(yè)由別人發(fā)布的feed組成”，獲得朋友圈消息feed流集合，從技術(shù)上說(shuō)，主要有：

(1)拉取(讀擴(kuò)散);

(2)推送(寫擴(kuò)散)。

兩種方式。feed流的推與拉主要指的是這里。

什么是拉模式 ，讀擴(kuò)散方案?

例如，某feed系統(tǒng)里有ABCD四個(gè)用戶，其中：

(1)A關(guān)注了BC，D關(guān)注了B;

其關(guān)系存儲(chǔ)又包含關(guān)注關(guān)系與粉絲關(guān)系，“A關(guān)注了BC，D關(guān)注了B”的潛臺(tái)詞是“B有兩個(gè)粉絲AD，C有一個(gè)粉絲A”。

(2)B發(fā)布過(guò)四條feed：msg1, msg3, msg5, msg10;

(3)C發(fā)布過(guò)兩條feed：msg2, msg8;

每一個(gè)用戶，都有一個(gè)feed隊(duì)列，記錄自己曾經(jīng)發(fā)布的所有feed數(shù)據(jù)。

拉模式讀擴(kuò)散如何實(shí)現(xiàn)feed發(fā)布?

在拉模式中，發(fā)布一條feed的流程非常簡(jiǎn)單，例如C新發(fā)布了一條msg12：

此時(shí)只需往C的feed隊(duì)列里加入一條feed即可。

拉模式讀擴(kuò)散如何實(shí)現(xiàn)關(guān)注/取關(guān)?

在拉模式中，取消關(guān)注的流程也非常簡(jiǎn)單，例如A取消關(guān)注C：

此時(shí)只需要在A的關(guān)注列表里刪除C，并在C的粉絲列表里刪除A即可。

拉模式讀擴(kuò)散如何實(shí)現(xiàn)個(gè)人主頁(yè)feed流?

在拉模式中，用戶A獲取“由別人發(fā)布的feed組成的主頁(yè)”的過(guò)程及其復(fù)雜，此時(shí)需要：

(1)獲取A的關(guān)注列表;

(2)獲取所關(guān)注列表中，所有用戶發(fā)布的feed;

(3)對(duì)消息進(jìn)行rank排序(假設(shè)按照發(fā)布時(shí)間排序)，分頁(yè)取出對(duì)應(yīng)的一頁(yè)feeds。

拉模式讀擴(kuò)散有什么優(yōu)點(diǎn)?

(1)存儲(chǔ)結(jié)構(gòu)簡(jiǎn)單，數(shù)據(jù)存儲(chǔ)量較小，關(guān)系數(shù)據(jù)與feed數(shù)據(jù)都只存一份;

(2)關(guān)注，取關(guān)，發(fā)布feed的業(yè)務(wù)流程非常簡(jiǎn)單;

(3)存儲(chǔ)結(jié)構(gòu)，業(yè)務(wù)流程都比較容易理解，適合項(xiàng)目早期用戶量、數(shù)據(jù)量、并發(fā)量不大時(shí)的快速實(shí)現(xiàn)。

拉模式讀擴(kuò)散有什么缺點(diǎn)?

(1)拉取朋友圈feed流列表的業(yè)務(wù)流程非常復(fù)雜;

(2)有多次數(shù)據(jù)訪問(wèn)，并且要進(jìn)行大量的內(nèi)存計(jì)算，網(wǎng)絡(luò)傳輸，性能較低。

什么是推模式 ，寫擴(kuò)散方案?

推模式(寫擴(kuò)散)，關(guān)系數(shù)據(jù)的存儲(chǔ)與拉模式(讀擴(kuò)散)完全一樣。

feed數(shù)據(jù)，每個(gè)用戶也存儲(chǔ)自己發(fā)布的feed。

如上圖：

(1)B曾經(jīng)發(fā)布過(guò)1，3，5，10;

(2)C曾經(jīng)發(fā)布過(guò)2，8。

畫外音：不妨設(shè)，這里的msgid按照f(shuō)eed的發(fā)布時(shí)間偏序。

feed數(shù)據(jù)存儲(chǔ)，與拉(讀擴(kuò)散)不同的是，每個(gè)用戶還需要存儲(chǔ)自己收到的feed流。

如上圖：

(1)A關(guān)注了BC，所以A的接收隊(duì)列是1，2，3，5，8，10;

(2)D關(guān)注了B，所以D的接受隊(duì)列是1，3，5，10。

推模式寫擴(kuò)散如何實(shí)現(xiàn)個(gè)人主頁(yè)feed流?

在推模式(寫擴(kuò)散)中，獲取“由別人發(fā)布的feed組成的主頁(yè)”會(huì)變得異常簡(jiǎn)單，假設(shè)一頁(yè)消息為3條feed，A如果要看自己朋友圈的第二頁(yè)消息，直接返回1，2，3即可。

畫外音：第一頁(yè)朋友圈是最新的消息，即5，8，10。

推模式寫擴(kuò)散如何實(shí)現(xiàn)feed發(fā)布?

在推模式(寫擴(kuò)散)中，發(fā)布一條feed的流程會(huì)更復(fù)雜一點(diǎn)。

例如B新發(fā)布了一條msg12：

(1)在B的發(fā)布feed存儲(chǔ)里加入消息12;

(2)查詢B全部粉絲AD;

(3)在粉絲AD的接收f(shuō)eed存儲(chǔ)里也加入消息12。

之所以該方案稱為推模式(寫擴(kuò)散)，就是因?yàn)?，用戶發(fā)布feed的時(shí)候：

(1)直接將feed推到了粉絲的接收列表里，故稱為“推模式”;

(2)不止寫發(fā)布feed存儲(chǔ)，而且要寫多個(gè)粉絲的接收f(shuō)eed存儲(chǔ)，故稱為“寫擴(kuò)散”。

推模式寫擴(kuò)散如何實(shí)現(xiàn)關(guān)注/取關(guān)?

在推模式(寫擴(kuò)散)中，添加關(guān)注的流程也會(huì)變得復(fù)雜。

例如D新增關(guān)注C：

(1)在D的關(guān)注存儲(chǔ)里添加C;

(2)在C的粉絲存儲(chǔ)里添加D;

(3)在D的接收f(shuō)eed存儲(chǔ)里加入C發(fā)布的feed。

畫外音：有些產(chǎn)品有這樣的邏輯，“關(guān)注之后才能看到feed”，這樣的話就不需要第三步，舊feed無(wú)需插入。

在推模式(寫擴(kuò)散)中，取消關(guān)注的流程也會(huì)變得復(fù)雜。

例如A取消關(guān)注C：

(1)在A的關(guān)注存儲(chǔ)里刪除C;

(2)在C的粉絲存儲(chǔ)里刪除A;

(3)在A的接收f(shuō)eed存儲(chǔ)里刪除C發(fā)布的feed。

推模式寫擴(kuò)散有什么優(yōu)點(diǎn)?

(1)消除了拉模式(讀擴(kuò)散)的IO集中點(diǎn)，每個(gè)用戶都讀自己的數(shù)據(jù)，高并發(fā)下鎖競(jìng)爭(zhēng)少;

畫外音：拉模式(讀擴(kuò)散)中，用戶發(fā)布feed存儲(chǔ)容易成為IO瓶頸。

(2)拉取朋友圈feed流列表的業(yè)務(wù)流程異常簡(jiǎn)單，速度很快;

(3)拉取朋友圈feed流列表，不需要進(jìn)行大量的內(nèi)存計(jì)算，網(wǎng)絡(luò)傳輸，性能很高。

畫外音：feed業(yè)務(wù)是典型的讀多寫少業(yè)務(wù)場(chǎng)景，讀寫比甚至高于100：1，即平均發(fā)布1條消息，有至少100次閱讀。

推模式寫擴(kuò)散有什么缺點(diǎn)?

(1)極大極大消耗存儲(chǔ)資源，feed數(shù)據(jù)會(huì)存儲(chǔ)很多份，例如楊冪5KW粉絲，她每次一發(fā)博文，消息會(huì)冗余5KW份;

畫外音：有朋友提出，可以存儲(chǔ)一份消息實(shí)體，只冗余msgid，這樣的話，拉取feed流列表時(shí)，還要再次拉取實(shí)體，網(wǎng)絡(luò)時(shí)延會(huì)更長(zhǎng)，所以很多公司選擇直接冗余消息實(shí)體，當(dāng)然，這是一個(gè)用戶體驗(yàn)與存儲(chǔ)量的折衷設(shè)計(jì)。

(2)新增關(guān)注，取消關(guān)注，發(fā)布feed的業(yè)務(wù)流會(huì)更復(fù)雜。

小結(jié)

feed流業(yè)務(wù)的推拉模式：

(1)拉模式，讀擴(kuò)散，feed存一份，存儲(chǔ)小，用戶集中訪問(wèn)數(shù)據(jù)，性能差;

(2)推模式，寫擴(kuò)散，feed存多份，用冗余存儲(chǔ)換鎖沖突，性能高;

推拉結(jié)合的方式是否可行?又該如何優(yōu)化呢?

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文