企业官网建设流程全解析

Kafka部署起来并不难，一条命令就能起一个单节点实例，但真正让它能在生产环境稳定跑起来，拼的全是对配置参数的理解。网上关于Kafka配置的文章不少，但大多是参数罗列加注释，读完好像懂了，真到自己调优时还是无从下手。这篇文章我想换个角度，从一个实际使用者的经验出发，把Kafka配置参数按"服务端、生产者、消费者、Topic"四个维度拆开，讲清楚每个关键参数背后的逻辑、它们之间的联动关系，以及在什么场景下应该怎么设置。内容不追求覆盖全部参数，而是聚焦那些真正影响可靠性、性能和日常排障的参数，适合刚入门想搭一套可用集群的人，也适合已经被线上告警逼着看配置的人。看完之后你至少能回答三个问题：这些参数控制什么、为什么要这样设计、改坏了怎么排查。

1. 配置参数的整体设计思路：先理解Kafka的三层架构

1.1 为什么不建议"背参数"，而是要建立配置坐标系

Kafka的配置项有上百个，第一次接触的人很容易被吓到。但如果你仔细去梳理，会发现它们其实围绕着同一个核心架构展开：Producer（生产者）把消息发到Broker（服务端节点），Broker负责存储和副本同步，Consumer（消费者）从Broker拉取消息进行处理。整个链路里，消息要经过"网络传输、写入磁盘、跨节点复制、读取返回"这几个环节，每一环都有对应的配置参数在约束行为和资源边界。

我比较推荐的学习方式是建立一个"配置坐标系"：横轴是数据流向（生产端、Broker存储、消费端），纵轴是你要达成的目标（可靠性、性能、稳定性）。每个参数放到这个坐标系里，它的意义就很清晰了。比如acks是生产端关于可靠性的参数，batch.size是生产端关于性能的参数，log.retention.hours是服务端关于存储的策略参数，max.poll.records是消费端关于处理节奏的参数。这样分类之后，你不会再被参数的数目吓倒，反而会看到它们之间其实是有关联的。

1.2 参数之间的联动关系：为什么不能单独看一个参数

Kafka参数设计的另一个特点就是强联动性。很多参数单独改没有任何意义，甚至会产生反效果。

举个最典型的例子。生产端的acks和min.insync.replicas就是一个联动组合。acks=all表示消息要等所有ISR副本都写入成功才算成功，但如果你没有在Broker端设置min.insync.replicas，那么当ISR里只剩一个副本时，acks=all实际上等于退化成acks=1。反过来，如果你的min.insync.replicas=2，但生产端的acks没有设置成all，这个限制也根本不会生效。只有两个参数一起搭配，才能做到"消息至少写入2个副本才算成功"的可靠性保证。

再比如生产端的linger.ms和batch.size。batch.size决定了一个批次能装多少数据，linger.ms决定了发送端等多久再发送。如果linger.ms=0，那消息会立即发送，batch.size再大也攒不起来；如果linger.ms设置得很大，又会让消息的延迟明显上升。所以这是一对需要根据业务吞吐和延迟要求一起权衡的参数，而不是各自独立去调。

消费者端也有类似的联动。session.timeout.ms和heartbeat.interval.ms必须一起看。如果心跳间隔大于会话超时时间，Broker会频繁判定消费者下线，触发无意义的Rebalance。这两者的经验比例在文档中有明确的建议：心跳间隔通常是会话超时的三分之一左右。我在线上就遇到过有人把heartbeat.interval.ms调成和session.timeout.ms一样的值，导致消费者频繁被踢出消费组，消费吞吐直接腰斩。

1.3 理解配置优先级：Topic级和Broker级的关系

还有一个容易忽略但很重要的机制：Topic级别的配置可以覆盖Broker级别的默认值。这意味着同一个参数（比如retention.ms）你既可以在server.properties里设置全局限值，也可以针对某个具体Topic单独设置。Kafka的覆盖规则是：Topic动态配置 > Broker动态配置 > Broker静态默认值。

我建议在生产环境中把通用的配置放到Broker级别，把一些有特殊需求的Topic单独管理。最常见的例子就是日志类Topic和订单类Topic的保留时间：日志数据量大但价值密度低，保留3天就够；订单数据需要追溯，保留30天甚至更久。这种情况下如果只用一个全局配置，要么浪费磁盘，要么业务不满足需求。利用Topic级覆盖，两边都能兼顾。

