平均邮件大小很小,但是大小不同。
我的问题。
谢谢。
答案 0 :(得分:2)
下面是有问题的相关配置的定义
生产者配置
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。
答案 1 :(得分:0)
出现此查询是因为批处理有各种可用设置。让我试着把它们说清楚:
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,我们指示生产者等待几毫秒在将附加消息发送到代理之前向批处理添加额外的消息,即使发送者线程可用。这会增加延迟,但也会增加吞吐量(因为我们一次发送更多消息,每条消息的开销更少)。