IM 单聊和群聊中的在线状态同步应该用“推”还是“拉”？
1、前言
“用户在线状态的一致性”（单聊好友在线状态、群聊用户在线状态）是 IM 应用领域比较难解决的一个技术问题，如何精准实时的获得好友、群友的在线状态，是今天将要探讨的话题。
2、IM 开发干货系列文章，欢迎关注网易云信博客
3、保持单聊好友状态的一致性
1 场景一：用户 uid-A 登录时，如何获取自己全部好友的在线状态？
一个典型的 IM 大致的处理逻辑是这样的：
1）服务器要存储所有用户的在线状态（往往存储在保证高可用的缓存集群里） -> 保证状态可查，流程见下图：
2）用户状态实时变更，任何用户登录时，需要将服务端自己的在线状态置为 online；任何用户登出时，需要将服务端自己的状态置为 offline -> 保证服务端状态存储的一致性与实时性，流程见下图：
3）uid-A 登录时，先去数据库拉取自己的好友列表，再去缓存获取所有好友的在线状态 -> 保证登录时好友状态获取的一致性与实时性，流程见下图：
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 的好友，这个细节要注意）。
方案二的优点：实时。方案二的缺点：当在线好友量很大时，任何一个用户状态的改变，会扩散成 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 个消息的扩散系数，这个系数与业务及数据相关，一定程度上它的大小决定了技术采用推送还是拉取。
咨询热线：+86 400-966-9672
邮 箱：info@foreverht.com
WorkPlus 私有化｢数智融合｣移动平台 2020.12.21 加入
WorkPlus 私有化｢数智融合｣移动平台
评论