微信：群消息，我们绝对不可能丢！（第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. 离线消息过多，可以分页拉取（按需拉取）优化；

知其然，知其所以然。

思路比结论更重要。

==全文完==

近期文章：

《1亿数据量，uid分库，tid上的查询该怎么办？（第55讲）》

创业了，欢迎围观：

《40岁，我创业了，一个人...》

未来10年，准备全职做职场发展社群，专注于技术人职场发展，欢迎大家加入。