feed留，單聊群聊，系統通知，狀態同步，到底是推還是拉？
今天拋一個話題，根據業務現象，一起討論其后端實現是推還是拉?
一、feed流
可以理解為一個發布訂閱業務，典型業務是微博(朋友圈)。你關注了姚晨的微博，姚晨發布了消息，你的主頁能看到她***發布的消息，這個場景是推送，還是拉取呢?
畫外音：微博是弱關系，關注無需對方同意，粉絲可以無上限;朋友圈是強關系，好友需要對方同意，好友個數有上線。
如果推送，姚晨發布消息的時候，要把消息ID投遞到所有粉絲的主頁消息隊列里，推送量巨大。
如果拉取，一來主頁消息無法實時更新，二來每次刷新動作非常復雜：
- 拉取你關注人的list
- 拉取這些人的消息list
- 對于這些人的這些消息進行rank處理，例如按照時間排序
- 還無法對主頁進行緩存，因為只要有關注人發布消息，主頁內容就會變化
- 還得考慮“不看誰的消息”，以及“消息不給誰看”
- ...
是不是覺得有點煩?如果你是架構師，你會怎么做?
二、聊天消息
聊天消息又分為單聊和群聊，典型的業務是微信。和朋友小窗溝通是單聊，群內扯淡是群聊。
- 單聊，很容易想到是服務器推送，但瀏覽器里的聊天工具JS只能使用http式的request - response協議，又能不能保證消息的實時性呢?
- 群聊，一個群500個人，有人在線，有人離線，到底是推送，還是拉取呢?
如果是推送，1條消息將轉變為500條消息，系統壓力會異常之大。
如果是拉取，消息的實時性又該如何保障呢?
還有一個坑爹的需求，“釘釘”的群聊天消息“已讀回執”，這個需求簡單描述是：對于每一條你發出的每一群消息，你能夠看到，多少人已讀，多少人未讀。這個群消息已讀回執，猜猜看，又是怎么實現的呢?
三、系統通知
系統消息聽上去比較泛，典型的業務是QQ的登錄廣告彈窗，以及登錄后的右下角廣告提示。
- QQ每天***登錄后的新聞彈窗：拉取?第二次登錄卻又沒有。
- QQ運行過程中的QQ彈窗廣告：推送?一次推送幾千萬條，會不會系統抖動?
或許，真實的實現方式或許與我們想的并不一樣。
玩桌面QQ時，收到過“你的好友XXOO登錄了”的彈窗提示么?這是一個好友登錄/登出狀態的客戶端同步。同理，群有500人，每個群友的在線/不在線狀態又是怎么實現同步的呢?
推送?那一個用戶登錄退出都要推送N個好友?M個群友?
拉取?如何保證好友狀態，群友狀態的實時性?
畫外音：好友/群友狀態一致性是非常復雜的，移動的時代，索性引入“一律在線”的概念，微信的好友就不存在所謂“頭像亮”和“頭像灰”的概念了，客戶端狀態同步這一塊復雜性有所降低。
看到產品功能，思考后面的技術實現，其實是很有意思的一件事。
究竟是推，還是拉?大伙怎么看。
還有其他業務場景的疑惑，也歡迎評論提問，有價值的問題，5月份逐條解答。
畫外音：自從有了群消息已讀回執，我再也不能裝作不在線，領導的消息沒看到了。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
