Even if the RabbitMQ broker provides many high-availability server-side options, they are pretty useless if the connecting clients do not implement some measures in spite of extending the high availability to the clients too:
Clients must check that the produced messages are successfully transferred to RabbitMQ and handle error conditions, for example, republishing them if needed.
Clients consuming messages must check that they are not duplicated; given the possibility of retransmitting messages, it is possible to actually get duplicated messages on the consumer side too. This activity is commonly called deduplication.
Clients must check that the RabbitMQ node to which they are connected is healthy. In particular, a consumer waiting for messages could not realize that it is not receiving messages because the server is stuck.
Clients should try to connect to any available cluster node, both for maximum reliability and for uniform resource distribution.
These mechanisms...