最近写了一篇关于 RabbitMQ 的分析文章，公司小伙伴对如下说法存有异议：

消息大小越小越能降低延迟，提高消息速率；而将小消息合并成大消息进行处理，能够增大吞吐量；

核心问题在于：将小消息合并为大消息进行处理，是否能够增大吞吐量，以及适用的场合是什么；

我的观点为：采用批处理对提高吞吐量是有好处的，原因在于可以大大减少网络通信；但是否适合采用批处理方式，则需要区分具体的使用场景；

举例：假如我要发送 100 条消息，当按照一次一条的方式处理时，整体耗时一定是高于将 100 条消息打包后一次性进行发送的耗时的；但是，如果你的关注点在于“某一条消息的延迟”，那么对于“某一条消息”来说，由于批处理而导致的延迟可能会更大一些；

另外，可以参考下 Amazon Simple Queue Service 关于批处理的，内容摘录如下：

Amazon SQS API 中的批处理操作可通过一次处理多达 10 条消息来进一步优化吞吐量。

批处理的基本理念是：在与服务的每次往返操作中执行更多工作，以及在批处理请求的多条消息中分配批处理操作的延迟时间，而不是接受单一消息的整个延迟时间。由于每次往返操作都会执行更多工作，因此，批处理请求可以更高效地使用线程和连接，从而提高吞吐量。Amazon SQS 按请求收费，因此，如果由更少的请求来处理等量的消息，则费用可以大幅降低。此外，更少的线程和连接可以降低客户端资源使用率，并且可以通过使用更小或更少的主机执行相同的工作来降低客户端费用。

不过，批处理确实会让应用程序变得有点复杂。例如，应用程序必须先积累消息，然后才能发送消息，并且有时候必须花费较长的时间来等待响应，但是批处理在以下情况下可能很有效：

• 您的应用程序正在短时间内生成大量消息，因此，延迟时间决不会很长。
• 消息使用者从队列中自行获取消息，这与典型的消息创建者相反，后者需要发送消息来响应它们无法控制的事件。

重要：即使批处理中单独的消息失败了，批处理请求也可能会成功。在提出批处理请求后，您应始终检查各条消息是否失败了，并在必要时重试。

另外一个需要提及的点是，RabbitMQ 中涉及到批处理的地方有两处：

• Consumer 侧 Acknowledging Multiple Deliveries at Once；
• Producer 侧使用 Publisher confirm 机制时，若 broker 设置 basic.ack 中 multiple 域为 true ；

差别在于：consumer 侧的批处理功能，需要业务自己实现相应逻辑，而 producer 侧的批处理功能，只需要理解 RabbitMQ 实现的批处理逻辑；

详见官网说明：；