即时通讯IM群聊和单聊中的信息是送还是拉取”？
时间：2020-10-20
1、题词
“用户在线状态的一致性”（单聊至友在线状态、群聊用户在线状态）是IM应用领域正如难化解的一个技能题目，何如精准实时的取得知音、群友的在线状态，是今天将要根究的话题。
2、IM支出干货满山遍野篇章
正文是浩如烟海成文中的第4篇，总目录如下：
《IM音息送达作保机制心想事成(一)：确保在线实时消息的可靠投递》
《IM音尘送达担保单式编制实现(二)：保准离线消息的可靠递送》
《什么样保准IM实时音问的“时序性”与“一致性”？》
《IM单聊和群聊中的在线状态联机本当用“推”还是“拉”？》（白文）
《IM群聊信息这么着复杂，什么样打包票不丢不重？》
《一种Android端IM智能怔忡算法的企划与奋斗以成探索（含样例代码）》
《移步端IM签到时拉取数目哪边作到省流量？》
《通俗易懂：根据集群的移步端IM连片层荷重均衡方案大饱眼福》
《浅谈移动端IM的多点登陆和音问观光原理》
《IM支出基础知识补课(一)：正确理解放权HTTP SSO单点登陆接口的规律》
《IM开支基础知识补课(二)：何等规划大度图籍文牍的服务端收储架构？》
《IM支出基础知识补课(三)：急若流星晓得服务端数据库读写作别公例及履行提议》
《IM开支基础知识补课(四)：正确理解HTTP短连年中的Cookie、Session和Token》
《IM群聊消息的已读回帖效能该怎么兑现？》
《IM群聊音讯究竟是存1份(即扩散读)或者存多份(即扩散写)？》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ音讯序列》
《一个低成本保证IM音信时序的措施推究》
《IM开销基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《IM里“附近的人”效益贯彻常理是哎哟？怎的如梭地奋斗以成它？》
《IM支付基础知识补课(七)：主流活动端账号登录法子的公设及计划性笔触》
《IM支出基础知识补课(八)：史上最通俗，到头搞懂字符乱码问题的真面目》
《IM的扫码登效验何许兑现？一文搞懂主流使唤的扫码登陆技巧法则》
《IM要做无绳电话机扫码登陆？先探访微信的扫码记名效用技巧常理》
《IM开销基础知识补课(九)：想开销IM集群？先搞懂什么是RPC！》
更多群聊技术文章：
《IM群聊消息究竟是存1份(即扩散读)要么存多份(即扩散写)？》
《IM群聊信息的已读回条职能该怎生实现？》
《有关IM即时通讯群聊信息的乱序题材讨论》
《现代IM系统中说闲话消息的一块和储存方案根究》
《举手投足端IM中大规模群信息的推送何等管保频率、实时性？》
《微信后台团体：微信后台异步音信队列的优化递升推行大快朵颐》
《IM群聊信息这一来复杂，怎样管教不丢不重？》
《IM单聊和群聊中的在线状态合伙该当用“推”要么“拉”？》
《何如准保IM实时音尘的“时序性”与“一致性”？》
《高速裂变：见证人微信强大后台架构从0到1的演进进程（一）》
《一套高可用、易舒卷、高面世的IM群聊架设方案设计实施》
另外，如若您是IM支付初学者，强烈建议首先阅读《新手入门一篇就够：从零开销挪动端IM》。
3、保全单聊契友状态的一致性
1气象一：用户uid-A记名时，怎样获取敦睦方方面面稔友的在线状态？
一个卓然的IM敢情的甩卖逻辑是这一来的：
1）服务器要收储有着用户的在线状态（屡次仓储在承保高可用的缓存集群里） -> 承保状态可查，工艺流程见下图：
IM单聊和群聊中的在线状态齐声理合用“推”要么“拉”？_1.jpg
2）用户状态实时更动，别样用户登录时，特需将服务端温馨的在线状态置为online；任何用户刊登时，亟待将服务端阖家欢乐的状态置为offline -> 担保服务端状态存储的一致性与实时性，工艺流程见下图：
IM单聊和群聊中的在线状态一起本该用“推”要么“拉”？_2.jpg
3）uid-A报到时，先去多寡库拉取融洽的至友列表，再去缓存博取富有挚友的在线状态 -> 管教登录时知交状态博取的一致性与实时性，流程见下图：
IM单聊和群聊中的在线状态联机应该用“推”或者“拉”？_3.jpg
2景象二：用户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的在线反向契友（反向好友是指：加了uid-B为挚友的人，而差错uid-B的执友，其一细节要放在心上）。
IM单聊和群聊中的在线状态一路本当用“推”抑或“拉”？_4.jpg
方案二的长项：实时。
方案二的缺陷：当在线至好量很大时，另一个一个用户状态的改动，会扩散成N个实时照会，这个N斥之为“音息狂澜扩散系数”。
设一个im系统平均每个用户有200个反向契友，平均有20%的反向稔友在线，那么音问狂澜扩散系数N=40，这代表，其余一个状态的浮动会化为40个推送呼吁。
4、保持群聊友状态的一致性
1万象一：群友状态一致性有好家伙不同，和至好状态一致性对照复杂在哪里？为什么无从用到实时推送？
理论上群友状态也何尝不可由此实时推送的办法兑现，以包管实时性。但实际上，群友状态似的都是应用拉取的办法获取，因为群友状态“音息风暴扩散系数”N实质上太大，通栏实时博得体系再三收受高潮迭起。
倘使平均每个用户加了20个群，平均每个群有200个用户，援例一经20%的用户在线，这就是说为着保管群友状态的实时性，每个用户记名，将要将友好的状态改动报信发送给20*200*20%=800个群友，N=800，表示，其他一个状态的成形会变成800个推送呼吁。
XXX体系用到的是群友状态推送，不设有的这么的题材？那很或是是，XXX系统的用户量和活跃度还不够高吧。
2此情此景二：轮询拉取群友状态也会给服务器拉动过大的下压力，再有哎哟优化长法？
群友的数据量太大，虽则每个用户平均入伙了20个群，但实则并决不会老是签到都进去每一个群。不役使轮询拉取，而施用按需拉取，延时拉取的方法，在确实跻身一个群时才实时拉取群友的在线状态，是既能满足用户需求（用户感觉是状态是实时、一致的，但实际上是进去群才拉取的），又能稳中有降服务器下压力。这是一种常见解数。
下结论与提议
IM利用中在线状态的实时性与一致性是一个较难解决的技能问题，不同的业务接受度，不同的数据量面世量在线量，实现方式不同。
村办建言献计的方法是：
稔友状态，倘然对实时性渴求较高，足以使役推送的办法一块儿；一经实时性务求不高，足以使唤轮询拉取的方式联机；
群友的状态，出于信息狂飙扩散系数过大，可以施用按需拉取，延时拉取的长法一起；
系统音讯/开屏广告等对实时性渴求不高的事体，足以使唤拉取的措施收获音讯；
“音讯狂风暴雨扩散系数”是指一个音问发出时，改为N个音尘的扩散系数，本条系数与业务及数目痛痒相关，大势所趋品位上它的大小支配了技能用到推送要么拉取。
