關於維護用戶狀態的一致性

           IM的業界標杆確定是QQ了。（貌似如今微信也算另外一種標杆？）

           沒有在騰訊工做過，也沒有看過相關的源碼，因此好奇它（們） 是怎樣解決IM常見的一些技術難題的。

 

           今天咱們來反思下如何維護狀態的一致性比較妥。

 

            用戶的狀態粗略來看，只有在線和離線，之前的qq引入了離開與隱身的狀態（如今也有，我說的「之前」的意思是qq有點老了。。）。

            不管怎麼樣，在各個客戶端，必須實時性的保持狀態的一致，否則用戶確定會吐槽，甚至想罵人（你有事要找A，看到了他離線的狀態，實際上他在的。。）。

           

            那麼最容易想到的方法登陸時拉取所有，以後狀態改變後，由服務器來推送。

           

 

          這裏的難點在於過程3，中文表述的部分，可貴沒法用英語表達了。。。

          有些好友關係是雙方的，還好一點，只要取用戶A的好友列表就行了，再推送給在線的用戶。

          不然，就要尋找全部包含A爲好友的列表（QQ裏面的陌生人，微信的假好友[你已經不在對方的好友列表了。。]）,工做量加大不少。

          好，如今假設你已經找到了。假設好友200個，在線20%，那麼推送係數爲200*20%=40左右（也叫「消息風暴擴散係數」）。

          嗯，不錯，任何一我的狀態的一點改變，服務器就要*消息風暴擴散係數倍的推送。這裏只是拋磚引玉，引發你們對狀態推送擴散的思考。

 

          那除了推，還有別的辦法嗎？固然有了，任何的C/S架構的交互都有push/pull 方法。

          設計一個定時器去拉的話，缺點在於

          1）、實時性下降。

          2）、有多是白拉，浪費帶寬和服務器的運算（狀態沒變啊）

          

          哈哈，說了半天，啥也幹不了。因此叫反思嘛，又沒說解決。

 

         好的，接下來咱們看看羣聊的狀況。

         假定A有20個羣，每一個羣200人，在線率20%，那麼消息風暴擴散係數=20*200*20%=800，這個意味着每次狀態的變動致使800次

         的推送，不是1對1的兩倍，是20倍，強烈不建議這樣作。除非你的系統級別真的很小。

         定時拉，仍然有實時性和白拉的問題。

 

         能夠延遲拉！用的時候拉。羣和好友不一樣的地方在於，在不展開羣的時候，用戶是不關心羣友的狀態的。

         因此咱們能夠用戶打開羣聊的時候再刷新一遍狀態，大大得下降了流量和資源。