小扳手

如果消息的延迟时间设置较长，可能会导致堆积的延迟消息非常多，会带来较大的 CPU 开销，同时延迟消息的时间会存在误差。不过 SpringAMQP 提供的重试机制时阻塞式的重试，也就是说多次重试等待的过程中，当前线程式被阻塞的。该插件的原理是设计了一种支持延迟消息功能的交换机，当消息投递到交换机后可以暂存一定时间，到期后再投递到队列中。当重试失败之后，不会直接将消息丢失而是交给专门接收失败信息的交换机，再由专门的消费者进行消费，比如说监听到队列中有接收失败的信息，将其写入日志中等等处理的方法。

但是在实际开发时，队列和交换机是程序员定义的，将来项目上线，又要交给运维去创建，那么程序员就需要把程序中运行的所有队列和交换机都写下来，交给运维，在这个过程中是是很容易出错的。默认情况下，消息是平均分配每个消费者，并没有考虑到消费者的处理能力，没有充分利用每一个消费者的能力，这样显然是有问题的。Work queues，任务模型，简单来说就是让多个消费者绑定到一个队列，共同消费队列中的消息，如果直接将消息发送到队列中，则队列每一个消息只能被处理一次，每一个消息都不能被多个消费者同时消费。