2. 服务端Broker核心配置：集群稳定性的地基

2.1 基础身份与存储路径配置

服务端配置是整个Kafka集群的地基，这部分配置错了，后面跑得再快也可能出大问题。我们先从最基础的看起。

broker.id是每个节点的唯一标识，集群中的每个Broker都必须有一个不重复的ID。如果你不想手动设置，也可以配置broker.id.generation.enable=true让Kafka自动生成，但生产环境还是建议手动指定，方便排查和运维。

listeners和advertised.listeners这对参数是新手最容易踩坑的地方。listeners是节点监听客户端连接的地址和端口（比如PLAINTEXT://192.168.1.10:9092），而advertised.listeners是节点对外广播的地址，客户端连接时会去拉取这个地址。在容器化或云环境下，两者经常不一致：监听地址是内网IP或容器IP，但客户端需要通过宿主机端口映射来访问。如果没有正确设置advertised.listeners，就会出现一种很典的故障：消费者进程明明连着集群，日志却一直报连接失败或超时，因为客户端拿到的是无法访问的内部地址。

log.dirs指定了Kafka数据日志的存储目录。生产环境建议把日志目录和数据盘分开，不要和系统盘放在一起。可以配置多个目录用逗号分隔，Kafka会把不同的分区数据分散存储到不同目录上，这能提升磁盘IO的并发能力。如果有条件，把log.dirs放在SSD上，对消息写入延迟的改善是非常直接的。

2.2 线程模型与网络参数

num.network.threads和num.io.threads分别控制网络线程和IO线程的数量。网络线程负责接收客户端请求和响应，IO线程负责处理请求（包括磁盘读写和副本复制等）。

这里有个容易被误解的点：线程数不是越大越好。num.io.threads的默认值是8，如果你的机器核数比较多，可以适当调大，但调到十几二十个之后性能收益就基本饱和了，反而会增加线程切换的开销。遇到过有人把IO线程调到64，结果CPU大部分时间花在上下文切换上，吞吐反而下降。在8核16G的机器上，num.network.threads=4、num.io.threads=12是一个比较稳妥的起点。

socket.send.buffer.bytes和socket.receive.buffer.bytes控制网络发送和接收缓冲区大小，默认值在100KB左右。如果集群走的是万兆网、消息体也比较大，可以适当调大到1MB左右。这个参数对性能的影响属于"锦上添花"级别，除非网络确实成了瓶颈，否则优先级不高。

2.3 消息留存与清理策略

log.retention.hours是控制消息保留时长的核心参数，默认是168小时（7天）。超过这个时间的日志会被清理线程删除。生产环境建议明确设置，不要让默认值替你拍板，因为7天对大多数业务来说不是一会长。

log.retention.bytes则是按容量来控制保留，默认是-1（不限制）。需要注意这两个参数的关系是"或"而不是"和"：只要任意一个条件满足，消息就会被清理。比如你设置了log.retention.hours=24和log.retention.bytes=1073741824（1GB），那么运行到24小时会被清，或者日志超过1GB也会被清，谁先触发谁生效。

log.segment.bytes默认是1GB，它决定了每个日志段文件的大小。日志文件是按Segment（段）存储的，消息写入当前活跃的Segment，写满后滚动到新的Segment。段越小，滚动越频繁，清理和索引的粒度越细，但产生的文件数也越多；段越大，文件数少，但如果要在段级别做删除，清理的粒度就会更粗。默认1GB在大多数场景下是合理的，除非你的单条消息特别大或写入了极多的消息，否则不需要主动调整。

2.4 副本机制和可靠性关键参数

default.replication.factor是Topic默认的副本数，生产环境建议至少设置为2。如果你有3个Broker，直接设成3也可以。副本数越大，数据冗余度越高，但写放大也越严重（每个副本都要写一遍），性能和磁盘占用都会上升。3副本是生产环境最常见的配置，兼顾了可靠性和成本。

min.insync.replicas和acks=all搭配使用。设置成2意味着：当ISR列表里的副本数小于2时，Broker会拒绝写入请求，返回NotEnoughReplicasException。这个参数是数据可靠性的最后一道闸门，宁可牺牲部分可用性，也不能让数据只写一份就假装成功。

unclean.leader.election.enable默认是false，这个默认值本身就是一个很好的安全设计。设置为false表示当Leader副本所在的节点出故障时，Kafka不允许那些没有跟上最新数据的副本成为新的Leader。这样可以避免"数据落后"的副本上位之后把旧数据当权威，造成数据丢失和混乱。但在极端场景下（比如ISR里的副本全部挂了），false会导致分区彻底不可用。所以这是一个可用性和一致性之间的取舍，生产环境建议保持false。

