2. Confluent Kafka数据共享基础
在 Confluent Kafka 中谈“数据共享”，并不是把一份数据库表直接授权给另一个团队，而是让数据以事件流的形式在多个团队之间持续流动。要理解这种共享方式，必须先弄清五个核心对象：Broker、Topic、Partition、Producer、Consumer。它们不是孤立术语，而是共同构成一条“谁产生数据、数据放在哪里、如何被并行读取、由谁消费”的共享链路。
Broker：共享数据的存储与协调节点
Broker 是 Kafka 集群中的服务节点，负责接收 Producer 写入的消息、持久化到磁盘，并向 Consumer 提供读取。一个集群通常由多个 Broker 组成，每个 Broker 有唯一编号（broker.id）。Topic 的每个 Partition 会分布在不同的 Broker 上，并通过副本机制保证可用性。例如一个 3 Broker 集群中，某 Topic 设置 replication.factor=3，则每个 Partition 都有一个 Leader 副本和两个 Follower 副本。Leader 处理读写，Follower 持续同步；当 Leader 所在 Broker 故障时，Controller 会从同步副本中选出新 Leader。对数据共享而言，Broker 决定了数据的持久性、吞吐上限和故障恢复能力，是跨团队共享的物理基础。
Topic：共享数据的逻辑分类
Topic 是消息的逻辑类别，也是团队之间约定共享内容的“契约边界”。例如订单团队创建 order-created，支付团队创建 payment-completed，风控团队订阅两者进行实时判断。Topic 名称应稳定、语义明确，避免把不同业务混在一个 Topic 中。共享时，生产方负责定义事件结构和 Schema，消费方按约定读取。Confluent 的 Schema Registry 可以为 Topic 绑定 Avro、Protobuf 或 JSON Schema，并在兼容性策略下演进，从而让跨团队协作不因字段变更而中断。
Partition：并行与顺序的平衡单元
Partition 是 Topic 的物理分片，也是 Kafka 实现水平扩展和并行消费的关键。一个 Topic 可划分为多个 Partition，每个 Partition 内部消息严格有序，但不同 Partition 之间不保证全局顺序。消息写入哪个 Partition 由 key 决定：相同 key 的消息进入同一 Partition，从而保证同一业务实体的顺序。例如以订单号作为 key，则同一订单的创建、支付、发货事件会落在同一 Partition，消费方可以按序处理。Partition 数量决定了最大并行消费度：若 Topic 有 6 个 Partition，同一消费者组最多可有 6 个 Consumer 实例同时消费。共享数据时，生产方需要合理选择 key 和分区数，消费方需要理解顺序只保证在分区内。
Producer：共享数据的写入方
Producer 是向 Topic 发布消息的客户端。它决定消息进入哪个 Partition、使用什么序列化格式、是否等待副本确认。关键参数包括：acks（0 表示不等待确认，1 表示 Leader 确认，all 表示所有同步副本确认）、retries（重试次数）、enable.idempotence（幂等写入，避免重试导致重复）。在跨团队共享中，Producer 通常由数据生产方维护，必须保证事件结构稳定、key 选择合理、发送语义明确。例如订单服务以订单号作为 key，并设置 acks=all，可以保证同一订单事件有序且不丢失。
Consumer：共享数据的读取方
Consumer 从 Topic 拉取消息并处理。多个 Consumer 可以组成 Consumer Group，组内每个 Partition 只由组内一个 Consumer 消费，从而实现并行处理；不同 Consumer Group 之间互不影响，可以各自独立读取同一 Topic。这正是数据共享的核心机制：一份数据可以被风控、报表、推荐等多个团队同时消费，而生产方只需写入一次。Consumer 通过 offset 记录消费进度，支持从指定位置重放，便于故障恢复和回溯计算。
五者如何共同支撑数据共享
把五个对象串起来看：Producer 按业务 key 将事件写入 Topic 的某个 Partition；Broker 集群持久化这些 Partition 并维护副本；Consumer Group 中的 Consumer 各自拉取分配给自己的 Partition，按 offset 推进消费。共享的边界由 Topic 和 Schema 定义，共享的并行能力由 Partition 数量决定，共享的可靠性由 Broker 副本和 Producer acks 共同保证。理解这层关系后，跨团队协作就不再是“把数据导来导去”，而是围绕事件契约和消费组进行可扩展、可重放、可治理的数据流动。