注：这篇文章会随时添加新的内容，就是将RabbtiMQ中的概念添加到这里。助力大家的学习
自动ACK和手动ACK的区别
自动ACK和手动ACK是消息队列中两种不同的消息确认机制，它们在消息处理的可靠性和灵活性方面存在显著差异。
自动ACK（Auto Acknowledgment）：
- 定义：当消费者接收到消息后，RabbitMQ会自动发送ACK信号给消息代理，表示消息已被确认并可以删除。
- 优点：
- 简单直接：消费者无需显式调用ACK方法，系统自动处理，减少了代码复杂度和出错的可能性。
- 性能优势：在高并发场景下，自动ACK可以减少交互次数，提升吞吐量，使系统运行更流畅。
- 缺点：
- 消息丢失风险：如果消费者在处理消息过程中宕机或出现异常，消息可能会被自动删除，导致数据丢失。
- 缺乏控制：无法灵活地控制消息的确认时机，可能无法满足某些严格的业务需求。
手动ACK（Manual Acknowledgment）：
- 定义：消费者需要显式调用ACK方法来确认消息已经成功处理完毕，才能通知消息代理删除消息。
- 优点：
- 高可靠性：只有在消息处理成功后，消费者才会发送ACK信号，确保消息不会因宕机或其他原因丢失。
- 灵活性：允许在业务逻辑完成后才进行确认，适合需要严格控制消息处理流程的场景。
- 缺点：
- 复杂性：需要在代码中显式调用ACK方法，增加了代码的复杂性和出错风险。
- 性能影响：由于需要显式确认，可能会增加系统交互次数，降低吞吐量。
适用场景：
- 自动ACK：适用于对消息丢失容忍度较高的场景，如日志记录等。
- 手动ACK：适用于对消息处理可靠性要求较高的场景，如金融交易、订单处理等。
在配置文件中开启的代码：
listener:simple:acknowledge-mode: manual #开启手动ackprefetch: 10 #设置流控
RabbitMQ中的Return机制和Confirm机制
在RabbitMQ中，Confirm机制和Return机制是确保消息可靠传输的重要工具。下面详细解释这两种机制的功能和实现方式。
Confirm机制
Confirm机制主要用于确认消息是否成功到达交换机（Exchange）。当生产者发送消息后，通过开启Confirm模式，可以监听消息是否被交换机接收。如果消息成功到达交换机，RabbitMQ会返回一个确认信号（ACK），表示消息接收成功；反之，如果消息未能到达交换机，RabbitMQ会返回一个否定确认信号（NACK），表示消息接收失败。
具体来说，Confirm机制的实现步骤如下：
- 开启Confirm模式：生产者需要在信道上开启Confirm模式，通常通过调用
channel.confirmSelect()方法来实现。 - 添加监听器：生产者需要添加一个Confirm回调监听器，如
addConfirmListener，以便在消息成功或失败时进行相应的处理。 - 处理确认结果：当消息成功到达交换机时，会触发Confirm回调，返回ACK；如果消息未能到达交换机，则返回NACK。
Confirm机制的主要优点是能够保证消息至少被交换机接收，但并不保证消息能够路由到指定的队列中。因此，如果需要进一步确保消息能够正确路由到队列，还需要结合Return机制。
Return机制
Return机制用于处理那些未能成功路由到指定队列的消息。当消息通过交换机但未能匹配到任何队列时，RabbitMQ会将这些消息返回给生产者。这使得生产者能够对这些不可达的消息进行后续处理，如重新发送或记录日志。
Return机制的实现步骤如下：
- 开启Return机制：在发送消息时，需要设置
mandatory参数为true，这样当消息无法路由到队列时，RabbitMQ会将消息返回给生产者。 - 添加Return监听器：生产者需要添加一个Return回调监听器，如
addReturnListener，以便在消息返回时进行处理。 - 处理不可达消息：当消息未能路由到队列时，会触发Return回调，返回包含错误信息、交换机名称、路由键等信息的回调。
Return机制确保了即使消息未能成功路由到队列，也不会丢失，而是能够被生产者捕获并处理。
Confirm与Return的区别和联系
- 区别：Confirm机制主要关注消息是否到达交换机，而Return机制则关注消息是否能够路由到指定的队列。
- 联系：两者都是为了提高消息传递的可靠性。通常在实际应用中，两者会结合使用，以确保消息不仅到达交换机，还能正确路由到队列。
通过以上机制，RabbitMQ能够提供更强大的消息传递保障，确保消息在生产者和消费者之间的可靠传输。