feed留，單聊群聊，系統通知，狀態同步，到底是推還是拉？

feed留，單聊群聊，系統通知，狀態同步，到底是推還是拉？

今天拋一個話題，根據業務現象，一起討論其後端實現是推還是拉？

一、feed流

可以理解為一個釋出訂閱業務，典型業務是微博（朋友圈）。你關注了姚晨的微博，姚晨釋出了訊息，你的主頁能看到她最新發布的訊息，這個場景是推送，還是拉取呢？

畫外音：微博是弱關係，關注無需對方同意，粉絲可以無上限；朋友圈是強關係，好友需要對方同意，好友個數有上線。

如果推送，姚晨釋出訊息的時候，要把訊息ID投遞到所有粉絲的主頁訊息佇列裡，推送量巨大。

如果拉取，一來主頁訊息無法實時更新，二來每次重新整理動作非常複雜：

1. 拉取你關注人的list<user_id>

2. 拉取這些人的訊息list<msg_id>

3. 對於這些人的這些訊息進行rank處理，例如按照時間排序

4. 還無法對主頁進行快取，因為只要有關注人釋出訊息，主頁內容就會變化

5. 還得考慮“不看誰的訊息”，以及“訊息不給誰看”

6. ...

是不是覺得有點煩？如果你是架構師，你會怎麼做？

二、聊天訊息

聊天訊息又分為單聊和群聊，典型的業務是微信。和朋友小窗溝通是單聊，群內扯淡是群聊。

單聊，很容易想到是伺服器推送，但瀏覽器裡的聊天工具JS只能使用http式的request - response協議，又能不能保證訊息的實時性呢？

群聊，一個群500個人，有人線上，有人離線，到底是推送，還是拉取呢？

如果是推送，1條訊息將轉變為500條訊息，系統壓力會異常之大。

如果是拉取，訊息的實時性又該如何保障呢？

還有一個坑爹的需求，“釘釘”的群聊天訊息“已讀回執”，這個需求簡單描述是：對於每一條你發出的每一群訊息，你能夠看到，多少人已讀，多少人未讀。這個群訊息已讀回執，猜猜看，又是怎麼實現的呢？

三、系統通知

系統訊息聽上去比較泛，典型的業務是QQ的登入廣告彈窗，以及登入後的右下角廣告提示。

• QQ每天首次登入後的新聞彈窗

拉取？第二次登入卻又沒有。

• QQ執行過程中的QQ彈窗廣告

推送？一次推送幾千萬條，會不會系統抖動？

或許，真實的實現方式或許與我們想的並不一樣。

四、狀態同步

玩桌面QQ時，收到過“你的好友XXOO登入了”的彈窗提示麼？這是一個好友登入/登出狀態的客戶端同步。同理，群有500人，每個群友的線上/不線上狀態又是怎麼實現同步的呢？

推送？那一個使用者登入退出都要推送N個好友？M個群友？

拉取？如何保證好友狀態，群友狀態的實時性？

畫外音：好友/群友狀態一致性是非常複雜的，移動的時代，索性引入“一律線上”的概念，微信的好友就不存在所謂“頭像亮”和“頭像灰”的概念了，客戶端狀態同步這一塊複雜性有所降低。

看到產品功能，思考後面的技術實現，其實是很有意思的一件事。

究竟是推，還是拉？大夥怎麼看。

還有其他業務場景的疑惑，也歡迎評論提問，有價值的問題，5月份逐條解答。

畫外音：自從有了群訊息已讀回執，我再也不能裝作不線上，領導的訊息沒看到了。