批量删除队列
删除以hello开头的queue
由于list_queues会列出队列名称以及对应的消息数目，需要过滤掉消息数目，配合awk命令只取第1列
rabbitmqctl list_queues| grep ^hello | awk '{print $1}' | xargs -n1 rabbitmqctl delete_queue
使用过期策略删除队列
# 设置规则
rabbitmqctl set_policy delete_gen "amq.gen-.*" '{"expires":1}' --apply-to queues
# 取消规则
rabbitmqctl clear_policy delete_ge
也可以在 UI 界面上 Admin 中进行操作，注意添加完毕后删除策略
使用手动 ACK 而不是 自动 ACK
自动 ACK 时，只要消息被消费者接收就会进行 ACK，若消息处理中途宕机，无法再次处理该消息，相当于丢失处理一条消息
nack 时 requeue 不要设置为 true
假设某消息队列有三个消费者，每个消费者 Qos 均为 5，那么假设有一个消息消费失败，则 nack 且 requeue 该消息，若随后依然消费失败，就构成 消费失败-requeue-消费失败的循环，如果有15个这样的消息，就会阻塞所有消费者，导致队列消息堆积
消费者预取若干消息，这些消息便不计入ready消息总数，不会被其它消费者获取
若获取到这些消息的消费者没有ack，随后断开连接，那么这些消息恢复为ready状态数据，注意ack之前消息并没有被从队列中删除
- 假定有两个消费者，每个消费者qos均为3
- 假设队列中有10条消息，编号为0-9，入队顺序为0-9
- 假定消费者永远不ack
- 先启动A消费者，随后A消费者从队列获取0-2消费，然后A消费者阻塞
- 然后启动B消费者，随后B消费者从队列获取3-5消费，然后B消费者阻塞
- 此时队列中还有10条消息，但是ready消息为6789
- 随后A消费者崩溃，0-2消费从untrack变为ready，所以队列中ready消息顺序为0126789
- 随后B消费者崩溃，3-5消息从untrack变为ready，所以队列中ready消息顺序为0123456789
消费者宕机后，消息不是重新入队而是从untrack变为ready，当然重新投递标记为被置为True，在队列中的顺序还是原来的顺序
reject和Nack的差别只有一种 ：reject一次只能拒绝一条消息，Nack支持批量拒绝。
nack时，若requeue为false，这条消息会进入死信队列，若requeue为true，那么就是消息状态从untrack恢复到ready，顺序还是原来的顺序
- 假定有一个消费者，消费者qos为3
- 假设队列中有10条消息，编号为0-9，入队顺序为0-9
- 假定消费者永远reject
- 则会发现该消费者循环的在reject012三条消息
- 若消费者宕机，则队列中ready消息顺序还是0123456789