RMQ线上集群（v3.6.12）purge一个大量消息堆积（100W+）的队列时，有可能导致客户端报大量发送超时异常。
原因
purge操作实际发生的事情（rabbit_amqqueue_process.erl）：
handle_call(purge, _From, State = #q{backing_queue = BQ,
backing_queue_state = BQS}) ->
{Count, BQS1} = BQ:purge(BQS),
...
BQ默认对应 rabbit_variable_queue 模块：
msg_store_remove(MSCState, IsPersistent, MsgIds) ->
with_immutable_msg_store_state(
MSCState, IsPersistent,
fun (MCSState1) ->
rabbit_msg_store:remove(MsgIds, MCSState1)
end).
也就是purge操作，最终是由rabbit_msg_store进程来进行操作的。
rabbit_msg_store 进程，每个节点只有一个，因此容易成为瓶颈。
rabbitmq 进程间通信采用 credit_flow 机制，一般一条持久化消息发送到持久化队列的大致过程如下：
rabbit_reader → rabbit_channel → rabbit_amqqueue_process → rabbit_msg_store
当 rabbit_msg_store 进程忙于大量消息的purge操作时，不能及时处理其上游 rabbit_amqqueue_process 的消息，这会导致其上游 rabbit_amqqueue_process 很快耗光其 credit 值，从而造成 flow。同理，
当 rabbit_amqqueue_process 进程由于 flow 被 block 住，不能及时处理其上游 rabbit_channel 的消息，导致 rabbit_channel 很快耗光其 credit 值，也造成 flow。最终限流状态会一直追溯到最上层 connection。
此时客户端发送会卡顿（表现出等待confirm超时等异常）
因此，对于线上有业务量的RMQ集群，如果有大量消息堆积的队列需要清理，最好不要直接purge，有可能对线上业务造成影响。
规避
最保险的清理方式，起 Consumers 消费（接收即丢弃）
附 rabbit_msg_store 进程有关的线上问题：
线上业务集群节点 TcpExt.pruneCalled 指标报警，同时发现有一队列处于flow状态，进而判断持久化进程 rabbit_msg_store 出现瓶颈，通过 sar 工具发现以下异常：
最终定位到节点对应的宿主机底层IO有问题，及时进行规避。
参考
Finding bottlenecks with RabbitMQ 3.3
Purge a large queue is slow
