陌陌Feed讀後總結

壹頁書發表於2016-05-10
參考:
http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659597071&idx=1&sn=cd8df9f8c52dfbfb54e65adbe19fae27&scene=23&srcid=0509WNSUJdcT5Z2HpGaegBaD#rd

下面是Feed系統的整體架構圖:


資源層主要使用Redis、MongoDB、HBase等NoSQL型別資料庫。
儲存層是內部RPC服務，根據業務場景和儲存特性，組合各種資料庫資源。
業務層呼叫儲存層讀寫資料，實現產品邏輯，直接面向使用者使用。

陌陌初期採用Mongodb,主要看重無模式的特性,儲存JSON方便.

Redis 採用Mod取餘Hash的方式.
通過節點資料複製，快速的翻倍擴容，省去了快取預熱的過程。

原文這部分沒有細說.


假如原來有三個redis例項,並且各自帶了Slave.
通過 id mod 3 取餘,判斷存放位置.

擴容的時候,僅僅需要把slave Readonly去掉,
前端通過 id mod 6 取餘,判斷存放位置即可.然後斷掉Redis 主從複製.
因為 id mod 6 == 0 的情況 必定 id mod 3 == 0

比如 10 mod 3 = 1 ,現在改為 10 mod 6 = 4 正好 落在原來的備機上.

待完成之後,需要清理每個例項上一半冗餘的資料.不過一般設定了過期時間,可以等待他自然過期. 


陌陌朋友圈開始用的是推的方式,後來改成拉取.
我倒是覺得推拉結合,似乎更好.

比如
使用者9066357的朋友有新訊息.
使用時間戳作為Score,內容就是資料庫中記錄的ID
127.0.0.1:6379> zadd 9066357 20160510112200 101
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112201 102
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112203 103
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112204 104
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112205 105
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112206 106
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112207 107
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112208 108
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112209 109
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112210 110
(integer) 1

使用者登入,獲取最近的5個訊息
127.0.0.1:6379> ZRANGE  9066357 -5 -1
1) "106"
2) "107"
3) "108"
4) "109"
5) "110"

然後除了最近的幾個資料,全部刪除.
127.0.0.1:6379> ZREMRANGEBYRANK 9066357 0 -8
(integer) 3
127.0.0.1:6379> ZRANGE 9066357  0 -1
1) "104"
2) "105"
3) "106"
4) "107"
5) "108"
6) "109"
7) "110"

保留指定個數的內容.避免記憶體佔用過大.

如果Redis快取Miss,則查詢資料庫.
遍歷我的好友，找到最近發表過Feed的人
遍歷最近發表過Feed的人，得到id和time
合併到我的timeline

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29254281/viewspace-2096963/，如需轉載，請註明出處，否則將追究法律責任。

相關文章