群聊比单聊,为什么复杂这么多?

开发 开发工具
群聊是多人社交的基本诉求,一个群友在群内发了一条消息,期望做到在线的群友能第一时间收到消息,群消息的实时性、可达性、离线消息的复杂度,要远高于单对单消息。

群聊是多人社交的基本诉求,一个群友在群内发了一条消息,期望做到:

  • 在线的群友能***时间收到消息;
  • 离线的群友能在登陆后收到消息;

群消息的实时性、可达性、离线消息的复杂度,要远高于单对单消息。

常见的群消息流程如何?

群业务的核心数据结构有两个。

群成员表:

  1. t_group_users(group_id, user_id) 

画外音:用来描述一个群里有多少成员。

群离线消息表:

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

画外音:用来描述一个群成员的离线消息。

业务场景举例:

  • 假设一个群中有x,A,B,C,D共5个成员,成员x发了一个消息;
  • 成员A与B在线,期望实时收到消息;
  • 成员C与D离线,期望未来拉取到离线消息;

典型群消息投递流程,如图步骤1-4所述:

  • 步骤1:群消息发送者x向server发出群消息;
  • 步骤2:server去db中查询群中有多少用户(x,A,B,C,D);
  • 步骤3:server去cache中查询这些用户的在线状态;
  • 步骤4:对于群中在线的用户A与B,群消息server进行实时推送;
  • 步骤5:对于群中离线的用户C与D,群消息server进行离线存储;

典型的群离线消息拉取流程,如图步骤1-3所述:

  • 步骤1:离线消息拉取者C向server拉取群离线消息;
  • 步骤2:server从db中拉取离线消息并返回群用户C;
  • 步骤3:server从db中删除群用户C的群离线消息;

那么,问题来了!对于同一份群消息的内容,多个离线用户似乎要存储很多份。假设群中有200个用户离线,离线消息则冗余了200份,这极大的增加了数据库的存储压力。

如何优化,减少消息冗余量?

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

群消息表:

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

画外音:用来存储一个群中所有的消息内容。

群离线消息表,需要进行优化:

  1. t_offine_msgs(user_id, group_id, msg_id) 

画外音:优化后只存储msg_id。

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

  • 步骤3:每次发送在线群消息之前,要先存储群消息的内容;
  • 步骤6:每次存储离线消息时,只存储msg_id,而不用为每个用户存储msg_detail;

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

  • 步骤1:先拉取所有的离线消息msg_id;
  • 步骤3:再根据msg_id拉取msg_detail;
  • 步骤5:删除离线msg_id;

优化后的流程,能保证消息的可达性么?例如:

  • 在线消息的投递可能出现消息丢失,例如服务器重启,路由器丢包,客户端crash;
  • 离线消息的拉取也可能出现消息丢失,原因同上;

画外音:单对单消息的可靠投递一样,是通过加入应用层的ACK实现的,群消息呢?

群消息,如何通过应用层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;

如果拉取了消息,却没来得及应用层ACK,会收到重复的消息么?

似乎会,但可以在客户端去重,对于重复的msg_id,对用户不展现,从而不影响用户体验。

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

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

群成员表,增加一个属性:

  1. t_group_users(group_id, user_id, last_ack_msg_id) 

画外音:用来描述一个群里有多少成员,以及每个成员***一条ack的群消息的msg_id(或者time)。

群消息表,不变:

  1. 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;

加入ACK机制,保证群消息的可靠投递只会,假设1个群有500个用户,“每条”群消息都会变为500个应用层ACK,似乎会对服务器造成巨大的冲击。有没有办法减少ACK请求量呢?

批量ACK,是一种常见的,降低请求量的方式。

如果每条群消息都ACK,确实会给服务器造成巨大的冲击,为了减少ACK请求量,可以批量ACK,批量ACK的方式又有两种方式:

  • 每收到N条群消息ACK一次,这样请求量就降低为原来的1/N了;
  • 每隔时间间隔T进行一次群消息ACK,也能达到类似的效果;

批量ACK有可能导致新的问题:如果还没有来得及ACK群消息,用户就退出了,这样下次登录似乎会拉取到重复的离线消息,怎么办?

客户端按照msg_id去重,不对用户展现,就保证良好的用户体验。

群离线消息过多,拉取过慢,怎么办?

分页拉取(按需拉取),细节就不再展开了,都是常见的优化方案。

总结

群消息还是非常有意思的,做个简单总结:

  • 不管是群在线消息,还是群离线消息,应用层的ACK是可达性的保障;
  • 群消息只存一份,不用为每个用户存储离线群msg_id,只需存储一个最近ack的群消息id/time;
  • 为了减少消息风暴,可以批量ACK;
  • 如果收到重复消息,需要msg_id去重,让用户无感知;
  • 离线消息过多,可以分页拉取(按需拉取)优化;

【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2022-11-09 10:32:50

群业务群聊数据结构

2017-12-21 19:38:50

润乾中间表

2022-07-26 23:43:29

编程语言开发Java

2013-01-15 09:41:45

编程语言

2016-12-01 13:40:37

2018-12-21 09:36:31

OLAP苏宁Druid

2015-06-25 13:31:19

2022-08-04 23:32:38

比特币以太坊代币

2022-01-12 20:04:09

网络故障断网事件网络安全

2020-04-27 09:45:16

网络工程师网络技术网络

2020-07-02 14:12:52

C++语言编程

2024-02-04 10:29:58

线程通信

2021-05-31 22:26:20

5G技术通信

2015-01-14 14:27:18

Docker容器镜像

2021-08-19 06:53:18

开发语言Java

2024-03-01 17:01:15

GraphQL后端

2017-08-11 14:21:33

软件开发前端框架

2023-07-17 08:21:52

漏洞版本项目

2019-07-05 15:52:03

数据科学家大数据机器学习

2021-09-13 10:03:54

蓝牙连接蓝牙蓝牙设备
点赞
收藏

51CTO技术栈公众号