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)

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

im即时通讯开发:群聊消息如此复杂,如何保证不丢不重_第1张图片

步骤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,但是每个用户的每一条离线消息都将在数据库中保存一条记录,有没有办法减少离线消息的记录数呢?

im即时通讯开发:群聊消息如此复杂,如何保证不丢不重_第2张图片

群消息优化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请求量呢?

你可能感兴趣的:(即时通讯)