auto.create.topics.enable默认是true。我建议生产环境直接关掉。不关的后果是：某个客户端因为配置错误往一个不存在的Topic写入时，Kafka会自动帮你建一个默认分区数、默认副本数的Topic，数据就写进去了。等到你后面创建了正式的Topic，消息已经被写进了错误的Topic里，排查起来很头疼。设成false之后，对不存在Topic的写入会直接报错，问题能尽早暴露。

2.5 单条消息大小限制的配套调整

最后说说message.max.bytes，默认是1MB，它限制的是单个消息的最大字节数。如果你的业务会有超过1MB的消息（比如要传图片base64、大的JSON报文），这个值要调大。但这里有一个联动细节很容易忽略：服务端的message.max.bytes调整之后，生产端的max.request.size和消费端的max.partition.fetch.bytes也必须同步调整。否则会出现一种奇怪的局面：发送端认为自己能发2MB的消息，服务端也确实能收2MB，但消费者默认单次拉取的最大字节数不够，报RecordTooLargeException，消息就是消费不下来。这三个参数必须一起改，缺一个都会出问题。

3. 生产者关键参数：从"能发"到"发得可靠、发得快"

3.1 Producer基础配置

生产者的配置相对Broker来说少一些，但每个参数的作用都很突出。先说基础的：bootstrap.servers是Producer启动时用来发现集群元数据的地址列表，只需要配置集群中的部分节点地址即可，不需要把所有Broker都写上。key.serializer和value.serializer是消息键和值的序列化类，最常用的是StringSerializer，但如果你用Avro或Protobuf，就要换成对应的序列化器。

client.id是个不起眼的参数，但我建议一定要设。它是客户端在Broker端的身份标识，排障的时候能让你在日志里快速区分请求来自哪个业务系统。有一次我们排查一个集群的网络异常，就是因为所有客户端都没设置client.id，在Broker侧完全看不出请求是哪个应用发出来的，最后只能抓包去定位，非常被动。

3.2 可靠性三兄弟：acks、retries、enable.idempotence

acks是生产者可靠性最核心的参数，有三个取值：

• acks=0：消息发出即算成功，不等任何确认。吞吐最高，但任何网络故障都会导致丢消息。
• acks=1：Leader节点写入成功就算成功。这是性能和可靠性的折中，但Leader挂了且新Leader没有这条数据时，消息会丢。
• acks=all（或-1）：所有ISR副本都写入成功才算成功。可靠性最高，但也有一个需要记住的前提：acks=all的实际效果取决于min.insync.replicas的配置，参照第2章讲的联动逻辑。

retries用于网络抖动时的重试，默认值是2147483647（极大值）。在事务和幂等开启的情况下，默认重试次数已经足够，一般不建议调低。需要注意的是，重试可能会引发消息乱序，比如第一条消息重试时，第二条已经发出去了。解决办法是配合enable.idempotence一起使用。

enable.idempotence是Kafka 0.11版本引入的参数，开启后生产者会自动具备幂等能力：每个Producer有一个ProduceID，Broker会用序列号去重，避免重试导致的重复写入。开启幂等之后，它还会强制把acks设为all，并且把max.in.flight.requests.per.connection限制在1到5之间（因为超过5个未确认请求时可能出现乱序）。在大多数场景下，我建议直接开启幂等，它能用极小的开销换掉"重试可能产生重复消息"这个隐患。

3.3 吞吐与延迟的平衡：batch.size、linger.ms、buffer.memory

生产者发送消息有个"攒批"机制。batch.size默认16KB，是个单批次的内存上限。linger.ms默认0，表示消息到来后立即发送，不等待更多消息凑成一批。

如果你想提高吞吐，可以考虑把linger.ms调到5-20ms范围。这样消息在缓冲区里多停留了十几毫秒，但一批能装更多消息，网络请求次数大幅减少，TPS能涨得很明显。代价是单条消息的延迟上升。这里没有标准答案，取决于业务是"每一条消息都要尽快送达"还是"一秒钟送完一个大批次就行"。

buffer.memory默认32MB，是所有未发送消息的缓冲区总大小。如果你的生产速率瞬间很高，缓冲区满了之后send()方法会阻塞（阻塞时长由max.block.ms控制，默认60秒）。如果60秒还没发出去，就会抛TimeoutException。在大流量场景下，我建议至少给到64MB以上，不然高峰期容易出现发送超时。

