3.9. 处理大型消息大小

消息的默认批处理大小是 1MB，这是大多数用例中最大吞吐量的最佳选择。假设有足够的磁盘容量，Kafka 可以在较低的吞吐量中容纳较大的批处理。

大型消息大小以四种方式处理：

建议使用基于参考的消息和消息压缩选项，并涵盖了大多数情况。对于其中任何这些选项，必须小心谨慎，以避免引入性能问题。

压缩还会在消费者上增加生产者和解压缩开销的额外处理开销，但在消息数据压缩时包含更多的数据，因此当消息数据压缩时，吞吐量通常很有用。

将制作者侧压缩与批处理大小的精细调节相结合，以促进最优吞吐量。使用指标有助于衡量所需的平均批处理大小。

图 3.4. 基于参考的消息传递流程

当传递消息需要更多行时，端到端延迟会增加。在清理 Kafka 消息时，这个方法的另一个缺陷是不自动清理外部系统数据。混合方法只是将大型消息发送到数据存储并直接处理标准消息。

如果消息太大，生产客户端应用程序必须对数据进行序列化和块。然后，生产者会使用 Kafka ByteArraySerializer，或者类似，在发送每个块前再次对每个块进行序列化。消费者跟踪消息和缓冲块，直到它有完整的消息。消耗的客户端应用程序接收块，这些块会在进行反序列化前编译。根据每个块消息集合的第一个或最后一个块偏移，将完整消息传送到消耗的应用程序的其余部分中。对偏移元数据检查成功发送完整消息，以避免在重新平衡期间重复。

图 3.5. 内联消息传递流

内联消息传递因为需要缓冲而具有性能开销，特别是并行处理一系列大型消息时。大量消息的块可能会变得交集，因此如果缓冲区中另一个大消息的块都不完整，则无法始终提交消息块。因此，缓冲通常受到持久性消息块或实施提交逻辑的支持。

代理将拒绝任何大于通过 message. max.bytes 设置的消息。producers 的缓冲区大小(max.request.size)和使用者(message.max.bytes)必须能够容纳较大的消息。