企业官网建设流程全解析

前阵子有个做交易系统的团队找到我，提了两个问题。第一个是“Kafka单节点到底能承载多少数据量”，第二个是“消费者端的负载均衡，能不能根据IP来路由，让指定机器消费指定数据”。这两个问题放在一起问的人不少，因为大家潜意识里都希望消息中间件既能估算容量，又能在消费端像负载均衡器一样做到按业务规则分发。但实际做过Kafka运维和调优的人都知道，前者是一个容量规划问题，后者是一个分区分配规则问题，二者完全不同，绝不能混为一谈。

这篇文章我会把这两件事彻底拆开讲清楚。容量部分会给出存量计算的公式、吞吐压测的方法和单节点合理规划的建议；路由部分会解释Kafka消费者负载均衡的真正工作机制，并给出按Key路由、自定义分区器、自定义分配器、手动指定分区几种可落地方案。最后还会分享我在实际生产环境里踩过的坑，包括分区扩容导致路由失效、消费组频繁Rebalance等典型问题。无论你是刚接触Kafka的新手，还是已经在维护大规模集群的开发者，这篇应该都能给你一些可直接参考的东西。

1. 关于单节点承载量：先算存量，再算吞吐

1.1 存量容量公式

先把一个最常见的误解纠正掉：Kafka单节点能承载的数据量，不是一个固定的“几十万TPS”，而是一个由磁盘空间、保留策略、消息大小、副本因子共同决定的容量规划问题。

所谓“能存多少数据”，最核心的指标是磁盘。你可以用下面这个公式先估算：

单日新增磁盘占用 = 每秒写入消息条数 × 平均单条消息大小 × 86400 × 副本因子 ÷ 压缩系数

举个例子。假设业务峰值每秒写入5000条消息，平均每条2KB，topic副本因子为2，保留3天，不开启压缩：

• 每秒写入流量 = 5000 × 2KB = 10MB/s
• 单日新增 = 10MB/s × 86400秒 ≈ 864GB
• 副本因子2后 = 1.73TB/天
• 保留3天总量 = 5.2TB左右

如果业务消息是JSON文本且开启gzip压缩，通常能压到原始体积的25%到35%，那么3天窗口内的磁盘占用可以降到1.7TB上下。但注意，如果消息本身是已经压缩过的图片、视频或者加密后的二进制数据，压缩率基本为零，必须按最坏情况估。

注意：这个公式只是存量估算，单位是“能存多少TB”。它回答的是“磁盘够不够”，回答不了“能不能扛得住这一波流量”。所以要继续看吞吐。

磁盘容量不是越高越好，还要考虑保留策略。很多团队习惯把retention设置得很长，比如保留30天，结果某天流量翻倍，磁盘直接被写满，整个broker开始拒绝写入。我的建议是，保留窗口、副本因子、单条消息大小这三项要有专人负责定期核对，任何一个变化都要重新跑一遍容量公式。

1.2 吞吐到底看哪几条边

吞吐的真实上限取决于瓶颈点，通常是以下四个之一：

• 网络带宽：例如1Gbps网卡的理论上限约125MB/s，实际可用打八折大概100MB/s。如果跨机架或跨机房，还要考虑专线带宽。
• 磁盘顺序写速度：Kafka的消息是先写OS PageCache，再异步刷到磁盘，所以磁盘的顺序写速度直接决定了极限。普通SATA SSD顺序写能到400-500MB/s，机械硬盘也能到150-200MB/s，但随机读写会垮掉。
• CPU开销：消息压缩、解压、TLS加密、ACL鉴权都会消耗CPU。开启gzip压缩后，CPU可能先于网络成为瓶颈。
• 分区数与文件句柄：每个分区对应一组日志段文件和若干索引文件，分区数上去后，broker需要管理的文件句柄暴增，协调成本也会上升。

网上经常能看到“Kafka单节点百万级TPS”的说法，这并不假，但通常是短时压测、PageCache吸收写入、无磁盘落盘压力、无副本复制的前提下测出来的。生产环境里长时间稳定运行，数据还要落盘，还要被消费，还要容忍消费者追赶，这时候能跑到的数字会低得多。

分区数与吞吐不是线性增长。我在常规压测中见到的情况是：单分区小消息（1KB左右）可以达到数万条每秒；当分区数从1增加到32甚至64时，整机吞吐会明显上升，但如果继续加到几百个分区，吞吐反而可能下降。原因在于broker线程、文件句柄、页缓存碎片等开销开始互相争抢资源。单节点上topic分区总数建议控制在两三百以内，超过五百就要仔细评估了。

1.3 单节点合理规划的几个数字

给出几个我实际使用的参考口径，不是绝对真理，但可以作为初始规划依据：

