企业官网建设流程全解析

1. 集群规划的核心三要素：节点、分区与副本

1.1 为什么这三个参数决定了Kafka集群的生死

很多刚接触Kafka的朋友，在本地跑通一个单节点Demo之后，就觉得“不过如此”，恨不得第二天就把公司核心业务全量接进来。结果一上线，要么是生产者写入超时，要么是消费者积压几百万条消息，要么是某个节点磁盘直接爆掉。这些问题追根溯源，八成以上都跟集群规划阶段没想清楚节点数、分区数、副本数这三个参数有关。

我见过一个比较典型的翻车案例：某团队做日志采集，初期每天数据量大概几十GB，为了省机器，直接上了3个节点，Topic只给了6个分区，副本数设成2。前两个月跑得好好的，后来业务量翻了三倍，生产者开始频繁报TimeoutException，消费者Lag一路飙升。他们第一反应是加机器，从3个节点扩到6个，结果发现Topic的分区数没变，新加的节点根本分担不了已有分区的写入压力。这就是典型的“只扩节点不扩分区”的坑。

所以这一课的核心，就是把这三个参数之间的联动关系彻底讲透。节点数决定了集群的物理承载上限，分区数决定了Topic的并行处理能力，副本数决定了数据的可靠性与可用性。三者不是孤立的，任何一个调整都会牵动另外两个。

1.2 节点数怎么定：从数据量和吞吐两个维度倒推

节点数不是拍脑袋定的，我一般建议从两个维度来倒推。

第一个维度是存储容量。假设你每天产生500GB原始数据，Kafka默认保留7天，副本数为3，那么实际需要的磁盘空间是：

500GB/天 × 7天 × 3副本 = 10500GB ≈ 10.5TB

如果单节点挂4块4TB的机械盘，做RAID或者JBOD，可用容量大概12TB左右，考虑到系统盘和预留空间，实际可用按10TB算。那么至少需要2个节点才能满足存储。但2个节点意味着任何一台挂了，集群都可能不可用，所以生产环境最少3个节点起步。

第二个维度是吞吐能力。单台Kafka Broker的写入吞吐，在机械盘、千兆网卡的环境下，实测大概在50MB/s到100MB/s之间；如果换成SSD加万兆网卡，单节点跑到300MB/s以上也不稀奇。假设你的峰值写入是200MB/s，单节点保守按80MB/s算，那至少需要3个节点来分摊。

把这两个维度算出来的节点数取最大值，再往上加1到2个作为冗余，基本就是比较稳妥的初始规模。我个人的经验是，生产环境起步3节点，中等规模6到8节点，大型集群12节点以上。但节点数也不是越多越好，ZooKeeper或者KRaft的元数据管理压力会随着节点数增加而上升，超过50个节点的集群，运维复杂度会明显上一个台阶。

1.3 分区数：并行度的天花板，也是踩坑的重灾区

分区是Kafka实现并行读写的基本单位。一个Topic的分区数，直接决定了最多有多少个消费者可以同时消费，也决定了生产者可以同时向多少个分区写入。

分区数太少，并行度上不去，消费者数量超过分区数之后，多出来的消费者只能空转。分区数太多，又会导致一系列问题：每个分区在Broker上都有对应的文件句柄和内存开销，分区过多会拖慢Leader选举和故障恢复的速度，端到端的延迟也会上升。

那到底怎么定分区数？我通常用这个公式来估算：

分区数 = max(目标吞吐 / 单分区写入吞吐, 目标吞吐 / 单分区消费吞吐)

单分区写入吞吐在机械盘环境下大概10MB/s到20MB/s，SSD环境下可以到50MB/s以上。假设你的目标写入吞吐是500MB/s，单分区按15MB/s算，那至少需要34个分区。再考虑消费者并行度，如果希望20个消费者同时消费，那分区数不能少于20。两者取大，最终定36个分区比较合适。

注意：分区数只能增加不能减少。Kafka不支持减少分区，因为减少分区会导致消息的归属关系发生变化，已经写入的消息无法重新分配。所以初期宁可多给一点，也不要给太少。

但“多给一点”也是有代价的。我见过一个团队，为了“一步到位”，给一个日均消息量只有几十万条的Topic设了500个分区。结果每次Broker重启，Leader选举要花好几分钟，消费者Rebalance也慢得让人抓狂。所以分区数不是越多越好，够用且留有一定余量才是最佳实践。

1.4 副本数：可靠性与成本的平衡术

副本数决定了每个分区有多少份数据拷贝。副本数设为1，意味着没有冗余，Broker一挂数据就丢；设为2，允许挂一台；设为3，允许挂两台。

