群聊比单聊，为什么复杂这么多？

ゝ一纸荒年。 2022-04-23 01:58 238阅读 0赞

出处：[群聊比单聊，为什么复杂这么多？][Link 1]

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

(1)**在线的群友**能第一时间收到消息；

(2)**离线的群友**能在登陆后收到消息；

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

**常见的群消息流程如何？**

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

**群成员表**：

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离线，期望未来拉取到离线消息；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70][]  
典型群消息投递流程，如图步骤1-4所述：

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

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

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

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

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

![2019012308581431.jpg][]  
典型的群离线消息拉取流程，如图步骤1-3所述：

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

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

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

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

**如何优化，减少消息冗余量？**

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

**群消息表**：

t\_group\_msgs(group\_id, sender\_id, time,msg\_id, msg\_detail)

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

**群离线消息表**，需要进行优化：

t\_offine\_msgs(user\_id, group\_id, msg\_id)

*画外音：优化后只存储msg\_id。*

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

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

步骤6：每次存储离线消息时，只存储msg\_id，而不用为每个用户存储msg\_detail；

![20190123085840244.jpg][]  
拉取离线消息时也做了响应的修改：

步骤1：先拉取所有的离线消息msg\_id；

步骤3：再根据msg\_id拉取msg\_detail；

步骤5：删除离线msg\_id；

**优化后的流程，能保证消息的可达性么？**例如：

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

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

*画外音：单对单消息的可靠投递一样，是通过加入应用层的ACK实现的，群消息呢？*

**群消息，如何通过应用层ACK，保证消息的可靠投递？**

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

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

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

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

![20190123085858516.jpg][]  
对应到群离线消息的拉取也一样：

步骤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。

**群成员表**，增加一个属性：

t\_group\_users(group\_id, user\_id, last\_ack\_msg\_id)

*画外音：用来描述一个群里有多少成员，以及每个成员最后一条ack的群消息的msg\_id（或者time）。*

**群消息表**，不变：

t\_group\_msgs(group\_id, sender\_id, time,msg\_id, msg\_detail)

*画外音：还是用来存储一个群中所有的消息内容。*

**群离线消息表**：不再需要。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 3][]  
离线消息表优化后，群在线消息的投递流程：

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

步骤7：在线的用户A和B在应用层ACK后，将last\_ack\_msg\_id更新即可（优化前需要将msg\_id从离线消息表删除）；

![20190123085918373.jpg][]  
群离线消息的拉取流程也类似：

步骤1：拉取离线消息；

步骤3：ACK离线消息；

步骤4：更新last\_ack\_msg\_id；

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

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

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

(1)每收到N条群消息ACK一次，这样请求量就降低为原来的1/N了；

(2)每隔时间间隔T进行一次群消息ACK，也能达到类似的效果；

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

客户端按照msg\_id去重，不对用户展现，就保证良好的用户体验。

**群离线消息过多，拉取过慢，怎么办？**

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

**总结**

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

(1)不管是群在线消息，还是群离线消息，应用层的ACK是可达性的保障；

(2)群消息只存一份，不用为每个用户存储离线群msg\_id，只需存储一个最近ack的群消息id/time；

(3)为了减少消息风暴，可以批量ACK；

(4)如果收到重复消息，需要msg\_id去重，让用户无感知；

(5)离线消息过多，可以分页拉取（按需拉取）优化；

[Link 1]: https://mp.weixin.qq.com/s/so7F88S7-3Wmq9x_rrYAoA
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70]: /images/20220323/fadb8889667a4bfb85df805c93ecba3c.png
[2019012308581431.jpg]: /images/20220323/3c06eb02797c490f84cd317424db9063.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 1]: /images/20220323/342deff13e264f0fa3620ee4217b65cf.png
[20190123085840244.jpg]: /images/20220323/b5d5dbb1f3a14cf0baa5db6b281aef3a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 2]: /images/20220323/01d58a9d4ce344d098efc7489c8506e0.png
[20190123085858516.jpg]: /images/20220323/62e76ba999604b04890965dc7cd9d436.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 3]: /images/20220323/e284038b5c8b4e889d674497974b11e1.png
[20190123085918373.jpg]: /images/20220323/76bec002fa4442e7a851340a31fe017e.png