开发中使用RabbitMQ的手动确认机制

• 使用消息队列处理消息的时候，我们可能会遇到以下问题：

1. 消息处理失败
2. 消息体本身有误
3. 消息重复处理
4. 消息丢失

• 对于消息处理失败，有可能有由于网络波动导致的数据处理异常，待网络稳定时消息就会正常处理，对于这种处理失败，我们应该继续尝试去处理消息。
• 消息体本身有误，这会导致消息连续处理失败，占用较多的资源，写大量的无用日志，这种错误应该丢弃这部分无用消息，但要记录下日志，记清消息体本身数据，以及丢弃消息的原因。
• 消息重复处理，例如我们通过消息队列向数据库中添加数据，由于数据库网络波动，导致数据库连接超时，而我们的系统认为消息处理失败，就会把消息回滚到消息队列，继续尝试处理，这时就会造成消息重复处理的现象，对于重要的消息，我们可以每处理一条消息，就记录一下，处理新的消息时，进行判断消息是否已经处理，如果已经处理，就丢弃消息。

• 经过开发中的实际测试，当消息回滚到消息队列时，这条消息不会回到队列尾部，而是仍是在队列头部，这时消费者会立马又接收到这条消息，进行处理，接着抛出异常，进行 回滚，如此反复进行。这种情况会导致消息队列处理出现阻塞，消息堆积，导致正常消息也无法运行。对于消息回滚到消息队列，我们希望比较理想的方式时出现异常的消息到 达消息队列尾部，这样既保证消息不会丢失，又保证了正常业务的进行，因此我们采取的解决方案是，将消息进行应答，这时消息队列会删除该消息，同时我们再次发送该消息 到消息队列，这时就实现了错误消息进行消息队列尾部的方案。

• 对于第三条中的解决方案会存在一个问题，如果一个消息体本身有误，会导致该消息体，一直无法进行处理，而服务器中刷出大量无用日志。解决这个问题可以采取两种方案
  1.分清异常，哪些是可以恢复的异常，哪些是不可以恢复的异常。对于可以恢复的异常重发消息到队列尾部，对于不可以处理的异常，我们采用记录日志，直接丢弃该消息方案。
  2.记录重试次数，当到达阀值，拒绝处理消息，但需要记录详细的日志。

• 使用手动应答消息，有一点需要特别注意，那就是不能忘记应答消息，因为对于RabbitMQ来说处理消息没有超时，只要不应答消息，他就会认为仍在正常处理消息，导致消息队列出现阻塞，影响业务执行。

开发中使用RabbitMQ的手动确认机制