3.4 压缩与粘性分区

compression.type用于配置发送数据的压缩算法。可选none、gzip、snappy、lz4、zstd。压缩能显著降低网络带宽和Broker磁盘占用，但会增加生产端的CPU开销。我的实测经验是：lz4在压缩率和CPU开销之间比较平衡，zstd压缩率最高（比gzip高30%-50%左右），但如果你的CPU资源本身就紧张，可以考虑lz4。如果你的消息体是纯文本JSON，压缩收益非常明显，一段几KB的JSON用zstd压缩后经常只剩几分之一。

partitioner.class是分区器，默认采用粘性分区策略（Sticky Partitioning），它会尽量往同一个分区发送数据来提升批处理效率。除非你有明确的分区需求（比如相同key的消息必须进同一分区保证顺序），否则不要自定义分区器。

3.5 顺序性保障的边界条件

如果要保证单个分区的消息顺序，需要同时满足三个条件：开启enable.idempotence=true、max.in.flight.requests.per.connection=1（或不超过5）以及retries>0。如果你关闭幂等，又把max.in.flight.requests.per.connection设为大于1，那么当第一条消息重试时，后续的消息可能先被写入，顺序就乱掉了。

我遇到过最尴尬的情况是：上线的代码里设置了max.in.flight.requests.per.connection=5来提升吞吐，但忘了开幂等，结果在线上真的发生了消息乱序，数据库里出现了一堆异常数据。排查了很久才发现是这个配置组合的问题。所以如果你对消息顺序有要求，务必要把enable.idempotence加上，否则不要为了吞吐牺牲顺序性。

4. 消费者关键参数：消费语义与消费性能的掌控

4.1 消费组与位移管理

消费者的核心概念是消费组（Consumer Group），group.id是唯一标识。同一个消费组内的多个消费者会分摊Topic的不同分区，从而实现水平扩展。

消费者位移（Offset）管理有两个关键参数。enable.auto.commit如果为true，消费者会在后台定期提交位移，提交间隔由auto.commit.interval.ms控制，默认5秒。这种方式最省心，但有重复消费的风险：比如消息已经拉取下来正在处理，还没到自动提交的时间点，进程就挂了，重启之后消费组会从上次提交的位移继续消费，导致一部分消息被重复处理。

对可靠性要求高的场景，我建议把enable.auto.commit设为false，改用手动提交。手动提交分两种：同步提交（commitSync）和异步提交（commitAsync）。同步提交会阻塞，直到Broker确认；异步提交不阻塞但可能失败，实际项目中一般配合回调把失败信息打日志。手动提交最理想的位置是：一批消息处理成功后提交这批的位移，再拉取下一批。这样"处理成功"和"提交位移"绑定在一起，重复消费的窗口大幅收窄。

auto.offset.reset定义的是消费者在"没有已提交位移"或"位移已失效"时的行为。latest表示从当前最新位开始消费，earliest表示从最早可用的消息开始消费，none则会直接抛异常。需要注意：这个参数不会影响有正常已提交位移的消费场景，它只处理"无位移可依"的情况。在新建消费组做数据补录时用earliest，在正常接流量时用latest。

4.2 心跳与会话超时：Rebalance的导火索

session.timeout.ms（默认45秒）是指消费者在指定时间内没有向Broker发送心跳，Broker就认为它已经下线，会把它踢出消费组，触发Rebalance。heartbeat.interval.ms（默认3秒）是心跳发送的频率。

这两个参数配合的要点是：心跳间隔必须远小于会话超时时间。如果心跳间隔设定成30秒、会话超时也是45秒，那消费者可能已经有好几轮心跳都没发出去，Broker就会误判。在正常的网络环境下，保持默认值即可，不需要频繁修改。如果消费端GC停顿时间比较长或者网络环境不稳定，可以适当调大session.timeout.ms，给系统多一点容错空间，但代价是故障的发现时间变长。

max.poll.interval.ms（默认5分钟）是一个经常被忽视的参数。它限制了消费者两次poll()调用之间的最大时间间隔。如果一次poll()之后，你的业务逻辑处理耗时超过了5分钟（比如调了一个慢接口、批量写库很耗时），消费者会被判定为"消费卡死"，主动离开消费组并触发Rebalance。这是很多消费端"莫名奇妙被踢出群"的原因。解决办法有两种：一是把max.poll.interval.ms调大（比如10分钟），二是把一批拉取到的时间缩小（配合max.poll.records），让单次poll()的处理时间不超过阈值。我个人倾向后者，主动降低每条消费线程的压力，而不是无限放宽超时。

