浅析百万消息量小规模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即时通讯系统技术的主要内容,如果未能解决你的问题,请参考以下文章