IM即时通讯技术分享

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

  • 1
    点赞
  • 27
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值