4.3 拉取性能参数解析

fetch.min.bytes（默认1字节）表示单次拉取最少要多少数据才会返回。如果设为0，表示有就返回，没有就空轮询；如果设为较大值（比如1KB），Broker会等到攒够1KB数据才返回，可以减少网络往返次数，适合大吞吐但低实时的场景。

fetch.max.wait.ms（默认500ms）是Broker等待数据攒够的最大时间。如果fetch.min.bytes一直没攒够，最多等这个时间也会返回。这两个参数是"时间与字节"的限制组合：先到阈值就返回。

max.poll.records（默认500条）是单次poll()最多返回多少条消息。它直接决定了消费线程单批次的处理量。在处理逻辑比较重的场景（比如每条消息要写数据库、调外部API），把max.poll.records调小一些（比如100甚至50），能有效减少单次处理的耗时，降低被max.poll.interval.ms判定超时的风险。如果你希望消费者最大化吞吐，可以保持默认，让消费线程扛更多处理量。

max.partition.fetch.bytes（默认1MB）是单次拉取中每个分区最多返回多少字节数据。如果你上游还在用message.max.bytes发送大消息，消费端的这个参数也要同步调大，否则会再次遇到"写入成功但消费失败"的尴尬局面。

4.4 事务与隔离级别：精确一次消费语义

isolation.level有两个值：read_uncommitted和read_committed。默认是read_uncommitted，表示可以读到未提交事务的消息。如果你的生产者使用了Kafka事务（比如流式计算中的正好一次语义），消费者端需要把isolation.level设置为read_committed，这样消费者只能读取事务已提交的消息，避免读到事务中间状态的数据。注意read_committed对非事务消息也是正常读取的，不会影响普通Topic的消费，所以如果你已经启用了事务型生产者，消费者端统一改成read_committed是安全的。

5. Topic级配置：让配置文件"活"起来

5.1 为什么需要Topic级配置

如果没有Topic级配置，你还算好办：所有Topic都使用Broker的默认值。但实际上不同业务的数据特征差异太大了。订单事件要求保留30天、副本3份；日志数据保留3天、副本2份；某个特殊Topic的消息体可能达到5MB，但大部分Topic只有几KB。如果所有Topic都走同一套配置，要么资源浪费，要么业务需求得不到满足。

Topic级配置的意义在于：它可以按Topic维度设置保留时间、消息大小、清理策略、最小ISR数量等参数，而不用影响其他Topic。操作上通过kafka-configs.sh来完成，推荐在创建Topic时就直接指定配置，而不是先建再改。

5.2 常用Topic级配置操作

查看某个Topic的当前配置，可以用：

bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name order-events --describe

调整Topic的保留时间为72小时：

bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name order-events --alter --add-config retention.ms=259200000

同时设置多个配置项：

bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name big-message-topic --alter --add-config max.message.bytes=5242880,min.insync.replicas=2

删除某个动态配置，让它回到Broker默认值：

bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name big-message-topic --alter --delete-config max.message.bytes

这里要注意，有些配置（如min.insync.replicas、retention.ms、max.message.bytes）是支持动态修改的，不需要重启Broker；但有些配置（如segment.bytes）修改后只对新创建的Segment生效。另外还有一种更精细的"覆盖"用法：在Broker上动态调整某个配置值，也会覆盖本地文件里的静态默认值。排查时用kafka-configs.sh --describe看到的才是实际生效值，不能只看server.properties。

5.3 一个实操案例：区分日志Topic和订单Topic

我给你描述一个我实际做过的配置方案做参考。假设集群有3个Broker：

• app-log-topic：量大、容忍丢失一点点，保留4天，副本2，不管顺序。配置为retention.ms=345600000,replication.factor=2。
• order-event-topic：关键业务，保留30天，副本3，开启幂等写入，消费端手动提交。配置为retention.ms=2592000000,replication.factor=3,min.insync.replicas=2。
• image-meta-topic：单条消息最大可能到3MB，保留1天，副本2。配置为retention.ms=86400000,replication.factor=2,max.message.bytes=3145728。