生产环境我一般建议副本数至少为3。为什么不是2？因为副本数为2的时候，如果两台Broker同时挂掉（比如机架断电、交换机故障），数据就丢了。而且副本数为2时，Kafka的min.insync.replicas通常设为1，这意味着只要有一个副本写入成功就返回ACK，可靠性其实并不高。副本数为3时，min.insync.replicas可以设为2，这样即使挂掉一台，仍然能保证至少有两个副本持有完整数据。

副本数带来的成本是存储和网络开销。副本数为3，意味着同样的数据要存三份，写入时也要同步到两个Follower，网络带宽消耗也是三倍。所以在一些对可靠性要求不那么极致的场景，比如日志采集、监控指标，副本数设为2也是可以接受的。但核心交易类数据，副本数必须是3。

这里有个容易被忽略的点：副本数不等于可用性。如果所有副本都分布在同一个机架上，机架断电照样全挂。所以生产环境一定要配置broker.rack，让Kafka把副本分散到不同机架。

2. 压力测试：用数据说话，别靠感觉调参

2.1 压测工具选型：官方脚本够用，但要注意姿势

Kafka自带了两套压测脚本：kafka-producer-perf-test.sh和kafka-consumer-perf-test.sh。这两个脚本虽然看起来简陋，但胜在开箱即用，不需要额外部署，而且能直接反映Broker端的真实表现。

我试过一些第三方的压测工具，比如用JMeter或者自己写多线程程序，但最后发现还是官方脚本最稳。原因很简单：官方脚本直接调用Kafka的Java客户端，没有中间层损耗，测出来的数据最接近真实业务场景。而且脚本的参数设计很直观，--num-records、--record-size、--throughput、--producer-props这些，基本覆盖了压测的核心需求。

不过官方脚本也有坑。默认情况下，kafka-producer-perf-test.sh使用的是acks=1，也就是Leader写入成功就返回，不等待Follower同步。这个配置测出来的吞吐量会偏高，但可靠性偏低。如果要测真实场景，一定要在--producer-props里显式指定acks=all。

2.2 生产者压测：从单分区到多分区的阶梯式验证

压测不是一上来就拉满，我习惯分三步走。

第一步，单分区基线测试。创建一个只有1个分区、1个副本的Topic，用生产者压测脚本写入固定大小的消息，观察单分区的极限吞吐和延迟。这一步的目的是摸清单个分区的能力上限，为后续分区数规划提供依据。

kafka-producer-perf-test.sh \ --topic perf-test-1p \ --num-records 1000000 \ --record-size 1024 \ --throughput -1 \ --producer-props bootstrap.servers=broker1:9092,broker2:9092,broker3:9092 acks=all

--throughput -1表示不限速，让生产者尽可能快地写入。--record-size 1024表示每条消息1KB，这是比较典型的业务消息大小。跑完之后，脚本会输出吞吐量（records/sec和MB/sec）以及延迟分布（平均延迟、P99延迟等）。

第二步，多分区扩展测试。把Topic的分区数增加到6、12、24，重复同样的压测，观察吞吐量是否线性增长。如果分区数增加后吞吐量没有明显提升，说明瓶颈可能在Broker的磁盘IO或者网络带宽上，而不是分区数。

第三步，多生产者并发测试。同时启动多个生产者进程，向同一个Topic写入，模拟真实业务中多个服务同时写入的场景。这一步能测出Broker在多连接下的表现，也能暴露一些连接数相关的配置问题。

2.3 消费者压测：别忽略消费端的瓶颈

生产者压测做完了，很多人就以为万事大吉了。但实际上，消费端的瓶颈往往更隐蔽。生产者写入快，不代表消费者能跟上。如果消费者处理能力不足，消息就会在Broker上堆积，最终触发保留策略被删除，造成数据丢失。

消费者压测用kafka-consumer-perf-test.sh，关键参数是--messages和--threads。--threads指定消费者线程数，一般建议和分区数对齐。比如Topic有12个分区，就开12个消费者线程，让每个线程消费一个分区。

kafka-consumer-perf-test.sh \ --topic perf-test-12p \ --messages 1000000 \ --threads 12 \ --bootstrap-server broker1:9092,broker2:9092,broker3:9092

跑完之后，重点关注MB/sec和records/sec两个指标。如果消费吞吐明显低于生产吞吐，就要检查消费者的处理逻辑是不是太重，或者fetch.min.bytes、max.poll.records这些参数是不是需要调整。

2.4 压测结果解读：哪些指标必须盯死

