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

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

(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 离线，指望将来拉取到离线消息；

典型群消息投递流程，如图步骤 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，就能大大的下降数据库的冗余存储量。

群消息表：

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

画外音：用来存储一个群中全部的消息内容。

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

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；

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

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

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

画外音：单对单消息的可靠投递同样，是经过加入应用层的 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。

群成员表，增长一个属性：

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)

画外音：仍是用来存储一个群中全部的消息内容。

群离线消息表：再也不须要。

离线消息表优化后，群在线消息的投递流程：

步骤 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 的方式又有两种方式：

(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) 离线消息过多，能够分页拉取（按需拉取）优化；

思路比结论重要，但愿你们有收获。

架构师之路 - 分享可落地的技术文章

你丢过群消息么？