在TCP传输中，接收端每次通过ACK确认消息，告诉发送端哪些序号的消息已经成功接收到并且在ACK中指定当前接收端接收缓冲区的大小，这样发送端发送的数据大小不能超过此大小，必要时（例如：由于发送端数据发送过快，导致接收端接收缓冲区窗口缩小，如果这时发送缓冲区已满）则阻塞发送端的应用程序write方法。如同TCP滑动窗口流量控制机制一样，rabbitmq也支持流量控制，当broker出现内存或磁盘资源等达到设置的阈值时，则会触发rabbitmq流量控制机制，阻塞消息生产端的connection，阻止生产者继续向broker发送消息，直到内存和磁盘资源不足警告解除，才会解除对connection的阻塞，从而实现流量控制机制。
SPI的全名为Service Provider Interface.大多数开发人员可能不熟悉，因为这个是针对厂商或者插件的。在java.util.ServiceLoader的文档里有比较详细的介绍。简单的总结下java spi机制的思想。我们系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块的方案，xml解析模块、jdbc模块的方案等。面向对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不使用实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。为了实现在模块装配的时候动态指定具体实现类，这就需要一种服务发现机制。 java spi就是提供这种功能的机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。
本篇主要介绍rabbitmq消费端Consumer的一些基本的使用特性，Consumer Cancel（取消消费者），Consumer Prefetch（设置消费者的预取数量）以及Consumer Priorities（设置消费者的优先级）等等。
在《rabbitmq 基于TTL和Dead Letter特性实现延迟队列》中，我们介绍了通过rabbitmq提供的TTL和Dead Letter特性来实现延迟队列的效果；今天我们将介绍另外一种方式来实现延迟队列 —— rabbitmq-delayed-message-exchange插件。
首先，rabbitmq并没有直接支持延迟队列这样的特性，我们必须通过rabbitmq提供的TTL（Time-To-Live：用于设置消息和队列的有效时间）和 Dead Letter（死信队列DLX ，寓意是存放那些不可送达消息的队列）这两个特性来间接的实现延迟队列的效果；接下来，将详细介绍TTL和 Dead Letter特性，以及如何使用它们来实现延迟队列的效果。
如果采用标准的AMQP协议，则唯一能够保证消息不会丢失的方式是利用其事务机制——令channel处于transactional模式、向其publish消息、执行commit动作。在这种方式下，事务机制会带来大量的多余开销，并会导致吞吐量下降250% 。为了补救事务带来的问题，引入了Publisher Confirm机制，详情参考之前的一篇博文《rabbitmq 消息可靠投递及消费机制》。