压测跑完，面对一堆输出，新手容易懵。我一般只看四个指标：

如果P99延迟远高于平均延迟，说明存在长尾请求，可能是GC停顿或者磁盘IO抖动导致的。如果CPU使用率长期超过80%，说明节点数不够，需要扩容。

提示：压测时一定要监控Broker端的磁盘IO和网络IO。很多时候瓶颈不在Kafka本身，而在底层硬件。用iostat和sar -n DEV可以快速定位。

3. 参数调优实战：从压测数据到配置落地

3.1 分区数调整：扩分区不是万能药

压测发现吞吐上不去，第一反应往往是加分区。但加分区之前，先确认瓶颈到底在哪。如果Broker的磁盘IO已经跑满，加再多分区也没用，反而会增加元数据开销。

加分区用kafka-topics.sh --alter命令：

kafka-topics.sh \ --bootstrap-server broker1:9092 \ --alter \ --topic perf-test \ --partitions 24

加完分区之后，已经写入的消息不会重新分配，只有新写入的消息才会进入新分区。所以加分区之后，消费者的并行度会提升，但历史数据的分布不会变。如果业务对消息顺序有要求，加分区要格外谨慎，因为同一个Key的消息可能被分配到不同分区，顺序性会被破坏。

我个人的经验是，分区数调整最好在业务低峰期做，而且做完之后要观察一段时间消费者Lag的变化。如果Lag没有明显下降，说明瓶颈不在分区数，而在消费者的处理能力上。

3.2 副本数调整：增加容易减少难

副本数可以从1增加到3，但反过来从3减到1，Kafka是不支持的。所以副本数调整要慎重。

增加副本数用kafka-reassign-partitions.sh，需要先写一个JSON文件指定重新分配方案：

{ "version": 1, "partitions": [ {"topic": "perf-test", "partition": 0, "replicas": [1, 2, 3]}, {"topic": "perf-test", "partition": 1, "replicas": [2, 3, 1]} ] }

然后执行：

kafka-reassign-partitions.sh \ --bootstrap-server broker1:9092 \ --reassignment-json-file reassign.json \ --execute

这个操作会触发大量的数据拷贝，对网络和磁盘IO压力很大。一定要在业务低峰期做，并且限速。--throttle参数可以限制拷贝速度，单位是字节每秒。比如限制50MB/s：

--throttle 52428800

3.3 节点扩容：新节点不会自动分担负载

集群扩容加节点，很多人以为新节点一加进去，负载就会自动均衡。实际上，Kafka不会自动把已有分区的负载迁移到新节点。新节点加入后，只有新建的Topic或者新增加的分区才会分配到新节点上。

要让已有分区重新分布，需要用kafka-reassign-partitions.sh生成重新分配方案。Kafka提供了一个--generate模式，可以自动生成均衡的分配方案：

kafka-reassign-partitions.sh \ --bootstrap-server broker1:9092 \ --topics-to-move-json-file topics.json \ --broker-list "1,2,3,4,5,6" \ --generate

这个命令会输出两个JSON：一个是当前的分配方案，一个是建议的均衡方案。把建议方案保存成文件，再用--execute执行。

扩容过程中，新节点的磁盘和网络配置最好和旧节点保持一致。如果新节点性能更好，可以考虑把热点分区迁移到新节点上，但要注意不要造成新的热点。

3.4 关键配置参数速查表

除了节点、分区、副本这三个核心参数，还有一些配置参数会直接影响集群表现。我整理了一张速查表，方便对照调整：

这些参数没有绝对的最优值，需要结合压测结果和实际业务场景来调整。比如num.io.threads，如果压测时发现磁盘IO等待时间很长，可以适当增加；如果CPU使用率已经很高，再增加反而会加剧上下文切换。

4. 常见问题与排查技巧实录

4.1 生产者超时：不一定是Broker的锅

生产者报TimeoutException，很多人第一反应是Broker挂了。但实际上，超时可能来自多个环节：网络延迟、Broker端处理慢、副本同步慢、甚至生产者自身的缓冲区满了。

排查思路是这样的：先看Broker端有没有报错日志，如果Broker正常，再看生产者的request.timeout.ms和linger.ms配置。request.timeout.ms默认是30秒，如果网络抖动比较大，可以适当调大。linger.ms默认是0，表示消息立即发送，如果调大到10ms，可以攒一批消息再发，提高吞吐但增加延迟。

还有一个容易被忽略的点：生产者的buffer.memory。默认是32MB，如果生产速度远大于发送速度，缓冲区很快就会被填满，导致send()方法阻塞或者抛异常。这种情况下，要么调大buffer.memory，要么增加max.block.ms。

