如何仅使用消息ID确认Rabbitmq消息（在Go中）？

Question

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.

Answer 1

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.