目前系统中，EMQ为我们的多人聊天功能提供了很大的支持。特别感谢EMQ！
如何处理大量的历史遗留消息是目前棘手的问题。
EMQ开源版本提供了 clean_session 和 最大消息队列来调控一个会话可保留的历史消息数量，目前我们正是此依赖此方案来实现的，但是当节点重启之后，消息队列便会清空，历史消息丢失。同时如果消息队列过大，机器内存占用将会很高。
目前能想到的解决方案：
- 购买企业版，使用消息持久化功能
- 客户端连接EMQ时，将 clean_seesion 设为 true , 不再依赖ＥＭＱ 的会话保留功能。
自己实现持久化，通过 webHook 将每一次发送的消息都保存到 mongoDB 或者 mysql 中。 系统提供一
个历史消息接口，客户端把该client接收到的最后一条消息时间（T1）带给服务器，服务器将 T1 之后的
所有消息返给客户端，然后删除 该 client 的全部消息
抛砖引玉，想看看官方和其他用户有没有更好的方案
1 首先，根据国内法律的话，聊天系统要保留消息（详细情况请咨询法律专家），如果你们的业务在国外可以忽略
2 消息持久化本质上是业务信息持久化，也就是业务落盘，对于聊天系统其实是避不开的问题
3 自己写webhook或者exhook保持消息持久化要考虑很多因素，比如消息高峰高并发，消息异常处理，服务运维等等。我们一般推荐自建平台（前提是技术能力够强且预算充足）
4 推荐一下我们的cloud服务，3中的问题全都有专业团队来做，强大的处理能力和运维经验， 7 * 24 的服务。比租个云主机贵不了多少，并且可以试用14天，官网链接
1 个赞
不推荐按照时间来划分，高并发场景可能遇到时间一样的两条消息。
1 个赞
有没有什么办法统计所有客户端消息队列的总长度。以及由未及时消费的消息占用的总内存大小？
难道是 messages.publish - messages.received ?
我们现在正在做客户端级别的消息计数器，会统计消息收发数量，消息队列，消息丢弃等，会在企业版4.4.1和开源版5.0上更新
