如何高效拉取，会不会丢？

：用来描述一个群成员的离线消息。

推，写扩散，存储群离线消息的过程如何?

• 先从群成员表中，获取群里有多少个用户;
• 从某个服务中，获取这些用户有多少个不在线;
• 将群消息，插入到这些用户的群离线消息表;

画外音：如果要支持消息漫游，则可以省略步骤二。

此时，用户拉取离线消息的过程如何?

• 用户登录，向server拉取离线消息;
• server返回并删除离线消息;

离线消息推，存在什么问题?

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

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

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

这样优化后，群消息的发送和存储要做一些升级：

• 每次发送群消息之前，先存储群消息的内容;
• 每次存储离线消息时，只存储msg_id，而不用为每个用户存储msg_detail;

相应的，拉取离线消息也要做对应的升级：

• 先拉取所有的离线消息msg_id;
• 再根据msg_id拉取msg_detail;
• 删除时，只删除自己的离线msg_id，而不删除msg_detail;

画外音：毕竟msg_detail只存储了一份，不能随便删。

上述过程，能保证离线消息的可达性么?

不能。

例如：server返回客户端离线消息之后，删除了离线消息，但客户端没有展现就奔溃了，离线消息就会丢失。

如何解决离线消息可达性呢?

很容易想到，通过ACK机制，server返回离线消息之后，不能立刻删除离线消息，而必须等客户端ACK，才能删除。

此时，离线消息拉取升级为：

• 用户登录，向server拉取离线消息;
• server返回离线消息;
• 客户端确认收到了离线消息;
• server再删除离线消息;

画外音：增加了3和4两个步骤。

还有一个问题，一次有几十个群，每个群有几千条离线消息，共计几万条群离线消息，消息量过大怎么办?

当然不能一次性拉取，可以：

• 分群拉取;
• 每个群分页拉取;
• 拉取一页，删除一页，拉取下一页，删除下一页...

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

可以在客户端去重，对于重复的msg_id，对用户不展现，从而不影响用户体验

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!