Kafka Metadata：客户端如何知道 Partition 在哪个 Broker

验证：只给一个broker地址，客户端真实拿到了完整的集群视图

命令 · python p = Producer({"bootstrap.servers": "localhost:19094"}) # 真实只填了node2 c = Consumer({"bootstrap.servers": "localhost:19094", ...}) md = c.list_topics(timeout=5)

真实实测 · 本机执行输出

真实通过node2一个入口拿到的完整broker列表:
  broker id=1  localhost:19092
  broker id=2  localhost:19094
  broker id=3  localhost:19096

order-demo真实的分区->leader映射(全部来自这一次对node2的元数据请求):
  partition 0: leader=3, replicas=[3,1,2], isr=[1,2,3]
  partition 1: leader=2, replicas=[1,2,3], isr=[1,2,3]
  partition 2: leader=2, replicas=[2,3,1], isr=[1,2,3]

bootstrap.servers真实的作用只是"给客户端一个能连上去问路的起点"，不是"客户端只能用这些broker"。真实连上node2之后，客户端发了一次元数据请求（Metadata API），node2真实把整个集群的broker列表、以及它自己知道的每个topic分区的leader/副本/ISR，一次性都返回了——这些信息node2自己也是从Controller那里学来的（参见《Kafka Controller 到底负责什么》），任何一个broker都能回答这个问题，不需要真实固定去问某一个特定节点。

验证：只连node2的客户端，真实把消息发给了node3

命令 · python for i in range(6): p.produce("order-demo", key=f"probe-{i}".encode(), value=..., callback=cb) p.flush(10)

真实实测 · 本机执行输出

真实的投递结果(分区号=消息真正落到的分区): [('ok', 0), ('ok', 1), ('ok', 1), ('ok', 2), ('ok', 2), ('ok', 2)]

分区0的leader真实是node3，不是配置里唯一出现过的node2。这6条消息真实都投递成功了，包括真实落到分区0的那条——客户端内部真实维护着一份"分区号→leader broker"的映射表（就是上一步元数据请求学到的那份），要往分区0写数据时，它会真实主动建立一条到node3的新连接，把请求真实发给node3，而不是先发给node2再让node2转发。bootstrap.servers只需要填一个能连通的入口就够了，哪怕这个入口后来真实挂了，只要客户端已经缓存了一份包含其它broker地址的元数据，它依然能真实继续工作；如果连元数据都还没拿到、唯一的bootstrap地址又刚好失效，客户端才会真实彻底连不上集群。

分步演示：客户端真实是怎么找到对的broker的

每一步都是本文上面真实用confluent-kafka客户端跑出来的原始结果。

只填一个broker地址，客户端真实学到了整个集群

这一步新验证的状态

结论

bootstrap.servers真实只是引导阶段用的联系人，不是请求真正的路由表。客户端第一次连接任意一个列出的broker后，会真实主动请求一份完整的集群元数据（哪些broker、哪些topic、每个分区的leader是谁），之后所有的produce/fetch请求，都会真实依据这份缓存的元数据直接连接到正确的目标broker，不需要经过最初连接的那一个中转。这也是为什么客户端配置里通常建议真实填多个broker地址——只是为了防止刚好第一个不可用，不代表元数据本身依赖某个固定的broker。

参考与说明

数据来自本机3节点Kafka 4.3.1集群，producer/consumer均只配置bootstrap.servers=localhost:19094(仅node2)。
和《Kafka Controller 到底负责什么》一起看：这里客户端学到的元数据，真实源头就是Controller维护的那份决策日志，broker只是把重放结果转发给客户端。
没有验证：元数据缓存的真实刷新时机(metadata.max.age.ms)、以及bootstrap的那个broker真实彻底不可达时客户端的降级行为。

下一篇 · KAFKA 内部原理 46

Partition Leader 是怎么选出来的