[TOC] > [參考](https://www.w3cschool.cn/architectroad/architectroad-qq-status-consistency.html) ## 好友狀態一致性 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個推送請求。 群友的數據量太大，雖然每個用戶平均加入了20個群，但實際上并不會每次登錄都進入每一個群。**不采用輪詢拉取，而采用按需拉取，延時拉取**的方式，在真正進入一個群時才實時拉取群友的在線狀態，是既能滿足用戶需求（用戶感覺是狀態是實時、一致的，但其實是進入群才拉取的），又能降低服務器壓力。這是一種常見方法 ## 總結與建議 狀態的實時性與一致性是一個較難解決的技術問題，不同的業務接受度，不同的數據量并發量在線量，實現方式不同，個人建議的方式是： （1）好友狀態，如果對實時性要求較高，可以采用推送的方式同步；如果實時性要求不高，可以采用輪詢拉取的方式同步 （2）群友的狀態，由于消息風暴擴散系數過大，可以采用按需拉取，延時拉取的方式同步 （3）系統消息/開屏廣告等對實時性要求不高的業務，可以采用拉取的方式獲取消息 （4）“消息風暴擴散系數”是指一個消息發出時，變成N個消息的擴散系數，這個系數與業務及數據相關，一定程度上它的大小決定了技術采用推送還是拉取