IM即时通讯技术分享_messaging 技术

IM技术分享

1. 概述

1.1 什么是IM

IM技术（Instant Messaging Technology）即即时通讯技术，主要是可以让用户或设备间实时交流的技术。它打破了时间和地域的限制让用户能够以文字、语音、视频、文件传输等方式进行通讯。

1.2 IM技术的应用场景

• IM技术的应用场景非常广泛，从业务领域主要分为以下几种

  • 1. 聚合型IM：主要有微信和QQ

  • 2.企业级IM：主要用于企业内部员工沟通，比如lark

  • 3. 社交型IM: 主要运用于社交场景，如微博、微信朋友圈

  • 4. 游戏型IM：主要运用于游戏内部，玩家之间的沟通交流

  • 5.行业型IM：主要为特定行业提供不同需求的通讯服务，比如医疗、金融

  • 6.物联网型IM：提供设备与设备间的通讯服务

2.通信领域

2.1发消息流程

1. 用户登陆app后，与服务端建立长链接，用户发送的消息经过接入层的转发，到达IM系统的recieve服务。recieve服务主要做鉴权工作。

2. 消息做完鉴权后会放到mq中，使用mq的好处，第一点是能够对消息削峰填谷、第二点是提高用户体验，消息只需要确保落地到mq就返回成功，减少用户发消息感知的延迟。

3. process会消费mq消息、将消息持久化存储、分发数据，判断用户是否在线，如果在线则使用长链接将消息发送给用户，如果离线则使用离线推送（PNS）的方式将消息推送给用户

2.2消息存储

• 存储方式：消息通常使用KV结构的LSM存储架构，因为LSM系统写性能比B+树要好，且可以基于时间范围读进行优化，同时保障数据的一致性和持久性。

• 存储优化：IM中有高活跃群聊和低活跃群聊，对于高活跃的群聊消息量通常会占所有消息量的80%。导致低活跃消息在SSTable中占比比较低，通常一个群聊的低活跃消息可能会散布在多个SSTable中，在拉取低活跃消息时通常会产生耗时的尖刺和超时问题。所以我们需要将冷热key隔离开来。

2.3读写扩散

 

读扩散

• 什么是读扩散：以会话纬度存储消息，一个会话只存储一份消息（conversation_message），用户需要读取这个会话的消息的时候都从这个conversation_message中读取。

• 优点：消息冗余少、节省内存、入库效率高

• 缺点：容易产生读热点问题，在万人群中，一份消息可能同时被多人拉取。

写扩散

• 什么是写扩散：以用户纬度存储消息，每个用户都存储自己那份消息（user_message）。用户读消息的时候从自己的user_message中读取消息即可。

• 优点：能解决读热点问题，定制化消息（仅个人可见消息）实现简单。

• 缺点：消息冗余，一份消息在万人群中需要写一万份。

混合模式

 

活跃用户

• 消息存储方式：采用写扩散的方式，将会话的消息写入user_message中。每个用户都有独立的user_message

非活跃用户

• 消息存储方式：对于群聊普通消息，存储在conversation_message中，定制化消息（红包领取、已删除消息）存放在user_message中。用户希望获取时，在应用层做聚合后再返回。

优点

• 对写扩散和读扩散取了折中的方式，在万人群的场景下，会有较明显的优势。即能解决读热点问题，又在一定程度上控制了消息的冗余量

缺点

• 方案复杂，实现相对困难。

2.4IM心跳保活

1. 什么是IM心跳保活：在应用层由开发者自定义实现客户端和服务端的心跳功能。

2. 为什么有TCP的KeepAlive还需要心跳保活：1.能够更加及时的发现连接断开和异常情况。一个经典的例子，假如某台服务器因为100%的cpu使用率无法响应业务请求。但是TCP的探针依然确定连接状态。就会形成经典的连接活着，业务方已死的状态。客户端这时最应该做的就是断连后重连其他服务器。

2.5已读消息

暂时无法在飞书文档外展示此内容

• 问题：在超大群的场景下，如果用户都在线，那么每个消息都会产生大量的已读请求，这种已读的请求量的扩散等于（M*N）群成员数量*消息数量。

• 解决方案：将请求进行合并，已读位置是单调递增的，所以我们只需要处理每个用户一个最大已读位置的请求就行了。将请求先落入mq中，一段时间处理一次，每次将可聚合的请求合并成为一个。

2.6消息的推与拉

客户端拉取

• 实现：客户端每隔一段时间便向服务端拉取消息。主要使用于对消息实时性要求不高的场景，比如超大群聊下消息的已读状态。

• 优点：实现简单

• 缺点：实时性无法保障

服务端推送

• 实现：每收到一条新消息，服务端都实时向客户端推送。主要用于实时性要求较高的场景。

• 优点：实时性高

• 缺点：超大消息扩散和消息频率较高的场景下会消耗服务端大量资源

问题讨论：

• 弱网问题：例如边远山区，网络条件较差的情况下，长链接可能会推送失败，会导致推消息不及时或者推失败。这时我们需要使用拉消息进行补偿。

• 客户端处理过慢：针对于较老的客户端机型，如果客户端消息处理跟不上服务端的推送速度，会导致消息堆积。这时我们采用重置的方式，当消息堆积到一定的阈值时，我们直接从最新的一条消息开始推送。

推拉结合

• 背景：针对于既要又要还要的场景，既要保障消息实时性，又要保障消息不丢失，还要减小服务端压力。我们可以采用推拉结合的方式。

• 消息聚合的推拉结合: 对于实时性要求不高的场景，我们采用消息聚合的推拉结合。对于超大直播间的聊天消息，先将一段时间内的消息进行聚合，然后通知客户端拉取。

• 推优先的推拉结合: 对于实时性要求高的场景，我们采用推优先的推拉结合。对于每条消息都尽量实时推送给客户端，客户端采用定时轮询拉查看消息是否有遗漏。

• 优化：针对于超大群聊，我们可以区分活跃成员和不活跃成员。对于活跃群成员采用推优先的方式将消息推给用户，对于非活跃成员，采用消息聚合的方式通知用户。

3.参考

http://www.52im.net/forum.php?mod=viewthread&tid=281&highlight=%D0%C4%CC%F8

https://mp.weixin.qq.com/s/dGQqm4JwlKwAKiKcUtZSqg

https://mp.weixin.qq.com/s/sCHQ58JAnZq_EkmbflTQ4A