很多人规划容量只盯消息条数，其实更该盯的是MB/s。同样的10万条每秒，1KB消息和10KB消息，对系统的压力完全是两个量级。把线上消息的平均大小用监控统计出来，再做容量估算，才是正确姿势。

2. 消费端的负载均衡：分区才是唯一路由单位

2.1 消费组和分区分配的工作原理

接下来回答第二个问题：“负载均衡能否根据IP路由消费”。理解这个问题的前提，是先理解Kafka消费者负载均衡的单位。

Kafka的消费模型里，同一个消费组内的所有消费者共同订阅一个或多个topic，组内协调由broker端的分区协调器负责。协调器会监控每个消费组成员的心跳，当组内有成员加入、退出、订阅关系变化或者topic分区数变化时，触发一次Rebalance，把待消费的分区重新分配给组内的消费者。

Kafka默认提供的分配策略主要有四种：

• RangeAssignor：按topic顺序排列分区，按消费者顺序分段分配，可能出现明显倾斜。
• RoundRobinAssignor：轮询分配，分区在消费者之间尽量均匀。
• StickyAssignor：在Rebalance时尽量保留上一次的分配结果，减少分区迁移。
• CooperativeStickyAssignor：Sticky的增强版，支持增量Rebalance，避免全量阻塞。

最核心的认知是：一个分区在同一个消费组内，同一时刻只能被一个消费者消费。负载均衡的最小单位是“分区”，而不是“IP”，也不是“消息”。如果组内有5个消费者但topic只有3个分区，那么多出来的2个消费者会空闲；如果组内有2个消费者但topic有10个分区，那么每个消费者会分到5个分区。

Rebalance的过程大致是：每个消费者启动后会向协调器发送JoinGroup请求，协调器选择组内某个消费者作为leader，leader根据所有成员上报的订阅信息执行分区分配算法，然后把分配结果通过协调器广播给所有成员。这里的输入信息是消费者的memberId、订阅的topic列表，以及自定义元数据，并不包含什么“消费者IP路由规则”。

2.2 为什么“按IP路由消费”听着合理，落地却坑很多

很多人觉得“负载均衡根据IP路由消费”是顺理成章的事，因为IP是机器最直观的标识。但在Kafka的机制里，这个想法有几个硬伤。

第一，消费者实例并不等同于IP。Kafka消费者实例的标识是memberId，由client.id加上随机UUID组成。同一台物理机上完全可能启动多个消费者进程，它们IP相同但memberId不同。你把路由规则绑在IP上，这多个消费者怎么区分？第二，IP是会变的。容器重建、DHCP重分配、虚拟机迁移都会导致消费者的IP变化。一旦IP变化，按旧IP绑定的分配规则就会失效，消费组会进入异常状态。第三，Kafka的故障转移依赖的正是rebalance。如果分区被硬编码绑定到某个IP的消费者，这台机器挂掉后，其他消费者无法接管它的分区，这个topic的消费就断了。

真正合理的思路是：分区分配只认“消费组成员”，不同成员之间允许携带自定义信息，分配策略可以在自定义信息上做文章。但要注意，这不是简单的“把IP传给coordinator”就能解决，需要自己实现分配算法。

2.3 正确拆解需求：按IP、按Key还是按机架

在实践中，“按IP路由消费”通常不是一个真实需求，而是用户对需求的粗粒度描述。我一般会继续追问，你到底想要哪种效果：

• 如果想让同一类业务消息，比如同一用户、同一订单的所有事件，都交给同一个消费者处理，那么你需要的不是IP路由，而是消息Key路由。
• 如果想让某个机房或某台特定机器只消费某几个分区，那么你需要的是自定义分区分配策略或手动指定分区。
• 如果只是想减少跨机房的网络流量，让消费者优先消费本机架的副本数据，那么Kafka 2.4之后的client.rack配置才是更合适的方案。

先把需求拆对，再去选方案，才不会白白写一堆代码。

3. 可落地的三种路由方案

3.1 方案一：Producer端用Key做路由

这是我认为最常用、成本最低、收益最高的方案。Kafka生产者在发送消息时，可以指定一个Key，默认分区器会对Key做哈希，然后将消息路由到对应的分区。

比如订单系统里，你希望同一个用户的所有订单事件都被同一个消费者处理，发送时把用户ID作为Key：

ProducerRecord<String, String> record = new ProducerRecord<>( "order-events", String.valueOf(order.getUserId()), payload ); producer.send(record);

只要Key相同，哈希值就相同，消息就会进入同一个分区。同一个分区只会被组内同一个消费者消费，所以顺序和归属都得到了保证。

这个方案的好处是：不改broker任何配置，不写自定义分配器，只需要在producer端指定Key。绝大多数业务场景，包括订单、支付、风控、日志聚合，都可以用这一招解决。注意，默认分区器在Key不为空时使用的是Murmur2哈希，不是Java的hashCode，不要拿Java的hashCode去推算分区号。

