有童鞋問我說，聽說QQ狀態同步過于復雜，微信的架構師搞不定，才取消了“在線”的概念，是這樣嗎？

微信“在線”的產品設計理念我不知道，做了幾十年IM，可以和大家聊聊在線狀態同步相關的架構設計。

QQ在線狀態同步分兩大類：

• 好友狀態的同步；
• 群友狀態的同步；

這兩類狀態同步的需求各異，前者需要實時同步，后者能夠容忍延時。

任何脫離業務的架構設計都是耍流氓，這兩類場景的狀態同步，究竟是推送還是拉取呢？

用戶的在線狀態，分為：

• 客戶端狀態(端，顯示狀態)；
• 服務端狀態(云，真實狀態)；

兩種形態。

什么是服務端狀態？

服務端狀態，在線online和離線offline兩種，這是用戶的真實在線狀態。不同的狀態，對于不同的業務處理流程可能不同。

例如，對于消息的處理：

• 服務端狀態在線，直接投遞給用戶；
• 服務端狀態離線，則存儲離線消息，等用戶下一次登錄拉取；

如何實時更新服務端狀態？

用戶uid-A登錄時，會修改用戶的服務端狀態為在線。

用戶uid-A登出時，會修改用戶的服務端狀態為離線。

經常的，服務端會將用戶的服務端狀態存儲在高可用的緩存集群里。

什么是客戶端狀態？

對好友，群友顯示的在線狀態，例如隱身、離線、忙碌、勿擾等，是客戶端狀態，這些狀態是產品功能需求。我們所說的“用戶狀態同步”，都是指的客戶端狀態。

為了方便介紹，假設客戶端狀態也只有online和offline兩種狀態，與服務端狀態一致，后文統一稱為“用戶狀態”。

如何獲取好友的狀態？

uid-A登錄時，先去數據庫拉取自己的好友列表，再去緩存獲取所有好友的狀態。

用戶uid-A的好友uid-B狀態改變時（由登錄、登出等動作觸發），uid-A如何同步這一事件？

情況一：如果對于狀態變更實時性要求不高，可以采用拉取。

uid-A向服務器輪詢拉取uid-B（其實是自己的全部好友）的狀態，例如每1分鐘一次，其缺點是：

• 如果uid-B的狀態改變，uid-A獲取不實時，可能有1分鐘時延；
• 如果uid-B的狀態不改變，uid-A會有大量無效的輪詢請求，非常低效；

情況二：如果對于狀態變更實時性要求較高，則必須推送。

uid-B狀態改變時（由登錄、登出等動作觸發），服務端不僅要在緩存中修改uid-B的狀態，還要將這個狀態改變的通知推送給uid-B的在線好友。

推送的優勢是：實時。

缺點是：當在線好友量很大時，任何一個用戶狀態的改變，會擴散成N個實時通知，這個N叫做“消息風暴擴散系數”。

假設一個IM系統平均每個用戶有200個好友，平均有20%的好友在線，那么消息風暴擴散系數N=40，這意味著，任何一個狀態的變化會變成40個推送請求。

群友狀態的一致性，和好友狀態的一致性相比，復雜在哪里？可不可以采用實時推送？

群業務場景大伙也非常熟悉，你能夠加入若干群(例如20個)，假設平均每個群有200人，即你會有4000個群友。依然假設20%的用戶在線，那么為了保證群友狀態的實時性，每個用戶登錄，就要將自己的狀態改變通知發送給20*200*20%=800個群友，N=800，意味著，任何一個狀態的變化會變成800個推送請求。

如果說好友狀態實時推送，消息風暴擴散系數N=40尚可以接受，那么群友狀態實時推送，N=800則是災難性的。此類業務往往采用輪詢拉取的方式，獲得群友的狀態。

輪詢拉取群友狀態也會給服務器帶來過大的壓力，還有什么優化方式？

群友的數據量太大，雖然每個用戶平均加入了20個群，但實際上并不會每次登錄都進入每一個群。

不采用輪詢拉取，而采用按需拉取，延時拉取的方式，在真正進入一個群時才實時拉取群友的在線狀態，是既能滿足用戶需求（用戶感覺是狀態是實時、一致的，但其實是進入群才拉取的），又能降低服務器壓力。這是一種常見方法。

總結

狀態的實時性與一致性是一個較難解決的技術問題，一般來說：

• 好友狀態同步，是采用推送的方式同步；
• 群友狀態同步，由于消息風暴擴散系數過大，一般采用拉取的方式同步；
• 群友狀態同步，還能采用按需拉取的優化方式，進一步降低服務端壓力；
• “消息風暴擴散系數”是指一個消息發出時，變成N個消息的擴散系數，這個系數一定程度上決定了技術采用推送還是拉取；

知道為什么，一個群最多500人了吧？

知其然，知其所以然。

思路比結論更重要。