历史消息持久化与再次消费问题

目前系统中,EMQ为我们的多人聊天功能提供了很大的支持。特别感谢EMQ!

如何处理大量的历史遗留消息是目前棘手的问题。
EMQ开源版本提供了 clean_session 和 最大消息队列来调控一个会话可保留的历史消息数量,目前我们正是此依赖此方案来实现的,但是当节点重启之后,消息队列便会清空,历史消息丢失。同时如果消息队列过大,机器内存占用将会很高。

目前能想到的解决方案:

  1. 购买企业版,使用消息持久化功能
  2. 客户端连接EMQ时,将 clean_seesion 设为 true , 不再依赖EMQ 的会话保留功能。
    自己实现持久化,通过 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上更新