4.2 消费者Lag飙升：先看分区数，再看处理逻辑

消费者Lag飙升是最常见的线上问题之一。排查顺序我一般是这样的：

第一步，确认分区数和消费者数的关系。如果消费者数大于分区数，多出来的消费者是空闲的，Lag不会因为增加消费者而下降。这时候要么增加分区数，要么优化单个消费者的处理能力。

第二步，检查消费者的处理逻辑。如果每条消息的处理耗时很长（比如调用了外部HTTP接口），那Lag飙升是必然的。可以考虑批量处理，或者把耗时操作异步化。

第三步，检查max.poll.records和max.poll.interval.ms。max.poll.records默认是500，如果单条消息处理很慢，500条消息可能超过max.poll.interval.ms（默认5分钟），导致消费者被踢出组，触发Rebalance。Rebalance期间消费者停止消费，Lag会进一步飙升。

4.3 副本同步失败：ISR收缩的连锁反应

如果Broker日志里频繁出现Shrinking ISR，说明有Follower副本同步跟不上。ISR收缩本身不是故障，但如果ISR频繁收缩和扩张，说明集群不稳定。

常见原因有三个：一是Follower所在节点的磁盘IO太慢，拉取数据跟不上；二是网络带宽不足，副本同步占用了大量带宽；三是replica.lag.time.max.ms设置得太小，Follower稍微慢一点就被踢出ISR。默认是10秒，如果网络抖动比较大，可以适当调大到30秒。

注意：ISR收缩到小于min.insync.replicas时，生产者会报NotEnoughReplicasException，写入会被拒绝。这是Kafka的保护机制，防止数据写入到副本不足的分区。

4.4 磁盘写满：保留策略和清理机制的配合

Kafka的磁盘写满，通常是因为保留策略没配好。log.retention.hours控制消息保留时间，log.retention.bytes控制每个分区的最大存储空间。两者是“或”的关系，只要满足一个条件，消息就会被删除。

但删除是异步的，而且是以日志段为单位删除的。如果log.segment.bytes设置得很大（比如1GB），而写入速度又很快，可能会出现磁盘已经写满，但日志段还没达到删除条件的情况。这时候可以调小log.segment.bytes，比如256MB，让日志段更快滚动，删除也更及时。

另外，log.cleanup.policy可以设置为compact，对Key相同的消息只保留最新值。这种策略适合存储变更日志类的数据，可以大幅减少存储占用。

4.5 常见问题速查表

4.6 几个我踩过的坑

第一个坑是分区数设成质数。早期我看过一些资料说分区数用质数可以更均匀地分布，但实际上Kafka的分区分配算法已经足够均匀，质数反而会让某些计算变得麻烦。后来我统一用偶数，比如6、12、24，扩容和调整都方便。

第二个坑是副本数设为2就以为高枕无忧。有一次机房网络抖动，两台Broker同时失联，副本数为2的Topic直接不可用。后来核心业务全部改成副本数3，并且配置了机架感知。

第三个坑是压测时没开acks=all。用默认的acks=1压测，吞吐量看起来很漂亮，结果上线后开了acks=all，吞吐量直接腰斩。所以压测一定要用和生产一致的配置，否则数据没有参考价值。

第四个坑是扩容后忘了重新分配分区。加了新节点，以为负载会自动均衡，结果新节点一直闲着，旧节点继续扛着。后来养成习惯，每次扩容后都用kafka-reassign-partitions.sh做一次均衡。

4.7 监控指标：提前发现问题比事后救火重要

与其等问题发生了再排查，不如提前监控关键指标。我一般会在监控系统里盯这几个：

• Broker端：磁盘使用率、CPU使用率、网络IO、请求处理时间、ISR数量
• 生产者端：发送速率、错误率、重试次数、缓冲区使用率
• 消费者端：Lag、消费速率、Rebalance次数、处理耗时

这些指标不需要全部实时告警，但至少要能随时查看。特别是Lag和ISR数量，这两个指标一旦异常，往往意味着集群正在经历故障。

我个人在实际操作中的体会是，Kafka的集群规划没有一劳永逸的方案。业务在变，数据量在变，集群参数也要跟着变。定期做压测，定期review监控数据，比一次性把参数调到“最优”更重要。最后再分享一个小技巧：如果拿不准分区数设多少，可以先按预估峰值的1.5倍来设，然后通过压测验证，不够再加。分区数只能加不能减，所以宁可初期多给一点，也不要后期被动扩容。