3.2 方案二：自定义分区器

如果默认的Key哈希满足不了需求，比如你想让某几类大客户的消息固定落到几个特定分区，方便关键消费端做隔离，可以实现自定义Partitioner。

public class CustomerPartitioner implements Partitioner { @Override public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) { List<PartitionInfo> partitions = cluster.partitionsForTopic(topic); int numPartitions = partitions.size(); if (key == null || numPartitions == 0) { return ThreadLocalRandom.current().nextInt(Math.max(1, numPartitions)); } String businessTag = (String) key; if ("vip".equals(businessTag)) { return 0; } return Utils.toPositive(Utils.murmur2(keyBytes)) % numPartitions; } @Override public void close() {} @Override public void configure(Map<String, ?> configs) {} }

然后在producer端指定：

partitioner.class=com.example.CustomerPartitioner

自定义分区器只是改变“消息进哪个分区”，并没有改变消费者分配规则。想让某个消费者固定消费这个分区，仍然需要在消费端配合手动指定分区或自定义分配器。

注意：自定义分区器一旦上线，topic分区数就不能随意变更。原因很简单，对所有Key取模的分区数变了，老数据读出来后就找不到原来那个消费者处理了，消息顺序和归属关系都会被打乱。

3.3 方案三：自定义ConsumerPartitionAssignor或手动assign

如果确实存在“指定IP/指定机器消费指定分区”的强需求，可以走两条路。

第一条路是实现自定义分配策略。消费者接口提供了ConsumerPartitionAssignor，可以重写subscriptionUserData()，让每个消费者在加入消费组时上报自己的自定义信息，比如机器ID、机架ID、IP等。分配时，你可以在assign()方法里读取这些自定义信息，把分区优先分配给特定成员。

这里给一段简化的伪代码，主要是展示思路，具体接口签名要按你所用Kafka版本的官方文档来写：

