kafkatopic数量上限_彻底搞懂Kafka消息⼤⼩相关参数设置的
规则
送礼的学问前段时间接到⽤户要求，调整某个主题在 Kafka 集群消息⼤⼩为 4M。
根据 Kafka 消息⼤⼩规则设定，⽣产端⾃⾏将 quest.size 调整为 4M ⼤⼩，Kafka 集群为该主题设置主题级别参数
以上是针对 Kafka 2.2.x 版本的设置，需要注意的是，在某些旧版本当中，还需要调整相关关联参数，⽐如 replica.fetch.max.bytes 等。
从上⾯例⼦可看出，Kafka 消息⼤⼩的设置还是挺复杂的⼀件事，⽽且还分版本，需要注意的参数巨多，⽽且每个都长得差不多，不但分版本，还需要注意⽣产端、broker、消费端的设置，⽽且还要区分 broker 级别还是 topic 级别的设置，⽽且还需要清楚知道每个配置的含义。
本⽂通过相关参数的解析说明，再结合实战测试，帮助你快速搞明⽩这些参数的含义以及规则。
broker
broker 关于消息体⼤⼩相关的参数主要有 message.max.bytes、replica.fetch.min.bytes、replica.fetch.max.bytes、
spon.max.bytes
1、message.max.bytes
Kafka 允许的最⼤ record batch size，什么是 record batch size ？简单来说就是 Kafka 的消息集合批次，⼀个批次当中会包含多条消息，⽣产者中有个参数 batch.size，指的是⽣产者可以进⾏消息批次发送，提⾼吞吐量，以下是 message.max.bytes 参数作⽤的源码：
kafka.log.Log#analyzeAndValidateRecords
以上源码可以看出 message.max.bytes 并不是限制消息体⼤⼩的，⽽是限制⼀个批次的消息⼤⼩，所以我们需要注意⽣产端对于
batch.size 的参数设置需要⼩于 message.max.bytes。
以下附带 Kafka 官⽅解释：
The largest record batch size allowed by Kafka. If this is incread and there are consumers older than 0.10.2, the consumers' fetch size must also be incread so that the they can fetch record batches this large.
In the latest message format version, records are always grouped into batches for efficiency. In previous message format versions, uncompresd records are not grouped into batches and this limit only applies to a single record in that ca.
This can be t per topic with the topic ssage.bytes config.
翻译如下：
Kafka 允许的最⼤记录批量。如果增加此数量，并且有⼀些消费者的年龄⼤于 0.10.2，则消费者的获取⼤⼩也必须增加，以便他们可以获取如此⼤的记录批次。
在最新的消息格式版本中，为了提⾼效率，始终将记录分组。在以前的消息格式版本中，未压缩的记录不会分组，并且在这种情况下，此限制仅适⽤于单个记录。
可以使⽤主题级别 “ssage.bytes” 配置针对每个主题进⾏设置。
2、replica.fetch.min.bytes、replica.fetch.max.bytes、spon.max.bytes
kafka 的分区如果是多副本，那么 follower 副本就会源源不断地从 leader 副本拉取消息进⾏复制，这⾥也会有相关参数对消息⼤⼩进⾏设置，其中 replica.fetch.max.bytes 是限制拉取分区中消息的⼤⼩，在 0.8.2 以前的版本中，如果 replica.fetch.max.bytes <
message.max.bytes，就会造成 follower 副本复制不了消息。不过在后⾯的版本当中，已经对这个问题进⾏了修复。
replica.fetch.max.bytes 参见 2.2.x 版本的官⽅解释：夺目的近义词
The number of bytes of messages to attempt to fetch for each partition. This is not an absolute maximum, if the first record batch in the first non-empty partition of the fetch is larger than this value, the record batch will still be returned to ensure that progress can be made. The maximum record batch size accepted by the broker is defined via
message.max.bytes (broker config) ssage.bytes (topic config).
翻译如下：
尝试为每个分区获取的消息的字节数。这不是绝对最⼤值，如果获取的第⼀个⾮空分区中的第⼀个记录批处理⼤于此值，那么仍将返回记录批处理以确保进度。 代理接受的最⼤记录批处理⼤⼩是通过 message.max.bytes(代理配置)或 ssage.bytes(主题配置)定义的。
replica.fetch.min.bytes、spon.max.bytes 同理。
topic
1、ssage.bytes
该参数跟 message.max.bytes 参数的作⽤是⼀样的，只不过 ssage.bytes 是作⽤于某个 topic，⽽ message.max.bytes 是作⽤于全局。
producer
1、quest.size
该参数挺有意思的，看了 Kafka ⽣产端发送相关源码后，发现消息在 append 到 RecordAccumulator 之前，会校验该消息是否⼤于quest.size，具体逻辑如下：
org.apache.kafka.clients.producer.KafkaProducer#ensureValidRecordSize
从以上源码得出结论，Kafka 会⾸先判断本次消息⼤⼩是否⼤于 maxRequestSize，如果本次消息⼤⼩ maxRequestSize，则直接抛出异常，不会继续执⾏追加消息到 batch。
并且还会在 Sender 线程发送数据到 broker 之前，会使⽤ quest.size 限制发送请求数据的⼤⼩：
org.apache.kafka.clients.producer.internals.Sender#ndProducerData
也就是说，quest.size 参数具备两个特性：
1)限制单条消息⼤⼩
2)限制发送请求⼤⼩
参见 2.2.x 版本的官⽅解释：
The maximum size of a request in bytes. This tting will limit the number of record batches the producer will nd in a single request to avoid nding huge requests. This is also effectively a cap on the maximum record batch size. Note that the rver has its own cap on record batch size which may be different from this.
翻译如下：
请求的最⼤⼤⼩(以字节为单位)。此设置将限制⽣产者将在单个请求中发送的记录批数，以避免发送⼤量请求。这实际上也是最⼤记录批次⼤⼩的上限。请注意，服务器对记录批⼤⼩有⾃⼰的上限，该上限可能与此不同。
2、batch.size
鸡爪batch.size 是 Kafka producer ⾮常重要的参数，它的值对 Producer 的吞吐量有着⾮常⼤的影响，因为我们知道，收集到⼀批消息再发送到 broker，⽐每条消息都请求⼀次 broker，性能会有显著的提⾼，但 batch.size 设置得⾮常⼤⼜会给机器内存带来极⼤的压⼒，因此需要在项⽬中合理地增减 batch.size 值，才能提⾼ producer 的吞吐量。
org.apache.kafka.clients.producer.internals.RecordAccumulator#append
以上，将消息追加到消息缓冲区时，会尝试追加到⼀个 ProducerBatch，如果 ProducerBatch 满了，就去缓存区申请 batch.size ⼤⼩的缓存创建⼀个新的 ProducerBatch 继续追加消息。需要注意的是，如果消息⼤⼩本⾝就⽐ batch.size ⼤，这种情况每个 ProducerBatch 只会包含⼀条消息。
最终 RecordAccumulator 缓存区看起来是这样的：
参见 2.2.x 版本的官⽅解释：
The producer will attempt to batch records together into fewer requests whenever multiple records are being nt to the same partition. This helps performance on both the client and the rver. This configuration controls the default batch size in bytes.
No attempt will be made to batch records larger than this size.
苍术的功效
Requests nt to brokers will contain multiple batches, one for each partition with data available to be nt.
A small batch size will make batching less common and may reduce throughput (a batch size of zero will disable
batching entirely). A very large batch size may u memory a bit more wastefully as we will always allocate a buffer of the specified batch size in anticipation of additional records.
横琴岛翻译如下：
每当将多个记录发送到同⼀分区时，⽣产者将尝试将记录⼀起批处理成更少的请求。这有助于提⾼客户端和服务器的性能。此配置控制默认的批处理⼤⼩(以字节为单位)。
不会尝试批处理⼤于此⼤⼩的记录。
发送给代理的请求将包含多个批次，每个分区⼀个，并包含可发送的数据。
较⼩的批处理量将使批处理变得不那么普遍，并且可能会降低吞吐量(零的批处理量将完全禁⽤批处理)。⾮常⼤的批处理⼤⼩可能会浪费⼀些内存，因为我们总是在预期其他记录时分配指定批处理⼤⼩的缓冲区。
那么针对 quest.size 、batch.size 之间⼤⼩的调优就尤其重要，通常来说，quest.size ⼤于 batch.size，这样每次发送消息通常会包含多个 ProducerBatch。
consumer
八月份出生的是什么星座
1、fetch.min.bytes、fetch.max.bytes、max.partition.fetch.bytes
1)fetch.max.bytes
参见 2.2.x 版本的官⽅解释：
The maximum amount of data the rver should return for a fetch request. Records are fetched in batches by the consumer, and if the first record batch in the first non-empty partition of the fetch is larger than this value, the record batch will still be returned to ensure that the consumer can make progress. As such, this is not a absolute maximum.
The maximum record batch size accepted by the broker is defined via message.max.bytes (broker config) or
翻译如下：
服务器为获取请求应返回的最⼤数据量。使⽤者将批量获取记录，并且如果获取的第⼀个⾮空分区中的第⼀个记录批次⼤于此值，则仍将返回记录批次以确保使⽤者可以取得进展。因此，这不是绝对最⼤值。代理可接受的最⼤记录批处理⼤⼩是通过“
message.max.bytes”(代理配置)或“ ssage.bytes”(主题配置)定义的。请注意，使⽤者并⾏执⾏多个提取。
fetch.min.bytes、max.partition.fetch.bytes 同理。
实战测试
螃蟹简笔画图片
针对以上相关参数配置的解读，还需要对 quest.size、batch.size、message.max.bytes(或者 ssage.bytes)三个参数进⼀步验证。
1、测试消息⼤于 quest.size 是否会被拦截
设置：
record-size = 2000
新年贺卡怎么做使⽤ kafka-producer-perf-test.sh 脚本测试：
$ {kafka_path}/bin/kafka-producer-perf-test.sh --topic test-topic2 --num-records 500000000000 --record-size 20000 --throughput 1 --producer-props boot 测试结果：
可以得出结论，成功拦截了⼤于 quest.size 的消息。
2、测试 ssage.bytes 参数⽤于校验批次⼤⼩还是校验消息⼤⼩
设置：
record-size = 500
batch.size = 2000
linger.ms = 1000
使⽤ kafka-producer-perf-test.sh 脚本测试：
$ {kafka_path}/bin/kafka-producer-perf-test.sh --topic test-topic1 --num-records 500000000000 --record-size 500 --throughput 5 --producer-props bootstr 测试结果：
当 ssage.bytes = 2500 时：
可以得出结论，ssage.bytes 参数校验的是批次⼤⼩，⽽不是消息⼤⼩。
3、测试消息⼤⼩⽐ batch.size 还⼤的情况下，是否还会发送消息，当 ssage.bytes 参数⼩于消息⼤⼩时，是否会报错
