自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

讀擴散,寫擴散,終于講清楚了!

開發(fā) 開發(fā)工具
什么是feed流?什么是讀擴散?什么是寫擴散?任何脫離業(yè)務的架構(gòu)設(shè)計都是耍流氓,今天和大家聊聊這幾個話題。

什么是feed流?什么是讀擴散?什么是寫擴散?

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

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

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

這類業(yè)務有什么特點?

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

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

這類業(yè)務的核心業(yè)務動作是什么?

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

(2)發(fā)布feed;

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

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

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

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

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

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

(1)拉取(讀擴散);

(2)推送(寫擴散)。

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

什么是拉模式 ,讀擴散方案?

例如,某feed系統(tǒng)里有ABCD四個用戶,其中:

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

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

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

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

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

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

在拉模式中,發(fā)布一條feed的流程非常簡單,例如C新發(fā)布了一條msg12:

此時只需往C的feed隊列里加入一條feed即可。

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

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

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

拉模式讀擴散如何實現(xiàn)個人主頁feed流?

在拉模式中,用戶A獲取“由別人發(fā)布的feed組成的主頁”的過程及其復雜,此時需要:

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

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

(3)對消息進行rank排序(假設(shè)按照發(fā)布時間排序),分頁取出對應的一頁feeds。

拉模式讀擴散有什么優(yōu)點?

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

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

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

拉模式讀擴散有什么缺點?

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

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

什么是推模式 ,寫擴散方案?

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

feed數(shù)據(jù),每個用戶也存儲自己發(fā)布的feed。

如上圖:

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

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

畫外音:不妨設(shè),這里的msgid按照feed的發(fā)布時間偏序。

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

如上圖:

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

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

推模式寫擴散如何實現(xiàn)個人主頁feed流?

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

畫外音:第一頁朋友圈是最新的消息,即5,8,10。

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

在推模式(寫擴散)中,發(fā)布一條feed的流程會更復雜一點。

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

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

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

(3)在粉絲AD的接收feed存儲里也加入消息12。

之所以該方案稱為推模式(寫擴散),就是因為,用戶發(fā)布feed的時候:

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

(2)不止寫發(fā)布feed存儲,而且要寫多個粉絲的接收feed存儲,故稱為“寫擴散”。

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

在推模式(寫擴散)中,添加關(guān)注的流程也會變得復雜。

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

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

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

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

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

在推模式(寫擴散)中,取消關(guān)注的流程也會變得復雜。

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

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

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

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

推模式寫擴散有什么優(yōu)點?

(1)消除了拉模式(讀擴散)的IO集中點,每個用戶都讀自己的數(shù)據(jù),高并發(fā)下鎖競爭少;

畫外音:拉模式(讀擴散)中,用戶發(fā)布feed存儲容易成為IO瓶頸。

(2)拉取朋友圈feed流列表的業(yè)務流程異常簡單,速度很快;

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

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

推模式寫擴散有什么缺點?

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

畫外音:有朋友提出,可以存儲一份消息實體,只冗余msgid,這樣的話,拉取feed流列表時,還要再次拉取實體,網(wǎng)絡時延會更長,所以很多公司選擇直接冗余消息實體,當然,這是一個用戶體驗與存儲量的折衷設(shè)計。

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

小結(jié)

feed流業(yè)務的推拉模式:

(1)拉模式,讀擴散,feed存一份,存儲小,用戶集中訪問數(shù)據(jù),性能差;

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

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

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

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

 

責任編輯:趙寧寧 來源: 51CTO專欄
相關(guān)推薦

2020-07-29 09:21:34

Docker集群部署隔離環(huán)境

2021-07-05 22:22:24

協(xié)議MQTT

2019-07-07 08:18:10

MySQL索引數(shù)據(jù)庫

2024-04-01 10:09:23

AutowiredSpring容器

2020-12-24 15:18:27

大數(shù)據(jù)數(shù)據(jù)分析

2021-04-10 10:37:04

OSITCP互聯(lián)網(wǎng)

2023-08-14 11:35:16

流程式轉(zhuǎn)化率數(shù)據(jù)指標

2024-02-23 08:08:21

2024-02-27 14:27:16

2020-10-16 17:20:21

索引MySQL數(shù)據(jù)庫

2021-01-29 10:50:04

數(shù)據(jù)中臺數(shù)據(jù)數(shù)據(jù)管理

2022-07-04 11:27:02

標簽數(shù)據(jù)指標標簽體系

2019-05-22 08:43:45

指令集RISC-V開源

2019-06-19 14:58:38

服務器負載均衡客戶端

2024-07-01 13:45:18

2020-04-23 10:21:57

Linux 網(wǎng)絡編程 數(shù)據(jù)

2021-10-29 11:30:31

補碼二進制反碼

2019-06-20 17:49:51

RPCHTTP協(xié)議

2017-12-17 20:17:23

NoSQLSQL數(shù)據(jù)

2018-08-13 09:20:21

NoSQLSQL數(shù)據(jù)
點贊
收藏

51CTO技術(shù)棧公眾號