消费者回调 (跨公司场景)

在某些业务场景下，为了提高消息投递的可靠性，消费者在消费完消息后可以回调生产者API，以达到响应消息的目的。例如商业银行与人民银行二代支付通信，无论是人行收到了商业银行的消息，还是商业银行收到了人行的消息，都必须发送一条响应消息（叫做回执报文）。

补偿机制 (定时重发)

如果生产者的API 就是没有被调用，也没有收到消费者的响应消息，怎么办？

其中原因可能是消费者处理时间太长或者网络超时。

生产者与消费者之间应该约定一个超时时间，比如5 分钟，对于超出这个时间没有得到响应的消息，可以设置一个定时重发的机制，但要发送间隔和控制次数，比如每隔2分钟发送一次，最多重发3 次，否则会造成消息堆积。

重发可以通过消息落库+定时任务来实现。

消息幂等性 (唯一的业务id)

如果消费者每一次接收生产者的消息都成功了，只是在响应或者调用API 的时候出了问题，会不会出现消息的重复处理？

为了避免相同消息的重复处理，必须实现消息的幂等性，可以对每一条消息生成一个唯一的业务ID，通过日志或者消息落库来做重复控制。

最终一致性

如果确实是消费者宕机了，或者代码出现了BUG 导致无法正常消费，在我们尝试多次重发以后，消息最终也没有得到处理，怎么办？

在金融系统中，都会有双方对账或者多方对账的操作，通常是在一天的业务结束之后，第二天营业之前，找到不一致的数据再进行手工平账，实现最终一致。

消息的顺序性

比如：1.发表微博；2.发表评论；3.删除微博。顺序不能颠倒。

在RabbitMQ 中，一个队列有多个消费者时，由于不同的消费者消费消息的速度是不一样的，顺序无法保证。只有一个队列仅有一个消费者的情况才能保证顺序消费（不同的业务消息发送到不同的专用的队列）。