RabbitMQ常见问题持续汇总

这篇文章主要是汇总一些杂七杂八的问题，核心内容参考前三章节

RabbitMQ系列文章
深入RabbitMQ世界：探索3种队列、4种交换机、7大工作模式及常见概念
不止于纸上谈兵，用代码案例分析如何确保RabbitMQ消息可靠性？
不止于方案，用代码示例讲解RabbitMQ顺序消费
RabbitMQ常见问题持续汇总

消息分发

不公平分发

RabbitMQ 默认分发消息采用的轮训分发，但是在某种场景下这种策略并不是很好，比方说有两个消费者在处理务，其中有个消费者 1 处理任务的速度非常快，而另外一个消费者 2 处理速度却很慢，这个时候我们还是采用轮训分发的化就会到这处理速度快的这个消费者很大一部分时间处于空闲状态，而处理慢的那个消费者一直在干活，这种分配方式在这种情况下其实就不太好，但是RabbitMQ 并不知道这种情况它依然很公平的进行分发。

为了避免这种情况，我们可以设置参数 channel.basicQos(1); 意思就是如果这个任务我还没有处理完或者我还没有应答你，你先别分配给我，我目前只能处理一个任务，然后 rabbitmq 就会把该任务分配给没有那么忙的那个空闲消费者，当然如果所有的消费者都没有完成手上任务，队列还在不停的添加新任务，队列有可能就会遇到队列被撑满的情况，这个时候就只能添加新的 worker 或者改变其他存储任务的策略。

限流-basic.qos

通过使用 basic.qos 方法设置“预取计数”值来完成的。该值定义通道上允许的未确认消息的最大数量。100 到 300 范围内的值通常可提供最佳的吞吐量，并且不会给消费者带来太大的风险。预取值为 1 是最保守的。

prefetch默认值以前是1，这可能会导致高效使用者的利用率不足。从spring-amqp 2.0版开始，默认的prefetch值是250，这将使消费者在大多数常见场景中保持忙碌，从而提高吞吐量。

basic.qos 是 RabbitMQ 的一个方法，用于设置消息消费的流控（Quality of Service, QoS）。具体来说，它允许你限制在消费者确认（acknowledge）消息之前，RabbitMQ 能够推送给该消费者的消息数量。这样可以防止消费者因为处理不过来而被淹没在大量未处理的消息中。

 com.rabbitmq.client.Channel#basicQos(int, int, boolean)	
	/**
     * 请求对此通道应用特定的prefetchCount“服务质量”设置
     *
     * @param prefetchCount 服务器将交付的最大消息数，如果不限制则为0
     * @throws java.io.IOException 如果遇到错误
     * 
     * 注意: 该方法是基本服务质量机制的一部分，用于流量控制
     * 客户端可以通过设置prefetchCount来避免被服务器压垮
     */
void basicQos(int prefetchCount) throws