1. 课程导入与全景认知
在企业系统里，数据往往不是“没有”，而是散落在 ERP、CRM、订单、库存、支付、风控、数据仓库与实时报表等几十个系统中。传统做法是系统之间点对点调用接口：订单系统调库存、库存调仓储、支付回调订单、报表再定时抽数。系统一多，接口数量按平方级增长，任何一方改字段、停机或流量突增，都会沿着调用链把故障放大。Confluent 要解决的核心问题，正是把这种“系统之间互相直连”的网状结构，改造成以事件流为中心的中枢结构：各系统只负责把业务事实写成事件，也只从自己关心的事件流中读取数据，从而让生产者与消费者解耦、可回放、可扩展。
从定位上看，Confluent 是构建在 Apache Kafka 之上的企业级数据流平台。Kafka 提供分布式提交日志、分区、副本、消费者组等底层能力；Confluent 在此基础上补齐了 Schema Registry、Kafka Connect、ksqlDB、Confluent Control Center、REST Proxy、集群链接、分层存储、RBAC 与审计等企业能力。它既不是单纯的“消息队列”，也不是传统 ETL 工具，而是把消息中枢、数据集成、流处理与治理统一到同一套事件底座上。理解这一点，是后续所有章节的起点。
这张全景图里，最值得先记住的是“事件流”这个中心对象。业务系统产生的事件，例如“订单已创建”“库存已扣减”“支付已成功”，被写入 Topic；Topic 再按 Partition 水平切分，每个 Partition 是一个有序、可追加的提交日志，消息一旦写入就获得递增 Offset。消费者组按 Offset 记录消费进度，因此可以重复读取、回溯历史，也可以让多个消费者并行分担分区。这个模型决定了 Confluent 与普通消息队列的根本差异：消息不是“消费完就消失”，而是按保留策略持久化，成为可重放的数据事实。
围绕这个核心，Confluent 的组件可以按“接入—中枢—治理—处理—消费”五层来理解。接入层由 Kafka Connect 与 REST Proxy 承担，前者用连接器把数据库、文件、对象存储、SaaS 系统的数据持续同步进 Topic，后者让非 Java 系统通过 HTTP 写入和读取。中枢层是 Broker 集群，负责分区、副本、Leader 选举、ISR 同步与分层存储。治理层由 Schema Registry 与 Control Center 等组成，Schema Registry 为每个 Topic 的键和值定义 Avro、Protobuf 或 JSON Schema 契约，生产者与消费者在读写时校验兼容性，避免上游改字段导致下游批量失败。处理层由 ksqlDB 与 Kafka Streams 提供流式过滤、聚合、窗口计算和流表连接。消费层则把处理结果写回 Topic 或推送到数据仓库、搜索、缓存和实时应用。
为了把抽象定位落到具体参数上，可以看一个贯穿课程的示例场景：订单系统向 orders.created 写入订单事件，库存系统订阅后扣减库存，风控系统订阅后做实时判断，数据仓库订阅后落仓分析。假设该 Topic 设置为 6 个分区、副本因子 3、最小同步副本 2，保留 7 天。生产者使用 acks=all 保证消息写入所有同步副本后才确认；消费者组 inventory-service 有 3 个实例，每个实例分到 2 个分区，实现并行消费。若某个 Broker 宕机，分区 Leader 会在 ISR 中重新选举，只要同步副本数不低于 2，写入仍可继续。这些参数不是装饰，而是决定吞吐、可靠性与延迟的关键旋钮。
# 示例：创建一个订单事件 Topic（参数为教学假设值）
kafka-topics --create \
--topic orders.created \
--partitions 6 \
--replication-factor 3 \
--config min.insync.replicas=2 \
--config retention.ms=604800000
# 示例：生产者关键参数
acks=all
enable.idempotence=true
max.in.flight.requests.per.connection=5
# 示例：消费者组关键参数
group.id=inventory-service
auto.offset.reset=earliest
enable.auto.commit=false学习路径上，建议按“先通链路、再补治理、后做优化”的顺序推进。第一步先理解 Topic、Partition、Offset、Consumer Group 四个基本对象，能画出事件从生产到消费的完整路径；第二步掌握 Schema Registry 与数据契约，知道如何注册 Schema、判断兼容性、处理 Schema 演进；第三步进入 Kafka Connect 与 CDC，能把 MySQL 的 binlog 持续同步到 Topic；第四步学习 ksqlDB 与 Kafka Streams，完成过滤、聚合、窗口和流表连接；第五步再深入副本一致性、ISR、分层存储、RBAC、监控与容量规划。这个顺序的好处是，每一层都建立在上一层已经跑通的链路上，而不是先陷入参数细节。
实战目标可以归纳为三条可检验的成果。第一，能独立搭建一条从业务库到 Topic 再到下游消费的端到端链路，并用命令行或 Control Center 观察到消息写入、Offset 增长和消费滞后。第二，能为关键 Topic 设计分区数、副本因子、保留策略和 Schema 契约，并说明每个参数对可靠性、吞吐和成本的影响。第三，能定位常见异常，例如消费者滞后持续增大、ISR 收缩、Schema 不兼容导致生产失败、分区倾斜导致单分区过热，并给出可执行的排查与调整方案。后续章节会围绕这三条目标逐步展开，每一节都对应全景图中的一个具体环节。