这样使用Topic级配置，就不需要为了让"大消息"Topic跑得通而把整个集群的message.max.bytes调高到影响所有Topic。全局配置保持常规取值，特殊需求在Topic维度解决，这比全部依赖Broker默认值灵活得多。

6. 常见问题与排查实录

6.1 消费者频繁Rebalance怎么定位

现象：消费者组日志里频繁出现"Rebalance in progress"和分区重新分配记录，消费吞吐上不去。

排查步骤：先看心跳参数是否合理，确认heartbeat.interval.ms确实小于session.timeout.ms。然后用kafka-consumer-groups.sh查看消费者组的状态和成员列表：

bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-group --describe

关注CURRENT-OFFSET和LOG-END-OFFSET的差值，也就是Lag。如果在Rebalance期间Lag突然拉大，说明消费者在Rebalance时是停止消费的，多个消费者之间来回踢皮球会导致进展停滞。最常引发这个现象的是单条poll()处理时间超过max.poll.interval.ms，或者有一个消费者的处理线程被阻塞了，没及时发心跳。把max.poll.records调小、升级慢消费者所在机器的CPU规格，通常是立竿见影的。

6.2 生产者报TimeoutException的排查思路

现象：生产者日志中出现org.apache.kafka.common.errors.TimeoutException，消息发送失败。

排查路径：

• 查看buffer.memory是否已满，如果满了且max.block.ms到时会抛这个异常。在监控上能看到的典型特征是：发送线程阻塞时间越来越长、消息积压在生产者侧。
• 检查Broker端是否发生长时间GC，导致响应延迟。
• 检查max.request.size和服务端message.max.bytes是否匹配，如果一个生产者发的消息体超限，不会报Timeout，而是会报RecordTooLargeException，要注意区分。
• 网络层面看是否有丢包，acks=all时如果ISR副本中有节点慢，整体响应时间会被拖长。

6.3 消费端报OffsetOutOfRangeException

现象：消费者启动后直接抛OffsetOutOfRangeException，或者日志里出现大量"sleeping for ..."的重试输出。

原因：消费组记录的位移小于消息最早保留的位移，或大于最新位移，通常在消息过期被清理后发生。比如一个Topic保留1天，但你有一个消费任务暂停了3天，再启动时它的位移对应的消息已经被删了。

解决办法：明确你的业务容忍度，如果是补数据场景，把auto.offset.reset设成earliest，重启消费者；如果只关心新数据，设成latest。注意这个参数只有在没有有效位移时才生效，如果你希望强制重置位移，需要用kafka-consumer-groups.sh --reset-offsets显式操作：

bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-group --topic order-event-topic --reset-offsets --to-earliest --execute

6.4 CoordinatorNotAvailableException和UnsupportedVersionException

CoordinatorNotAvailableException通常出现在消费组刚启动时，消费者在寻找Group Coordinator节点的阶段。它会自动重试，但如果长时间不恢复，说明offsets.topic.replication.factor配置过低或者负载过大。__consumer_offsets这个内部Topic承载了所有消费组的位移提交，它的副本数在生产环境至少要是2或3。很多人在三节点集群里只设了offsets.topic.replication.factor=1，一旦那个Broker挂掉，整个集群的消费组都会卡在Coordinator查找阶段，所有位移提交全部失败。

UnsupportedVersionException一般是客户端版本和服务端版本不匹配导致的。Kafka的Broker和客户端之间的协议是向下兼容的，但如果你用了太老的客户端连新版本的Broker，或者反过来客户端用了新版特性而Broker太老，就会报这个错。解决办法是让客户端版本尽量向服务端版本靠拢，不要差太多大版本。

6.5 配置调优的推荐起点

如果你刚开始接触Kafka，从下面这套配置起步，实测可以满足大多数常规业务：

调优时不要一次性改很多参数，一次改一两个，观察指标变化，再继续下一步。

最后聊一点我自己的体会：配置参数这东西，文档能告诉你每个参数是干什么的，但真正决定配置是否合理的，是你对业务场景的理解。同样是acks=all，在日志系统里可能就是过度设计，在交易系统里则是底线要求；同样是linger.ms=10，在实时推荐场景里就是不可接受，在离线批处理场景里反而能大幅提升吞吐。所以不用追求"最优配置"这种不存在的目标，而是要在项目上线前想清楚三个问题：这个系统允许丢多少消息、允许有多大的延迟、故障时是优先恢复还是要保数据。把这三个问题想清楚了，再回头看参数，每一个选择都有据可依。