public class RackAwareAssignor extends AbstractPartitionAssignor { @Override public String name() { return "rack-aware"; } @Override public ByteBuffer subscriptionUserData() { String rackId = System.getenv("RACK_ID"); return ByteBuffer.wrap(rackId.getBytes(StandardCharsets.UTF_8)); } @Override public Map<String, Assignment> assign( Map<String, Subscription> subscriptions, int defaultPartitionCount, long defaultAssignmentTimeoutMs) { // 1. 遍历所有订阅的topic分区 // 2. 按subscriptionUserData()里的机架ID/实例ID对消费者分组 // 3. 将分区优先分配给同组消费者，分配结果写入Assignment return assignments; } }

消费者侧配置：

partition.assignment.strategy=com.example.RackAwareAssignor

这个方案能做到真正意义上的“按自定义维度做负载均衡”，但实现成本不低，而且要自己处理各种Rebalance边界情况。如果不是很有必要，我不建议一般团队直接上。

第二条路更简单粗暴，用assign()手动指定分区：

List<TopicPartition> partitions = Arrays.asList( new TopicPartition("order-events", 0), new TopicPartition("order-events", 1) ); consumer.assign(partitions); consumer.seekToBeginning(partitions);

这种方式完全绕开了消费组协调器，不参与组内Rebalance，也不会有负载均衡。它的优点是精确、可控、低延迟，适合离线任务、特殊数据处理、测试环境。缺点是如果消费者挂了，没有其他消费者会接管这些分区；如果新增分区，你需要手动扩展列表。线上业务如果追求高可用，要慎用。

4. 单节点容量评估实测过程

4.1 压测环境与命令

理论说了那么多，最终还是要用数据说话。我自己做单节点容量评估时，一般会准备一台和线上配置接近的机器，topic设为32个分区，副本因子为1，关闭压缩，分别处理1KB小消息和100KB大消息两种场景。

先用Kafka自带的压测工具测生产者吞吐：

bin/kafka-producer-perf-test.sh \ --topic perf-1k \ --num-records 5000000 \ --record-size 1024 \ --throughput -1 \ --producer-props bootstrap.servers=127.0.0.1:9092 acks=1 linger.ms=5 batch.size=262144

再测消费者吞吐：

bin/kafka-consumer-perf-test.sh \ --bootstrap-server 127.0.0.1:9092 \ --topic perf-1k \ --messages 5000000 \ --threads 1 \ --reporting-interval 1000

压测的同时，一定要在另一个终端盯系统指标：

dstat -tcmdn 1 iostat -dx 1 sar -n DEV 1

重点关注四个指标：网络带宽利用率、磁盘util、CPU平均负载、内存可用量。

提示：压测前要清理旧数据，topic重新创建一次。否则PageCache里可能已经有部分数据，读写混合会让结果失真。

4.2 如何从压测数据推导容量

比如某次压测中，1KB消息、32分区、acks=1，生产者稳定跑到12万条每秒，约117MB/s，此时网卡利用率已经接近上限。继续加压，延迟立刻从几十毫秒跳到几百毫秒，说明网络就是瓶颈。

那么生产容量建议就按峰值不超过60MB/s来规划，大约6万条每秒。如果你预估业务峰值会到10万条每秒，单节点就顶不住了，需要扩容到两台，或者开启消息压缩把体积降下来。

消费者端的压测同样重要。消费者压测结果会告诉你单节点能支撑多少下游消费速率。如果LAG持续上涨，要么加消费者实例，要么优化消费逻辑，要么扩容分区。

存储容量则按1.1节公式单独计算。两个结果都出来后，取更小值作为单节点的服务能力上限。记住一个原则：任何硬件的理论峰值都不能作为生产承诺值，至少预留50%的余量。

4.3 配套参数调优清单

容量评估时，有些参数会影响结果，这里列一下我常用的基线配置。

broker端：

num.network.threads=8 num.io.threads=8 socket.send.buffer.bytes=102400 socket.receive.buffer.bytes=102400 socket.request.max.bytes=104857600 log.retention.hours=72 log.segment.bytes=1073741824 unclean.leader.election.enable=false

consumer端：

enable.auto.commit=false max.poll.records=500 session.timeout.ms=15000 heartbeat.interval.ms=3000 max.poll.interval.ms=300000 partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

producer端：

acks=1 linger.ms=5 batch.size=131072 compression.type=gzip

要说明一下，acks=1能在大多数场景下保证较好的吞吐，但极端故障时可能丢消息；业务对可靠性要求极高，应该用acks=all。开启gzip压缩后，如果CPU还有富余，可以明显降低网络和磁盘压力。

5. 踩过的坑和排查技巧

5.1 分区扩容后Key路由失效

有个真实教训。某业务上线时topic分了32个分区，一年后业务量翻倍，大家决定扩到64个分区。结果扩容后，那些按用户ID做Key的消息并没有像预想中那样继续落在同一个分区，而是被重新哈希到了别的分区。原因不复杂：默认分区器的哈希结果对分区数取模，分区数变了，取模结果自然全变了。

这个坑一旦踩中，处理起来非常麻烦。老数据还在旧分区里，新数据去了新分区，消费者如果沿用旧逻辑，部分历史消息会落到不匹配的处理实例上。

教训是，topic分区数规划时就要预留足够的增长空间，比如初始64个分区，之后两年内一般够用。如果确实要扩容，建议新建一个topic，把数据迁移过去，而不是在旧topic上直接调分区数。

5.2 消费组频繁Rebalance风暴

当时排查一个线上问题：消费组LAG突然上涨，但消费者CPU并不高，也没有慢查询。最后发现组内每隔一两分钟就发生一次Rebalance。原因是有个消费者处理一批消息耗时超过了max.poll.interval.ms，心跳正常但poll调用超时，协调器判定它已经失联，把它踢出消费组，触发了全量Rebalance。Rebalance期间所有消费者暂停消费，LAG自然猛涨。

这个问题的解法有几层：

• 把max.poll.records从默认的500调小到200甚至100，控制单次poll的消息总量。
• 消费逻辑改成异步化，让poll循环快速返回，不要阻塞在业务处理上。
• 把session.timeout.ms和max.poll.interval.ms设置成合理的配合关系，不要一个极小一个极大。
• 使用CooperativeStickyAssignor，减少Rebalance需要迁移的分区。

5.3 如何快速查看消费组分配情况

排查消费问题时，最实用的命令是kafka-consumer-groups.sh：

bin/kafka-consumer-groups.sh \ --bootstrap-server 127.0.0.1:9092 \ --describe \ --group order-group

输出的核心列有CONSUMER-ID、HOST、CURRENT-OFFSET、LOG-END-OFFSET、LAG。

• LAG为0说明消费跟上了。
• LAG持续增长说明消费能力不足，要么加消费者，要么优化逻辑。
• 某行CONSUMER-ID为空但LAG很大，说明分区没有被任何消费者接管，要么消费者数不够，要么Rebalance还没完成。
• HOST列只是展示消费者注册时的地址，Kafka分配时并不拿它当作路由依据。很多同学看到HOST列以为“IP路由”是现成的，这就是误读。

这个命令在排查“某分区一直没人消费”“某个消费者分到的分区太多”等问题时非常有效，应该成为每个Kafka使用者的基础工具。

最后再分享一点个人体会。单节点承载量没有标准答案，一定要基于自己的消息大小、保留时长、副本数去压测和计算，峰值按50%余量规划。路由消费这件事，能走Key路由就不要写自定义分配器，除非你确实有非常明确的分区绑定或机架亲和需求。Kafka的机制已经很成熟，顺着机制用，省心省力；非要逆着机制造轮子，最后往往要在故障处理上付出更大的代价。