平均消息大小很小，但大小不同。
我的问题。
谢谢。
【问题讨论】：
标签： apache-kafka kafka-producer-api
以下是相关配置的定义
生产者配置
batch.size：生产者将尝试批处理记录，直到达到 batch.size，然后再发送到 kafka（假设 batch.size 配置为优先于 linger.ms）。默认 - 16384字节
max.request.size ：请求的最大大小（以字节为单位）。此设置将限制生产者在单个请求中发送的记录批次数，以避免发送大量请求。这也有效地限制了最大记录批量大小。默认 - 1048576 字节
代理配置
message.max.bytes ：Kafka 允许的最大记录批量大小。默认 - 1000012 字节
replica.fetch.max.bytes ：这将允许代理中的副本在集群内发送消息并确保消息被正确复制。
回答您的问题
为避免生产者发送错误，您无需将批量大小设置为 2MB，因为这会延迟小尺寸消息的传输。您可以根据平均消息大小和要批处理的数量来保留 batch.size
如果您不指定批量大小，它将采用默认值，即 16384 字节
所以基本上你必须配置生产者 'max.request.size'>=2MB 和代理 'message.max.bytes' 和 'replica.fetch.max.bytes' >=2MB。
【讨论】：
之所以会出现此查询，是因为批处理有各种可用的设置。让我试着把它们说清楚：
Kafka 设置：message.max.bytes 和 fetch.max.bytes
Kafka 代理限制了可以生成的消息的最大大小（批量消息的总大小，如果消息是批量发布的），由集群范围的属性 message.max.bytes 配置（默认为 1 MB） .尝试发送大于此值的消息的生产者将从代理收到错误消息，并且该消息将不被接受。与代理上指定的所有字节大小一样，此配置处理压缩消息大小，这意味着生产者可以发送比未压缩值大得多的消息，前提是他们将其压缩到配置的 message.max.bytes 大小下。
注意：此设置可以被特定主题覆盖（但名称为 max.message.bytes）。
在 Kafka 代理上配置的最大消息大小 message.max.bytes 必须与消费者客户端上的集群范围属性 fetch.max.bytes（默认为 1 MB）相协调。它配置尝试获取请求的消息的最大字节数。如果该值小于message.max.bytes，那么遇到较大消息的消费者将无法获取这些消息，从而导致消费者卡住无法继续。
配置设置replica.fetch.max.bytes（默认为 1MB）决定了代理上每个分区所需的粗略内存量。
制作人设置：max.request.size
此设置控制生产者发送的生产请求的大小。它限制了可以发送的最大消息的大小和生产者在一个请求中可以发送的消息数量。例如，默认最大请求大小为 1 MB，您可以发送的最大消息为 1MB，或者生产者可以将 1000 条大小为 1k 的消息批处理到一个请求中。
此外，代理对其将接受的最大消息的大小有自己的限制message.max.bytes)。让这些配置匹配通常是个好主意，这样生产者就不会尝试发送会被代理拒绝的大小的消息。
请注意message.max.bytes（代理级别）和max.requrest.size（生产者级别）对批处理中的最大请求大小设置了上限，但batch.size（应低于前两个）和linger.ms 是实际控制批处理大小的设置。
制作人设置：batch.size 和 linger.ms
当多个记录被发送到同一个分区时，生产者会将它们一起批处理。参数batch.size 控制将用于每个批次的最大内存量（以字节为单位）（而不是消息数！）。如果批次已满，则必须发送该批次中的所有消息。这有助于提高客户端和服务器的吞吐量。
小批量会使批处理不太常见，并且可能会降低吞吐量。一个非常大的大小可能会更浪费一点内存，因为我们总是会分配一个指定批量大小的缓冲区来预期额外的消息。
linger.ms（默认为 0）设置控制在发送当前批次之前等待其他消息的时间量。
默认情况下，一旦有发送者线程可以发送消息，生产者就会发送消息，即使批处理中只有一条消息（注意batch.size 仅指定批处理大小的最大限制)。通过将 linger.ms 设置为高于 0，我们指示生产者等待几毫秒以将其他消息添加到批处理中，然后再将其发送到代理，即使发送者线程可用。这增加了延迟，但也增加了吞吐量（因为我们一次发送更多消息，每条消息的开销更少）。
【讨论】：