实时事件流架构：Kafka核心概念、Topic与Partition设计、生产者与消费者模型

好，咱们进入第二章。这一章聊的是实时事件流的骨架——Kafka。说实话，我在风控系统里跟Kafka打交道好几年了，踩过的坑能绕公司三圈。今天我把这些经验掰开揉碎，跟你好好讲讲。

Kafka是什么？为什么风控离不开它？

Kafka说白了就是一个消息队列，但它不是普通的队列。它能把数据持久化到磁盘，能扛住百万级吞吐，还能保证数据不丢。我当年第一次接触Kafka时，心里想的是：这不就是个日志系统吗？后来才发现，它简直是实时风控的命脉。

你想想看，风控场景里，用户点击、支付、登录这些事件，每秒可能产生几十万条。如果用传统数据库去扛，早就挂了。Kafka的设计目标就是处理这种「洪水般的数据」。它把数据组织成Topic，每个Topic又分成多个Partition，这样就能并行处理，速度飞快。

Topic与Partition设计：我的血泪教训

Topic是Kafka里最基础的概念。你可以把它理解成一个「数据桶」，所有同类事件都往里面扔。比如风控系统里，我会建一个 risk_events 的Topic，专门放用户行为事件。

但光有Topic不够，还得有Partition。Partition是Topic的物理分片，每个Partition就是一个有序的日志文件。为什么需要Partition？因为单机处理能力有限，分片后才能水平扩展。

我记得有一次，我设计的Partition数量太少，只有3个。结果业务量一上来，消费者处理不过来，消息堆积了几百万条。风控模型迟迟拿不到数据，该拦截的没拦住，不该拦的反而误杀了。嗯，那天的复盘会开得特别漫长。

Partition数量怎么定？

我个人习惯用这个公式来估算：

Partition数 = max(生产者吞吐量 / 单个Partition写入速度, 
                  消费者吞吐量 / 单个Partition消费速度)

但别死板。我一般会留20%的余量。比如算出来需要8个，我就设10个。为什么？因为业务会增长，你不想三个月后又来改配置吧？

Partition与Key的关系

这里有个关键点：消息的Key决定了它进入哪个Partition。如果Key为null，Kafka会用轮询方式分配。如果指定了Key，比如用户ID，那么同一个用户的所有事件都会进入同一个Partition。

为什么这很重要？因为风控场景里，你需要保证同一个用户的事件是有序的。比如用户先登录、再支付、再提现，这个顺序不能乱。如果乱序了，风控模型可能会误判。

我曾经踩过这个坑：有个项目没设Key，结果同一个用户的「登录」和「支付」事件被分到了不同Partition，消费者处理时顺序全乱了。风控模型以为用户没登录就支付，直接给拦截了。用户投诉电话打爆了客服。

生产者模型：怎么把数据扔进Kafka？

生产者就是往Kafka里写数据的角色。在风控系统里，通常是各个业务系统（比如交易系统、登录系统）作为生产者，把事件发送到Kafka。

生产者的核心参数有几个，我挑重要的说：

参数	说明	我的推荐值
acks	确认机制，控制数据可靠性	all（风控场景必须全确认）
retries	发送失败重试次数	3
batch.size	批量发送大小	16KB
linger.ms	延迟发送时间	5ms

这里有个权衡：acks=all 最安全，但性能最差。风控场景里，数据丢失的代价远大于性能损耗，所以我一直用 all。你想想看，如果一条交易事件丢了，那笔交易可能就逃过风控了，后果不堪设想。

代码示例，我习惯用Java写生产者：

Properties props = new Properties();
props.put("bootstrap.servers", "localhost: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("batch.size", 16384);
props.put("linger.ms", 5);

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

// 发送事件
String userId = "user_12345";
String event = "{\"type\":\"login\",\"userId\":\"user_12345\",\"timestamp\":1700000000}";
producer.send(new ProducerRecord<>("risk_events", userId, event));
producer.close();

注意看，我把 userId 作为Key传进去了。这样同一个用户的事件就会进入同一个Partition，保证有序。

消费者模型：怎么从Kafka里拿数据？

消费者就是读取数据的角色。在风控系统里，通常是风控引擎作为消费者，从Kafka里拉取事件，然后跑模型、出结果。

消费者有个核心概念叫「消费者组」。同一个组里的消费者，会共同消费一个Topic的Partition。每个Partition只能被组内的一个消费者消费。这样做的好处是：你可以水平扩展消费者数量，提高处理速度。

举个例子：假设Topic有10个Partition，你起了3个消费者。那么Kafka会尽量平均分配，比如消费者A拿4个，B拿3个，C拿3个。如果某个消费者挂了，Kafka会自动把它的Partition分配给其他消费者。这就是所谓的「再均衡」。

消费者的偏移量（Offset）管理也很重要。Offset记录了消费者消费到了哪个位置。默认情况下，Kafka会自动提交Offset，但风控场景里我建议手动提交。为什么？因为自动提交可能丢数据。比如你消费了一条事件，还没来得及处理，Offset就提交了。然后消费者挂了，重启后从新Offset开始消费，那条没处理完的事件就丢了。

手动提交的代码示例：

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "risk-engine-group");
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("enable.auto.commit", "false");  // 手动提交

Consumer<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(Arrays.asList("risk_events"));

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
    for (ConsumerRecord<String, String> record : records) {
        // 处理事件，比如跑风控模型
        processEvent(record.value());
    }
    // 处理完成后手动提交
    consumer.commitSync();
}

这里我用了 commitSync()，它是同步提交，会阻塞直到提交成功。虽然性能差一点，但安全。如果你追求性能，可以用 commitAsync()，但要做好失败重试。

一张图看懂Kafka核心架构

说了这么多，我画张图帮你理一理思路。这张图展示了生产者、Topic、Partition、消费者组之间的关系。

这张图里，生产者把事件写入Topic，Topic内部有多个Partition。消费者组里的消费者各自负责不同的Partition，处理完后交给风控引擎。整个链路是解耦的，任何一个环节出问题，其他环节还能继续工作。

总结一下

这一章我们聊了Kafka的核心概念。Topic是数据桶，Partition是分片，生产者负责写，消费者负责读。风控场景里，数据可靠性和有序性是第一位的，所以acks要设all，Key要设用户ID，Offset要手动提交。

嗯，这些经验都是我一个个坑里爬出来的。你照着做，至少能避开80%的坑。剩下的20%，等你遇到了再来找我聊。

---

公众号:蓝海资料掘金营，微信deep3321