📚 课程目录第2章 Kafka核心概念

2. Kafka 核心概念：Topic、Partition、Broker、Producer、Consumer、Consumer Group 详解

在实时风控评分沙盘中，Kafka 扮演着“数据中枢神经”的角色。理解其六大核心概念——Topic、Partition、Broker、Producer、Consumer 与 Consumer Group——是搭建高吞吐、低延迟风控管道的基础。下面逐一拆解其定义、职责与在风控场景中的映射关系。

2.1 核心概念总览

下表从“一句话定义”与“风控角色”两个维度，快速建立概念认知：

概念	一句话定义	风控沙盘中的角色
Topic	消息的逻辑分类 / 主题	每类风控事件（交易、登录、设备指纹）对应一个 Topic
Partition	Topic 的物理分片，实现并行与扩展	按用户 ID 或事件 ID 哈希分区，保证同一用户事件有序
Broker	Kafka 集群中的单个服务器节点	集群中每台服务器承载部分 Partition 的读写
Producer	消息的生产者 / 发布者	风控 SDK / 业务系统将事件推送到 Kafka
Consumer	消息的消费者 / 订阅者	实时评分引擎从 Kafka 拉取事件进行规则计算
Consumer Group	一组 Consumer 协同消费同一 Topic	评分服务多实例部署，分摊 Partition 消费压力

2.2 Topic 与 Partition：逻辑分类与物理分片

Topic 是 Kafka 最顶层的消息分类单位。在风控场景中，通常按事件类型创建独立的 Topic：

risk-trade：交易事件
risk-login：登录事件
risk-device：设备指纹事件

Partition 是 Topic 内部的物理分片。每个 Partition 是一个有序、不可变的日志文件（append-only log）。Partition 的数量决定了 Topic 的最大并行处理能力。

风控设计要点： 为保证同一用户的事件顺序（如“先登录后交易”），Producer 需按用户 ID 作为 Key 发送消息。Kafka 保证同一 Key 的消息落入同一 Partition，从而保持局部有序。

下图展示一个 Topic 被拆分为 3 个 Partition，分布在 2 个 Broker 上：

2.3 Broker：集群节点

Broker 是 Kafka 集群中的单个服务器进程。多个 Broker 组成集群，通过 ZooKeeper 或 KRaft 协调元数据。每个 Broker 负责：

存储部分 Partition 的日志数据
处理 Producer 的写入请求
处理 Consumer 的拉取请求
Partition 的 Leader/Follower 角色切换（故障转移）

风控集群建议： 生产环境至少部署 3 个 Broker，配合副本因子（replication-factor）≥ 2，确保单节点宕机不影响实时评分数据流。

2.4 Producer：消息生产者

Producer 负责将消息发布到指定的 Topic。在风控沙盘中，Producer 通常是业务系统的 SDK 或日志采集器。关键配置参数：

参数	默认值	风控推荐值	说明
`acks`	1	all (-1)	等待所有副本确认，保证不丢消息
`retries`	0	3	网络抖动时重试，防止临时失败
`linger.ms`	0	5~10	小批量聚合发送，提升吞吐
`batch.size`	16384	32768	适当增大批次，减少网络开销
`key.serializer`	—	StringSerializer	用户 ID 作为 Key，保证分区有序

Producer 发送消息的核心代码示例：

Properties props = new Properties();
props.put("bootstrap.servers", "broker1:9092,broker2:9092,broker3:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("acks", "all");
props.put("retries", 3);
props.put("linger.ms", 5);

KafkaProducer<String, String> producer = new KafkaProducer<>(props);

// 风控事件：用户ID作为Key，保证同一用户事件顺序
ProducerRecord<String, String> record =
    new ProducerRecord<>("risk-trade", "user_12345", eventJson);
producer.send(record, (metadata, exception) -> {
    if (exception != null) {
        // 记录发送失败日志，触发告警
    }
});
producer.close();

2.5 Consumer 与 Consumer Group：协同消费

Consumer 从 Kafka 拉取消息进行业务处理。在风控场景中，Consumer 就是实时评分引擎。多个 Consumer 可以组成一个 Consumer Group，实现负载均衡与故障转移。

Consumer Group 的核心机制：

一个 Partition 只能被同一个 Group 内的一个 Consumer 消费
Group 内 Consumer 数量 ≤ Partition 数量时，每个 Consumer 分配至少一个 Partition
Consumer 数量 > Partition 数量时，多出的 Consumer 闲置
Consumer 宕机时，Group 自动触发 Rebalance，将 Partition 分配给其他成员

风控常见陷阱： 如果评分服务部署了 4 个实例，但 Topic 只有 3 个 Partition，则始终有 1 个实例处于空闲状态。务必保证 Partition 数 ≥ 最大预期 Consumer 数。

下图展示 Consumer Group 与 Partition 的分配关系：

2.6 风控沙盘中的完整数据流

将上述概念串联起来，实时评分沙盘的数据流如下：

业务系统（Producer）将风控事件发送到 risk-trade Topic
Kafka 集群（多个 Broker）将消息持久化到对应 Partition
评分引擎（Consumer Group）从各 Partition 拉取事件
评分引擎执行规则计算，输出风险分数
分数结果写入下游（数据库、告警系统、业务回调）

关键设计原则： Partition 是并行度的上限。风控场景中，建议将 Partition 数设置为预期峰值 TPS / 单 Consumer 处理能力的 1.5~2 倍，预留弹性空间。

2.7 核心概念对比速查

对比维度	Topic	Partition	Broker	Producer	Consumer	Consumer Group
是否物理存储	逻辑概念	是（日志文件）	是（服务器）	否	否	逻辑概念
是否可扩展	可创建多个	可增加（需谨慎）	可水平扩展	可增加实例	可增加实例	可增加 Group
有序性保证	无	分区内有序	无	无	分区内有序	无
故障影响范围	无	Leader 切换	节点宕机	发送失败	Rebalance	Rebalance
风控配置要点	按事件类型拆分	≥ 预期 Consumer 数	≥ 3 节点	acks=all	手动提交 offset	唯一 Group ID

掌握这六大核心概念，就具备了搭建实时风控数据管道的基础。下一层我们将深入 Kafka 的存储与副本机制，确保评分数据在极端情况下不丢失、不重复。