RabbitMQ–基础–11.1–持久化，消息的保障机制，生产者确认机制，消费者处理消息的模式
1、持久化
- 交换机的持久化
- 队列的持久化
- 消息的持久化
1.1、交换机的持久化
RabbitMQ服务重启，若交换机不设置持久化，交换机的元数据会丢失，消息不会丢失，不过消息再也不能发送到这个交换机中了
1.2、队列的持久化
RabbitMQ服务重启，若队列不设置持久化，元数据会丢失，数据也会丢失
1.3、消息的持久化
设置所有的消息持久化，可靠性会大大提高，可是对于性能上是一个巨大的影响，这是一个可靠性和吞吐量之间做一个权衡
2、队列中传输消息的保障机制
- 消息的传输保障，对于一般的消息中间件来说，会考虑这三个层级
- 最多一次
- 最少一次
- 恰好一次
- RabbitMQ 支持最多一次和至少一次，无法保障 恰好一次
2.1、最多一次
消息可能会丢失，但不会重复
2.1.1、最多一次 的实现需要考虑以下几个方面
- 生产者需要开启事务机制 或者 确认机制，以确保消息可以可靠地传输到 RabbitMQ 中
- 生产者需要配合使用备份交换机来确保消息能够从交换机路由到队列中，进而能够保存下来而不会被丢弃
- 消息和队列都需要进行持久化处理，以确保 RabbitMQ 服务器在遇到异常情况时不会造成消息丢失
- 消费者在消费消息的同时需要将autoAck设置为 false，然后通过手动确认的方式去确认已经正确消费的消息，以避免在消费端引起不必要的消息丢失。
2.2、最少一次
- 消息可能会重复，但不会丢失
- 生产者随意发送，消费者随意消费
2.3、恰好一次
- 每条消息一定只会被传输一次
2.3.1、无法保障 恰好一次 的原因
- 消费者在消费完一条消息之后向 RabbitMQ 发送确认命令，此时由于异常原因(网络，或宕机)造成RabbitMQ并没有收到这个确认命令，RabbitMQ不会将此条消息标记删除。在重新连接之后，消费者还是会消费到这一条消息，这就造成了重复消费
- 生产者在使用 确认机制 的时候，发送完一条消息等待 RabbitMQ 返回确认通知，此时正好网络断开，生产者捕获到异常情况，为了确保消息可靠性选择重新发送，这样 RabbitMQ 中就有两条同样的消息，在消费的时候，消费者就会重复消费
3、生产者确认机制
- 事务模式
- 发送方确认模式 confirm 模式
3.1、事务模式
- 事务机制在一条消息发送之后会使发送端阻塞，以等待RabbitMQ的回应，之后才能继续放下一条消息
- 事务模式性能非常低，不建议使用。
3.2、发送方确认模式 confirm 模式
- 发送方确认机制最大的好处在于它是异步的，一旦发布一条消息，生产者就可以在等信道返回确认的同时继续发送下一条消息
- 当消息最终得到确认之后，生产者便可以通过回调方式来处理该确认消息，哪怕是 RabbitMQ 自己内部出现了错误，也会回复响应的应答给到生产者
4、消费者处理消息的模式
- 推模式：消费者正常启动程序之后，会是推模式
- 拉模式：消费者程序第一次起来的时候，是拉模式
