im即时通讯开发：群聊消息如此复杂，如何保证不丢不重

群聊已经成为主流IM软件的基本功能，不管是QQ群、还是微信群，一个群友在群内发了一条消息，那么对于IM服务器来说需要保证：

在线的群友能第一时间收到消息；

离线的群友能在登陆后收到消息。

常见的群消息流程

开始讲群消息投递流程之前，先介绍两个群业务的核心数据结构：

群成员表：用来描述一个群里有多少成员

t_group_users(group_id, user_id)

群离线消息表：用来描述一个群成员的离线消息

t_offine_msgs(user_id, group_id, sender_id,time, msg_id, msg_detail)

业务场景举例：

1）一个群中有x,A,B,C,D共5个成员，成员x发了一个消息；

2）成员A与B在线，期望实时收到消息；

3）成员C与D离线，期望未来拉取到离线消息。

系统架构简介：

1）客户端：x,A,B,C,D共5个客户端用户；

2）服务端：

2.1）所有模块与服务抽象为server；

2.2）所有用户在线状态抽象存储在高可用cache里；

2.3）所有数据信息，例如群成员、群离线消息抽象存储在db里。即时通讯开发

典型群消息投递流程

步骤1：群消息发送者x向server发出群消息；

步骤2：server去db中查询群中有多少用户(x,A,B,C,D)；

步骤3：server去cache中查询这些用户的在线状态；

步骤4：对于群中在线的用户A与B，群消息server进行实时推送；

步骤5：对于群中离线的用户C与D，群消息server进行离线存储。

典型的群离线消息拉取流程

步骤1：离线消息拉取者C向server拉取群离线消息；

步骤2：server从db中拉取离线消息并返回群用户C；

步骤3：server从db中删除群用户C的群离线消息。

存在的问题：

上述流程是最容易想，也最容易理解的，存在的问题也最显而易见：对于同一份群消息的内容，多个离线用户存储了很多份。假设群中有200个用户离线，离线消息则冗余了200份，这极大的增加了数据库的存储压力。

群消息优化1：减少存储量

为了减少离线消息的冗余度，增加一个群消息表，用来存储所有群消息的内容，离线消息表只存储用户的群离线消息msg_id，就能大大的降低数据库的冗余存储量，思路如下。

群消息表：用来存储一个群中所有的消息内容

t_group_msgs(group_id, sender_id, time,msg_id, msg_detail)

群离线消息表：优化后只存储msg_id

t_offine_msgs(user_id, group_id, msg_id)

这样优化后，群在线消息发送就做了一些修改：

步骤3：每次发送在线群消息之前，要先存储群消息的内容；

步骤6：每次存储离线消息时，只存储msg_id，而不用为每个用户存储msg_detail。

拉取离线消息时也做了响应的修改：

步骤1：先拉取所有的离线消息msg_id；

步骤3：再根据msg_id拉取msg_detail；

步骤5：删除离线msg_id。

存在的问题（如同单对单消息的发送一样）：

1）在线消息的投递可能出现消息丢失，例如服务器重启，路由器丢包，客户端crash；

2）离线消息的拉取也可能出现消息丢失，原因同上。

需要和单对单消息的可靠投递一样，加入应用层的ACK，才能保证群消息一定到达。

群消息优化2：应用层ACK

应用层ACK优化后，群在线消息发送又发生了一些变化：

步骤3：在消息msg_detail存储到群消息表后，不管用户是否在线，都先将msg_id存储到离线消息表里；

步骤6：在线的用户A和B收到群消息后，需要增加一个应用层ACK，来标识消息到达；

步骤7：在线的用户A和B在应用层ACK后，将他们的离线消息msg_id删除掉。

对应到群离线消息的拉取也一样：

步骤1：先拉取msg_id；

步骤3：再拉取msg_detail；

步骤5：最后应用层ACK；

步骤6：server收到应用层ACK才能删除离线消息表里的msg_id。

存在的问题：

1）如果拉取了消息，却没来得及应用层ACK，会收到重复的消息么？

答案是肯定的，不过可以在客户端去重，对于重复的msg_id，对用户不展现，从而不影响用户体验

2）对于离线的每一条消息，虽然只存储了msg_id，但是每个用户的每一条离线消息都将在数据库中保存一条记录，有没有办法减少离线消息的记录数呢？

群消息优化3：离线消息表

