QQ狀態同步究竟是推還是拉？
前面兩篇講即時通訊核心技術的文章
反饋還可以，故繼續即時通訊這一個系列吧，今天聊聊即時通訊中的“狀態”。
需求緣起
“在線狀態一致性”(好友在線狀態，群友在線狀態)是即時通訊領域較難解決的一個技術問題，如何精準實時的獲得好友、群友的在線狀態，是今天將要探討的話題。
好友狀態一致性
問題一：用戶uid-A登錄時，如何獲取自己全部好友的在線狀態?
回答：
(1)服務器要存儲所有用戶的在線狀態(往往存儲在保證高可用的緩存集群里) -> 保證狀態可查
(2)用戶狀態實時變更，任何用戶登錄時，需要將服務端自己的在線狀態置為online;任何用戶登出時，需要將服務端自己的狀態置為offline -> 保證服務端狀態存儲的一致性與實時性
(3)uid-A登錄時，先去數據庫拉取自己的好友列表，再去緩存獲取所有好友的在線狀態 -> 保證登錄時好友狀態獲取的一致性與實時性
問題二：用戶uid-A的好友uid-B狀態改變時(由登錄、登出、隱身等動作觸發)，uid-A如何知道這一事件?
方案一：uid-A向服務器輪詢拉取uid-B(其實是自己的全部好友)的狀態，例如每1分鐘一次
缺點：
(1)如果uid-B的狀態改變，uid-A獲取不實時，可能有1分鐘時延
(2)如果uid-B的狀態不改變，uid-A會有大量無效的輪詢請求，占用服務器資源
方案二：uid-B狀態改變時(由登錄、登出、隱身等動作觸發)，服務器不僅在緩存中修改uid-B的狀態，還要將這個狀體改變的通知推送給uid-B的在線反向好友(反向好友是指：加了uid-B為好友的人，而不是uid-B的好友，這個細節要注意)
優點：
(1)實時
缺點：
(2)當在線好友量很大時，任何一個用戶狀態的改變，會擴散成N個實時通知，這個N叫做“消息風暴擴散系數”。
假設一個im系統平均每個用戶有200個反向好友，平均有20%的反向好友在線，那么消息風暴擴散系數N=40，這意味著，任何一個狀態的變化會變成40個推送請求。
群友狀態一致性
問題三：群友狀態一致性有什么不同，和好友狀態一致性相比復雜在哪里?為什么不能采用實時推送?
回答：理論上群友狀態也可以通過實時推送的方式實現，以保證實時性。但實際上，群友狀態一般都是采用拉取的方式獲得，因為群友狀態“消息風暴擴散系數”N實在太大，全部實時獲取系統往往承受不了。
假設平均每個用戶加了20個群，平均每個群有200個用戶，依然假設20%的用戶在線，那么為了保證群友狀態的實時性，每個用戶登錄，就要將自己的狀態改變通知發送給20*200*20%=800個群友，N=800，意味著，任何一個狀態的變化會變成800個推送請求。
XXX系統使用的是群友狀態推送，不存在的這樣的問題?那很可能是，XXX系統的用戶量和活躍度還不夠高吧。
問題四：輪詢拉取群友狀態也會給服務器帶來過大的壓力，還有什么優化方式?
回答：群友的數據量太大，雖然每個用戶平均加入了20個群，但實際上并不會每次登錄都進入每一個群。不采用輪詢拉取，而采用按需拉取，延時拉取的方式，在真正進入一個群時才實時拉取群友的在線狀態，是既能滿足用戶需求(用戶感覺是狀態是實時、一致的，但其實是進入群才拉取的)，又能降低服務器壓力。這是一種常見方法。
關于更多按需拉取，延時拉取的討論，可移步《微信為啥這么省流量》。
延伸討論：系統消息/開屏廣告的推送與拉取
問題五：系統消息/開屏廣告一般采用推送還是拉取?
回答：不考慮APP端的push(APP端的push，不需要啟動APP，不依賴client與server之間的TCP長連接)，個人強烈建議系統消息/開屏廣告這類消息采用“拉取”的方式，原因是：
- 這類業務對消息的實時性往往要求不高
- 如果集中推送，“消息風暴擴散系數”過大，容易引發系統抖動;而拉取的方式，可以攤平這個抖動，用戶登錄時均勻的發起請求
- 如果集中推送，往往不在意用戶是否“在線”，往往會造成大量離線垃圾消息;而拉取的方式，保證只有在線的用戶才會收到請求
- …
有不同的建議，歡迎評論討論。
總結與建議
狀態的實時性與一致性是一個較難解決的技術問題，不同的業務接受度，不同的數據量并發量在線量，實現方式不同，個人建議的方式是：
- 好友狀態，如果對實時性要求較高，可以采用推送的方式同步;如果實時性要求不高，可以采用輪詢拉取的方式同步
- 群友的狀態，由于消息風暴擴散系數過大，可以采用按需拉取，延時拉取的方式同步
- 系統消息/開屏廣告等對實時性要求不高的業務，可以采用拉取的方式獲取消息
- “消息風暴擴散系數”是指一個消息發出時，變成N個消息的擴散系數，這個系數與業務及數據相關，一定程度上它的大小決定了技術采用推送還是拉取
文章轉載自微信公眾號“架構師之路“
