## 前言 一款app，消息頁面有：錢包通知、最近訪客等各種通知類別，每個類別可能有新的通知消息，實現已讀、未讀功能，包括多少個未讀，這個是怎麼實現的呢？比如用戶A訪問了用戶B的主頁，難道用rabitmq給B發通知消息嗎？量大了成本受得了嗎？有沒有成本低的方案呢 
小談
挺好的一個問題，可惜其他的回答要麼是大而化之想當然，要麼是顧左而言他，沒有一個正經的回答。
這個是很常見的需求，在做這類需求的時候，首先要做的是，設計一個合適的業務模型，那麼這個模型就是“對話模型”，
將問題中的"設置"，“賺錢積分”,"最近聽眾","好友跟新"，"最近來訪"當做一個“虛擬人”來處理，你跟"虛擬人"組成了一個"對話列表(msg_group)"
“虛擬人”與正常人的區別就是，虛擬人與你的對話是單向的，只能他向你發消息，你無法回覆。
所有，判斷有沒有小紅點，或者小紅點的數字是多少，就是簡單的獲取你與虛擬人的對話的未讀的消息的數量。
“最近來訪”標簽
當有人訪問你主頁的時候，後端會以這個“最近來訪”虛擬人的身份給你發一條消息，不過消息里還有一個特殊標記，標明瞭來源。我們除了要拉取總量，還有不同來源消息的數量。當然，一個動作不一定只發一條消息，比如，圖中下方有個金剛鍵"消息"，它是所有消息的總和，所以，投遞其他消息的時候，也要給它投遞一次，不過它只展示一個未讀數字，所以這個消息只需要一個msg_id即可，不需要消息payload。
前端怎麼展示
看具體產品需求。
每個對話可以看作一個msg_group，它是一個消息的隊列(註意，不是我們常說的消息隊列),每條msg的msg_id都是有序遞增的，至於msg_id只是隊列內有序還是全局有序，就看你選擇了,一般數據10億以內沒必要優化，發號器全局有序即可。這個隊列有基本的信息:參與人(圖中的例子只有2個，你和“虛擬人”)，maximal_msg_id。
你只需要保存一個last_pull_msg_id或last_read_msg_id即可，在拉取信息的時候，帶上這個last_msg_id即可。
當然，消息列表的存儲，讀取，就比較多樣了。可以是MySQL，nosql，hbase，redis。一般我們是混合存儲，特別老的存hbase，比較老的存mysq或nosql，新數據存redis。雲廠商也有專門針對這類場景的存儲產品。大多數情況，我們只需要一個數量，固定從maximal_id往前取，如果取到100條還沒完，直接返回99+完事了。
實際上，圖中的需求，比如“設置”，"隱私設置"，是整個產品全局的，所以可以弄個簡單的"廣播消息模式"，廣播模式就是維持一個單向的消息的隊列，所有的人都可以拉取這個隊列的消息，只需要他們各位維護自己的last_id即可。
"已讀和未讀"。它包含兩層意思，一個判否，即內容你是否讀過，二是計數，即這個內容有多少人讀過。
長尾原因
如果你用Redis存儲，成本非常高，浪費非常嚴重。如果不用redis，一旦刷到歷史數據，會非常非常慢。在這裡bitmap肯定是搞不定的，因為bitmao需要載入全部數據，顯然不可行。
這個時候，通常的策略是"[log record]"和"comb", 我們每產生一個動作，比如讀，贊，收藏，就會產生一個log record( 取關，取消贊...也是一條獨立的log record)，我們由專門的大數據系統統一收集這些record，然後對多個維度的數據統計，將統計結果存起來，前端獲取數據的時候，先從緩存取，取不到再到comb取。comb的數據規模是遠遠小於log record的，查詢速度非常快。
log record因為不涉及查詢，所以沒必要用資料庫，一般直接存hbase或cassandra這類廉價存儲介質。
熱門內容
用戶互動非常活躍，所以在寫入log record的時候，會直接同步更新緩存，但是緩存的數據並不保證十分準確，它只是迷惑用戶的，準確的數據是以log record為準的，你在wb經常可以看熱門內容的點贊數跟實際的數量不符。因為wb的緩存，獨立的counter，實際的數據不同步。
本文由博客一文多發平臺 OpenWrite 發佈！
