浅析百万消息量小规模IM即时通讯系统技术

Posted wecloud1314

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了浅析百万消息量小规模IM即时通讯系统技术相关的知识,希望对你有一定的参考价值。

现如今的互联网产品中,即时通讯技术已经不仅限于传统IM聊天工具本身,它早已通过有形或无形的方式嵌入到了各种形式的互联网应用当中。IM技术(或者说即时通讯技术)对于很多开发者来说,确实是必不好可少的领域知识,不可或缺。

 

典型的IM系统通常需要满足四点能力:高可靠性、高可用性、实时性和有序性。

架构设计

以我的这个项目来说,架构设设计要点主要是:

    1)微服务:拆分为用户微服务 &消息连接服务 &消息业务服务;
    2)存储架构:兼容性能与资源开销,选择 reids&mysql
    3)高可用:可以支撑起高并发场景,选择 Spring 提供的 websocket;
    4)支持多端消息同步:app 端、web 端、微信公众号、小程序消息;
    5)支持在线与离线消息场景。

理解读扩散和写扩散

我们举个例子说明什么是读扩散,什么是写扩散:

一个群聊“相亲相爱一家人”,成员:爸爸、妈妈、哥哥、姐姐和我(共 5 人)。

因为你最近交到女朋友了,所以发了一条消息“我脱单了”到群里面,那么自然希望爸爸妈妈哥哥姐姐四个亲人都能收到了。

正常逻辑下,群聊消息发送的流程应该是这样:

    1)遍历群聊的成员并发送消息;
    2)查询每个成员的在线状态;
    3)成员不在线的存储离线;
    4)成员在线的实时推送。

问题在于:如果第4步发生异常,群友会丢失消息,那么会导致有家人不知道“你脱单了”,造成催婚的严重后果。

所以优化的方案是:不管群员是否在线,都要先存储消息。

按照上面的思路,优化后的群消息流程如下:

    1)遍历群聊的成员并发送消息;
    2)群聊所有人都存一份;
    3)查询每个成员的在线状态;
    4)在线的实时推送。

以上优化后的方案,便是所谓的“写扩散”了。

问题在于:每个人都存一份相同的“你脱单了”的消息,对磁盘和带宽造成了很大的浪费(这就是写扩散的最大弊端)。即时通讯聊天软件app开发可以加蔚可云的v:weikeyun24咨询

 

所以优化的方案是:群消息实体存储一份,用户只存消息 ID 索引。

于是再次优化后的发送群消息流程如下:

    1)遍历群聊的成员并发送消息;
    2)先存一份消息实体;
    3)然后群聊所有人都存一份消息实体的 ID 引用;
    4)查询每个成员的在线状态;
    5)在线的实时推送。

二次优化后的方案,便是所谓的“读扩散”了。

“消息”所关联的对象

常见的消息业务,可以抽象为几个实体模型概念:用户/用户关系/用户设备/用户连接状态/消息/消息队列。

用户实体:

    1)用户->用户终端设备:每个用户能够多端登录并收发消息;
    2)用户->消息:考虑到读扩散,每个用户与消息的关系都是 1:n;
    3)用户->消息队列:考虑到读扩散,每个用户都会维护自己的一份“消息列表”(1:1),如果考虑到扩容,甚至可以开辟一份消息溢出列表接收超出“消息列表”容量的消息数据(此时是 1:n);
    4)用户->用户连接状态:考虑到用户能够多端登录,那么 app/web 都会有对应的在线状态信息(1:n);
    5)用户->联系人关系:考虑到用户最终以某种业务联系到一起,组成多份联系人关系,最终形成私聊或者群聊(1:n);


联系人关系(主要由业务决定用户与用户之间的关系),比如说:

    1)某个家庭下有多少人,这个家庭群聊就有多少人;
    2)在 ToB 场景,在钉钉企业版里,我们往往有企业群聊这个存在。


消息实体:

    消息->消息队列:考虑到读扩散,消息最终归属于一个或多个消息队列里,因此群聊场景它会分布在不同的消息队列里。


消息队列实体:

    消息队列:确切说是消息引用队列,它里面的索引元素最终指向具体的消息实体对象。


用户连接状态:

    1)对于 app 端:网络原因导致断线,或者用户手动 kill 掉应用进程,都属于离线;
    2)对于 web 端:网络原因导致浏览器断网,或者用户手动关闭标签页,都属于离线;
    3)对于公众号:无法分别离线在线;
    4)对于小程序:无法分别离线在线。


用户终端设备:

    客户端一般是 android&ios,web 端一般是浏览器,还有其他灵活的 WebView(公众号/小程序)。

消息的存储方案

对于消息存储方案,本质上只有三种方案:要么放在内存、要么放在磁盘、要么两者结合存储(据说大公司为了优化性能,活跃的消息数据都是放在内存里面的,毕竟有钱~)。

下面分别解析主要方案的优点与弊端:

    1)方案一:考虑性能,数据全部放到 redis 进行存储;
    2)方案二:考虑资源,数据用 redis + mysql 进行存储。

对于方案一:redis

前提:用户 & 联系人关系,由于是业务数据,因此统一默认使用关系型数据库存储。

解释如下:

    1)用户发消息;
    2)redis 创建一条实体数据 &一个实体数据计时器;
    3)redis 在 B 用户的用户队列 添加实体数据引用;
    4)B 用户拉取消息(后续 5.2 会提及拉模式)。


实现方案:

    1)用户队列,zset(score 确保有序性);
    2)消息实体列表,hash(msg_id 确保唯一性);
    3)消息实体计数器,hash(支持群聊消息的引用次数,倒计时到零时则删除实体列表的对应消息,以节省资源)。


优点是:内存操作,响应性能好

弊端是:

    1)内存消耗巨大,eg:除非大厂,小公司的服务器的宝贵内存资源是耗不起业务的,随着业务增长,不想拓展资源,就需要手动清理数据了;
    2)受 redis 容灾性策略影响较大,如果 redis 宕机,直接导致数据丢失(可以使用 redis 的集群部署/哨兵机制/主从复制等手段解决)。

方案二:redis+mysql

前提:用户 & 联系人关系,由于是业务数据,因此统一默认使用关系型数据库存储。

解释如下:

    1)用户发消息;
    2)mysql 创建一条实体数据;
    3)redis 在 B 用户的用户队列 添加实体数据引用;
    4)B 用户拉取消息(下文会提及拉模式)。


实现方案:

    1)用户队列,zset(score 确保有序性);
    2)消息实体列表,转移到 mysql(表主键 id 确保唯一性);
    3)消息实体计数器,hash(删除这个概念,因为磁盘可用总资源远远高于内存总资源,哪怕一直存放 mysql 数据库,在业务量百万级别时也不会有大问题,如果是巨大体量业务就需要考虑分表分库处理检索数据的性能了)。


优点是:

    1)抽离了数据量最大的消息实体,大大节省了内存资源;
    2)磁盘资源易于拓展 ,便宜实用。


弊端是:磁盘读取操作,响应性能较差(从产品设计的角度出发,你维护的这套 IM 系统究竟是强 IM 还是弱 IM)。

以上是关于浅析百万消息量小规模IM即时通讯系统技术的主要内容,如果未能解决你的问题,请参考以下文章

基于实践:一套百万消息量小规模IM系统技术要点总结

im即时通讯开发:百万人的直播实时聊天消息分发技术

im即时通讯开发:百万人的直播实时聊天消息分发技术

IM即时通讯开发架构技术:整体架构服务拆分

IM即时通讯开发架构技术:整体架构服务拆分

浅析IM即时通讯开发出现上网卡顿?网络掉线?