|
（一）在使用 RabbitMQ 的时，作为消息发送方希望安全可靠的将消息发送到中间件。
RabbitMQ 提供了两种方式来控制消息的投递可靠性。
- confirm 确认模式：消息从 producer 到 exchange 会返回一个 confirmCallback 。
- return? 退回模式：消息从 exchange 到?queue 投递失败时才，会返回一个returnCallback 。
（RabbitMQ也支持事务，但是性能较差，一般不用）
（二）除了生产方发送到中间件的可靠保证，还需要接收方获取消息的可靠保证。
消费端确认 ack。表示消费端收到消息后的确认方式。
有三种确认方式：
?自动确认：acknowledge="none"
?手动确认：acknowledge="manual"
?根据异常情况确认：acknowledge="auto"，（这种方式使用麻烦，不作讲解）
其中自动确认是指，当消息一旦被Consumer接收到，则自动确认收到，并将相应 message 从 RabbitMQ 的消息缓存中移除。
但是在实际业务处理中，很可能消息成功接收到，但是业务处理出现异常，那么该消息就会丢失。如果设置了手动确认方式，则需要在业务处理成功后，调用channel.basicAck()，手动签收，如果出现异常，则调用channel.basicNack()方法，可以让其重新发送消息。
（三）消息在Broker中，是暂存在内存中的，如果Consumer还没来得及消费，Broker挂掉了，导致的消息丢失问题怎么解决？
设置持久化，以保证即使Broker挂掉，服务重启后消息依然会恢复，
- ?将Exchange设置为持久化的；
- ?将Queue设置为持久化的；
- ?将message设置为持久化的。
但这里还有个问题，设置了持久化的消息存入Broker之后，还需要一段时间才能存入磁盘（虽然很短，但不能忽视），因为Broker并不会为每条消息都实时同步存盘，如果这个很短的时间内发生宕机、异常、重启等情况，消息也会丢失，解决办法是引入"RabbitMQ的镜像队列"（RabbitMQ集群，Master挂了Slave会换上去充当Master）。
|