这么做吞吐量更高。 当出产者发送大量动静时候RabbitMQ会将压力通报到TCP毗连上，假如利用同一个毗连消费动静大概会得不到确认动静。
大量毗连与通道会影响RabbitMQ打点节制台的机能RabbitMQ会收罗每个毗连与通道的指标数据并阐明，然后在节制台展示，大量的毗连与通道会对节制台有较大压力。
Acknowledgements and Confirms动静在传输进程中大概会丢失（如毗连间断），这时候就需要重传。确认动静用于奉告客户端与处事端何时重传动静。客户端需要发送确认动静当收到动静、可能对付重要动静是动静被处理惩罚后。动静确认对机能也有影响，在高吞吐场景下，只管制止利用手动确认。
对付消费者，一些重要的动静，发起在动静消费逻辑处理惩罚完成后才确认，确保动静不丢失。
未确认动静 Unacknowledged messages所有未确认的动静都存储在内存中，当有大量的为确认动静时候大概会将内存耗尽。一个高效的限制未确认动静的要领是配置消费者的预提取（prefetch）动静数量。可以参考RabbitMQ的 prefect 机制。
Persistent messages and durable queues假如动静不答允丢失，需要将行列配置为 durable ，将动静配置为 persistent 。这种方法动静与行列城市耐久化到硬盘，虽然对比于 transient 动静，吞吐量会下降。
Prefetchprefetch 值用于指定一次发送几多个动静给消费者。RabbitMQ官网对 prefetch 的界说：
prefetch 的目标是使得消费者处于饱和事情状态，同时又要让消费者客户端内存缓存最少，并使得动静呆在行列中让其他消费者尽快消费。
RabbitMQ默认不设定消费者内存缓存上限，意思是一次性发送只管多的动静给消费者，动静在消费者客户端内存中缓存直到被处理惩罚。 Prefetch 限定消费者一次消费的动静数量， 所有 Prefetch 的动静城市从行列中删除，其他消费者不再可见。
Prefetch 的值对RabbitMQ的机能有影响。
过小的值会导致RabbitMQ将时间都耗费在期待发送动静与正在发送动静进程内。下图是一个 Prefetch 配置过小，导致时间都耗费在网络传输上的例子：消费者处理惩罚动静只用了5ms，可是吸收动静，确认动静却淹灭了120ms。
过大的值会导致一个消费者取走了所有动静很是忙碌，其他消费者没有动静可处理惩罚空闲期待的现象。
消费者很少且动静处理惩罚很快：prefetch 配置尽大概大；
消费者许多且动静处理惩罚很快：prefetch 配置较小；比 “消费者很少且动静处理惩罚很快” 场景要小
消费者许多且动静处理惩罚很慢：prefetch 配置为1；这样尽大概将动静漫衍给差异的消费者处理惩罚
需要留意的是，假如消费者配置了自动确认动静消费，那么 prefetch 是无效的。
常见的错误做法是不设定 prefetch 的值，这种环境下会导致一些消费者撑死，一些消费者饿死。
HiPEHiPE(High Performance Erlang)开启之后可以晋升吞吐量，负面影响是增加启动时间；开启了 HiPE 之后，RabbitMQ会在启动时候编译，开启 HiPE 后机能会有 20%~80% 的晋升，启动时长会增加 1~3 分钟。
Disable unused plugins插件会耗损CPU与内存，禁用不需要的插件。
Do not set RabbitMQ Management statistics rate mode to detailed in productionSetting RabbitMQ Management statistics rate mode to detailed has a serious performance impact and should not be used in production.
Use updated RabbitMQ client libraries确保你利用的SDK是最新的不变版本。
Use latest stable RabbitMQ and Erlang version利用最新不变的RabbitMQ与Erlang版本。
Use TTL with caution死信投递与TTL是两个风行的特性，可是这两个特性对机能会有影响，在利用时候凡是容易忽视这点。
死信投递行列配置了 x-dead-letter-exhcange 属性将会吸收到被拒绝的、或超时的动静。动静配置了 x-dead-letter-routing-key 后 routing key 将会在死信投递后被改变。