Kafka Streams、Connect 与生态

学习目标

Kafka 不只是消息中间件，还包含流处理、数据集成和跨集群复制生态。本章覆盖：

Kafka Streams：在应用内做流计算。
Kafka Connect：标准化数据采集和落地。
Schema Registry：治理事件结构。
MirrorMaker 2：跨集群复制。

Kafka Streams

Kafka Streams 是 Kafka 官方 Java 流处理库。它不是独立集群，而是嵌入你的应用进程。

适合：

实时计数。
订单状态聚合。
风控规则。
双流 join。
窗口统计。

不适合：

超大规模复杂 SQL 分析，优先考虑 Flink/Spark。
多语言团队强依赖非 Java 技术栈。

Streams 核心概念

概念	说明
KStream	无界事件流，每条记录都是事实
KTable	按 key 聚合后的最新状态
GlobalKTable	每个实例持有完整表副本
State Store	本地状态存储，通常基于 RocksDB
Window	时间窗口，如滚动窗口、滑动窗口、会话窗口

Streams 示例：统计订单金额

伪代码：

java 复制代码

StreamsBuilder builder = new StreamsBuilder();

KStream<String, OrderEvent> orders = builder.stream("order-events");

orders
    .filter((key, value) -> "PAID".equals(value.status()))
    .groupByKey()
    .aggregate(
        () -> BigDecimal.ZERO,
        (key, value, total) -> total.add(value.amount()),
        Materialized.as("order-amount-store")
    )
    .toStream()
    .to("order-amount-summary");

这段逻辑表达的是：

text 复制代码

读取 order-events -> 只保留 PAID -> 按订单 key 聚合金额 -> 输出汇总 topic

Kafka Connect

Kafka Connect 用于把外部系统与 Kafka 连接起来，减少每个团队重复写采集和落地代码。

两类 Connector：

类型	方向	示例
Source Connector	外部系统 -> Kafka	MySQL CDC、文件、MQ、HTTP
Sink Connector	Kafka -> 外部系统	Elasticsearch、S3、HDFS、JDBC

典型链路：

text 复制代码

MySQL binlog -> Debezium Source Connector -> Kafka -> Elasticsearch Sink Connector

Connect 运行模式

模式	说明	适用
Standalone	单进程、本地配置	本地测试
Distributed	多 worker、Kafka 存状态	生产环境

生产建议使用 Distributed 模式，因为它支持：

worker 扩容。
connector task 分配。
配置存储在 Kafka topic。
故障后自动恢复。

Schema Registry

随着 topic 被多个系统订阅，事件结构必须治理。否则一个字段改名就可能导致多个消费者失败。

常见格式：

JSON：简单直观，但缺少强约束。
Avro：常配合 Schema Registry，适合数据平台。
Protobuf：跨语言强类型，体积较小。

Schema 演进规则：

变更	是否安全	说明
新增可选字段	通常安全	老消费者可忽略
删除必填字段	不安全	老消费者可能解析失败
字段改名	不安全	等同删除旧字段
改变字段类型	不安全	需要版本兼容
新增事件类型	通常安全	消费端要有默认分支

推荐事件兼容策略：

text 复制代码

只新增可选字段，不随意删除或改名；破坏性变更使用新 topic 或 eventVersion。

MirrorMaker 2

MirrorMaker 2 用于 Kafka 集群间复制。

场景：

同城双活读取。
异地灾备。
机房迁移。
云上云下数据同步。

复制链路：

text 复制代码

source cluster topic -> MM2 connector -> target cluster topic

注意事项：

跨集群复制有延迟，不是强一致。
topic 命名可能带 source cluster alias。
offset 同步需要额外配置和验证。
灾备切换前要明确 RPO/RTO。

生态选型

需求	Kafka 原生能力	何时换其他组件
简单实时聚合	Kafka Streams	复杂 SQL、超大状态用 Flink
数据采集落地	Kafka Connect	Connector 不成熟时自研
Schema 治理	Schema Registry	多语言强约束可选 Protobuf 平台
跨集群复制	MirrorMaker 2	云厂商托管复制能力更稳定时
延迟任务	不建议直接用 Kafka	用专门延迟队列或调度系统

实操建议

学习阶段：

先掌握普通 producer/consumer。
再学习 Connect，用现成 connector 接入文件或数据库。
再学习 Streams，理解流、表、窗口和状态。
最后学习 Schema 和跨集群复制。

生产阶段：

所有跨团队共享 topic 必须有 Schema 文档。
Connector 任务必须有错误队列、重试、监控和告警。
Streams 应用必须监控 lag、state store 大小、处理延迟。
跨集群复制必须定期演练切换。

学习目标

本章面向生产环境，解决 Kafka 上线后怎么治理：

集群部署和滚动升级。
监控指标和告警阈值。
安全认证与权限。
常见故障排查。
故障演练和运维清单。

生产集群基本建议

