2015-09-14 21:03
浏览 546


I built a small server (golang) to grab messages from a RabbitMQ and deliver them to connected browsers via a Websocket.
It works quite well, though has one caveat: the messages are acknowledged when delivered to the browser via the websocket. For most messages that is ok but some messages might be very important. If the user's browser received those but the user didn't SEE the message, it would be lost if the browser was closed or reloaded.
Is there a way to ack a message at a later time based on its message id (from the Delivery struct)?
The use case would be that some messages are acked when the user acknowledges them explicitly and at that point the message id is sent back to the tool to be acknowledged with RabbitMQ.

图片转代码服务由CSDN问答提供 功能建议

它运行良好,但有一个警告:消息通过websocket传递到浏览器时得到确认。 对于大多数消息来说都可以,但是某些消息可能非常重要。 如果用户的浏览器收到了这些消息,但用户没有看到该消息,则如果关闭或重新加载该浏览器,消息将会丢失。
用例是,当用户明确确认 some 消息后,该消息将被确认,并在此时将消息ID发送回工具进行确认 RabbitMQ。

  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

1条回答 默认 最新

  • douningqiu4991 2015-09-14 23:13

    Even if you can do this, it's bad design.

    What happens to the message if the user doesn't see it? Does your web server infinitely hang on to it? Does it "nack" the message back to the queue?

    Neither of these options are good.

    Hang on to every message, and RabbitMQ will start having issues with thousands of unacknowledged messages from a lot of users. Nack the message back to the queue and you'll thrash the message round in circles, spiking CPU resources on the web server and the RMQ server, as well as network traffic between the two.

    The better solution to this problem is to store the message in a database, after pulling it out of RabbitMQ. When it gets sent to / viewed by the browser, update the database to reflect that.

    From a yet-unpublished article I've written:

    Store the message in a database.

    Add a field to the database record that says who this message belongs to. When the user reconnects later, query the database for any messages that this user needs to see and send them along at that time.

    The full process started above, then becomes this:

    • User's browser connects to SignalR/Socket.io/Pusher/websockets on web server
    • Web server checks a queue for updates that happen during a long running process
    • When a message for a logged in user comes in
      • If the user is logged in, broadcast the message through the websocket to the user
      • If the user is not logged in, store the message in a database
    • When the user logs in again, query the database and send all waiting messages

    It's what you would have done before the idea of a message queue came in to play, right? It should be what you would do now that you have a message queue, as well.

    打赏 评论

相关推荐 更多相似问题