其实，对于一个群用户，在ta登出后的离线期间内，肯定是所有的群消息都没有收到的，完全不用对所有的每一条离线消息存储一个离线msg_id，而只需要存储最近一条拉取到的离线消息的time（或者msg_id），下次登录时拉取在那之后的所有群消息即可，而完全没有必要存储每个人未拉取到的离线消息msg_id

群成员表：用来描述一个群里有多少成员，以及每个成员最后一条ack的群消息的msg_id（或者time）

t_group_users(group_id, user_id, last_ack_msg_id(last_ack_msg_time))

群消息表：用来存储一个群中所有的消息内容，不变

t_group_msgs(group_id, sender_id, time,msg_id, msg_detail)

群离线消息表：不再需要了

离线消息表优化后，群在线消息的投递流程：

步骤3：在消息msg_detail存储到群消息表后，不再需要操作离线消息表（优化前需要将msg_id插入离线消息表）；

步骤7：在线的用户A和B在应用层ACK后，将last_ack_msg_id更新即可（优化前需要将msg_id从离线消息表删除）。

群离线消息的拉取流程也类似：

步骤1：拉取离线消息；

步骤3：ACK离线消息；

步骤4：更新last_ack_msg_id。

存在的问题：

由于“消息风暴扩散系数”的存在，假设1个群有500个用户，“每条”群消息都会变为500个应用层ACK，将对服务器造成巨大的冲击，有没有办法减少ACK请求量呢？

im即时通讯开发：群聊消息如此复杂，如何保证不丢不重相关推荐

IM即时通讯开发群聊消息的已读回执功能该怎么实现？
我们平时在使用即时通讯应用时候,每当发出一条聊天消息,都希望对方尽快看到,并尽快回复,但对方到底有没有真的看到?我却并不知道.一个残酷的现实是,很多时候对方其实是早就已经看到了这条消息,但出出种种原因 ...
im即时通讯开发：离线消息、历史消息的实践
在如今的移动互联网时代,IM类产品已是我们生活中不可或缺的组成部分.像微信.钉钉.QQ等是典型的以 IM 为核心功能的社交产品.另外也有一些应用虽然IM功能不是核心,但IM能力也是其整个应用极其重要的 ...
即时通讯开发Android端消息推送总结
为什么要研究Android推送技术? 主要还是毕业设计要做一个即时通信app, 我是不喜欢做什么社交app的, 也就象牙塔里的人想得出来, 说实话有这功夫还不如钻研一个小技术点, 把一个点研究透彻, ...
im即时通讯开发：IM群聊消息的已读回执功能
我们平时在使用即时通讯应用时候,每当发出一条聊天消息,都希望对方尽快看到,并尽快回复,但对方到底有没有真的看到?我却并不知道. 一个残酷的现实是,很多时候对方其实是早就已经看到了这条消息,但出出种种原 ...
im即时通讯开发：高可用、易伸缩、高并发的IM群聊、单聊架构方案设计
要实现一整套能用于大用户量.高并发场景下的IM群聊,技术难度远超IM系统中的其它功能,原因在于:IM群聊消息的实时写扩散特性带来了一系列技术难题. 举个例子:如一个2000人群里,一条普通消息的发出问 ...
im即时通讯开发：万人群聊消息
传统意义上的IM群聊,通常都是像微信这样的500人群,或者QQ的2000人群(QQ有3000人群,但那是单独收费的,也就意味着它并非无门槛标配,能用上的人并不多). 自从国外某号称"世界上最 ...
融云RongIMKit即时通讯开发(让我们聊起来)
1.前言现在APP功能越来越多,聊天成为很重要的一个功能,现在市面上流行的即时通讯SDK基本上只有融云和环信,而近年来融云在各个方面都有超过环信的趋势,所以在项目中用到融云的地方越来越多.那我们是不 ...
im即时通讯开发：消息模型、万人群、已读回执、消息撤回功能
企业微信作为一款办公协同的产品,聊天消息收发是最基础的功能.消息系统的稳定性.可靠性.安全性尤其重要. 消息系统的构建与设计的过程中,面临着较多的难点.而且针对toB场景的消息系统,需要支持更为复杂的 ...
im即时通讯开发：IM系统中离线消息、历史消息实践
在如今的移动互联网时代,IM类产品已是我们生活中不可或缺的组成部分.像微信.钉钉.QQ等是典型的以 IM 为核心功能的社交产品.另外也有一些应用虽然IM功能不是核心,但IM能力也是其整个应用极其重要的 ...

im即时通讯开发：群聊消息如此复杂，如何保证不丢不重

im即时通讯开发：群聊消息如此复杂，如何保证不丢不重相关推荐

最新文章

热门文章