项目	建议
Broker 数量	至少 3 台
副本数	核心 topic 使用 3
`min.insync.replicas`	核心 topic 使用 2
磁盘	独立 SSD 或高性能云盘
机架感知	跨可用区部署时开启 rack awareness
JVM	固定堆大小，避免过大堆导致长 GC
版本	统一版本，滚动升级前读 release notes

Topic 治理规范

每个生产 topic 都应该登记这些信息：

字段	示例
Topic 名称	`order-events`
负责人	订单团队
数据级别	核心业务
Partition 数	24
副本数	3
保留时间	7 天
Schema 地址	文档或 Registry subject
生产者	order-service
消费者	inventory-service、risk-service
告警阈值	lag > 100000 持续 10 分钟

监控指标

Broker 指标

指标	含义	风险
`UnderReplicatedPartitions`	副本不足的 partition 数	broker 或网络异常
`OfflinePartitionsCount`	无 leader partition 数	topic 不可用
`ActiveControllerCount`	当前 controller 数	正常应为 1
`RequestHandlerAvgIdlePercent`	请求处理线程空闲率	过低表示 broker 忙
`NetworkProcessorAvgIdlePercent`	网络线程空闲率	过低表示网络线程忙
`BytesInPerSec` / `BytesOutPerSec`	入站/出站流量	容量和热点判断

Consumer 指标

指标	含义	处理
Consumer Lag	未消费消息数	扩容消费者或优化处理
Rebalance Rate	再均衡频率	排查实例波动和处理超时
Poll Latency	拉取延迟	broker 或网络问题
Processing Latency	业务处理耗时	下游慢或逻辑复杂

Producer 指标

指标	含义
request-latency-avg	请求平均延迟
record-error-rate	发送错误率
record-retry-rate	重试率
batch-size-avg	平均批次大小
compression-rate-avg	压缩效果

告警建议

告警	建议阈值
Offline partition	大于 0 立即告警
Under replicated partition	大于 0 持续 5 分钟告警
Controller 不为 1	立即告警
磁盘使用率	大于 75% 预警，大于 85% 严重
Consumer lag	按业务 SLA 设置，例如 10 分钟未下降
Producer error rate	大于 0.1% 持续 5 分钟
Rebalance 频繁	10 分钟内多次

安全

Kafka 安全包含三层：

传输加密：SSL/TLS。
身份认证：SASL/PLAIN、SCRAM、Kerberos、mTLS。
授权：ACL。

ACL 示例：

bash 复制代码

kafka-acls --bootstrap-server kafka-1:9092 \
  --add \
  --allow-principal User:order-service \
  --operation Write \
  --topic order-events

给消费组授权：

bash 复制代码

kafka-acls --bootstrap-server kafka-1:9092 \
  --add \
  --allow-principal User:inventory-service \
  --operation Read \
  --topic order-events \
  --group inventory-service

安全原则：

按服务账号授权，不共享账号。
生产者只给写权限。
消费者只给读 topic 和读 group 权限。
禁止业务服务拥有集群级管理权限。
密钥定期轮换。

常见故障排查

消费堆积

排查顺序：

查看 lag 是否持续增长。
看消费者日志是否报错或重试。
看单条处理耗时和批处理耗时。
看下游数据库、缓存、HTTP 是否慢。
看消费者实例数是否小于 partition 数。
看是否频繁 rebalance。

临时处理：

扩容消费者实例。
降低每条消息处理成本。
暂停非核心消费者。
将坏消息转入 DLT。
对下游做限流保护。

ISR 缩小

排查顺序：

Broker 是否宕机。
网络是否抖动。
磁盘 IO 是否高。
follower 是否 GC 或 CPU 飙高。
topic 写入是否突增。

风险：acks=all 且 ISR 小于 min.insync.replicas 时，producer 会写入失败。这是保护机制，不应该直接降低可靠性配置掩盖问题。

Producer 超时

常见原因：

broker 请求队列满。
topic leader 不可用。
ISR 不足导致无法满足 acks=all。
网络延迟高。
生产端 buffer 满。

排查指标：

producer request latency。
producer buffer available bytes。
broker request handler idle。
under replicated partitions。

滚动升级

升级前：

备份配置。
确认 controller 和 broker 状态健康。
检查 under replicated partitions 为 0。
阅读版本兼容说明。
先升级非核心或测试集群。

升级中：

text 复制代码

停止一台 broker -> 升级 -> 启动 -> 等 ISR 恢复 -> 升级下一台

升级后：

检查 controller 数。
检查 ISR。
检查 producer error rate。
检查 consumer lag。
检查日志异常。

故障演练

演练	目的	验证
停一台 broker	验证副本容错	topic 可读写，ISR 可恢复
停消费者实例	验证 rebalance	其他实例接管 partition
下游数据库变慢	验证背压	消费者不崩溃，lag 可控
写入坏消息	验证 DLT	坏消息进入死信 topic
磁盘逼近阈值	验证容量告警	告警触发，扩容流程明确