微信：群消息，我们绝对不可能丢！（第56讲）
《架构师之路：架构设计中的100个知识点》
56.消息可靠投递
前几天聊了1v1在线消息，离线消息的可达性：
《微信：我们绝不丢消息！（第49讲）》
《微信：我绝不丢离线消息！（第54讲）》
有水友问我说，微信的群消息，是怎么做到不丢的？ 做过几十年IM架构，今天和大家聊聊消息的可靠投递。
群聊的核心需求，群友在群内发消息，期望：
1. 在线的群友能第一时间收到消息；
2. 离线的群友能在登录后收到消息；
群消息的实时性、可达性、离线消息的复杂度，要远高于1v1消息。
群业务的核心数据结构如何？
群成员表：记录群里的群成员。
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-5所述：
1. x向server发出群消息；
2. server去db中查询群用户(x,A,B,C,D)；
3. server去cache中查询群用户在线状态；
4. 在线的用户A与B，进行实时推送；
5. 离线的用户C与D，进行离线存储；
然后，是群离线消息。
典型的群离线消息拉取流程，如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)
群离线消息表，需要进行优化，只存储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. 离线消息的拉取也可能出现消息丢失，原因同上；
很容易想到，必须和1v1消息投递一样，需要加入应用层的ACK。
群消息，如何通过应用层ACK，保证消息的可靠投递？
应用层ACK优化后，群在线消息发送又做了调整：
3. 在消息msg_detail存储到群消息表后，不管用户是否在线，都先将msg_id存储到离线消息表里；
6. 在线的用户A和B收到群消息后，需要增加一个应用层ACK，来标识消息到达；
7. 在线的用户A和B在应用层ACK后，将他们的离线消息msg_id删除掉；
对应到群离线消息的拉取也一样：
1. 先拉取msg_id；
2. 再拉取msg_detail；
5. 最后应用层ACK；
6. server收到应用层ACK才能删除离线消息表里的msg_id；
如果拉取了消息，却没来得及应用层ACK，会收到重复的消息么？
会，但可以在客户端去重，对于重复的msg_id，对用户不展现，从而不影响用户体验。
对于离线的每一条消息，虽然只存储了msg_id，但是每个用户的每一条离线消息都将在数据库中保存一条记录，有没有办法减少离线消息的记录数呢？
对于一个群用户，在ta登出后的离线期间内，肯定是所有的群消息都没有收到的，不用对所有的每一条离线消息存储一个离线msg_id，而只需要存储最近一条拉取到的离线消息的time（或者msg_id），下次登录时拉取在那之后的所有群消息即可，而没有必要存储每个人未拉取到的所有离线消息msg_id。
群成员表，增加一个属性，记录每个群成员最近一条ACK的群消息msg_id（或者time）。
t_group_users(group_id, user_id, last_ack_msg_id)
群消息表，不变，依然存储群中所有的消息：
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的方式又有两种方式：
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. 离线消息过多，可以分页拉取（按需拉取）优化；
知其然，知其所以然。
思路比结论更重要。
==全文完==
本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-04-16，如有侵权请联系 cloudcommunity@tencent 删除数据库存储微信登录优化
发布评论