一、数据总线与消息队列：Kafka 在风电场景的核心实践
各位好，我是老张。今天咱们聊聊 Kafka。
说实话，在风电大数据平台里，Kafka 就像整个系统的「血管」。风机每秒都在产生海量数据——振动、温度、转速、功率……这些数据如果不能及时、可靠地流转到下游，那什么实时预警、故障诊断都是空谈。
我最早接触风电项目时，团队用的是 RabbitMQ，结果一到高峰期就丢消息。后来全面迁移到 Kafka，才算真正解决了问题。今天我就把这些年踩过的坑、总结的经验，一次性讲清楚。
1.1 Kafka 核心概念：别被术语吓住
先过一遍基础。Kafka 的核心概念其实就几个：
- Producer：消息生产者。在风电场景里，就是每台风机上的数据采集终端。
- Consumer：消息消费者。比如实时计算引擎、数据仓库、告警服务。
- Broker：Kafka 服务器节点。说白了就是存消息的机器。
- Topic：消息类别。比如「风机振动数据」「风机温度数据」各是一个 Topic。
- Partition：Topic 的分区。这是 Kafka 实现高吞吐的关键。
- Offset：消息在分区内的位置编号。消费者靠它知道自己读到哪了。
嗯，这里要注意：Partition 是 Kafka 并行处理的核心。一个 Topic 可以有多个 Partition，每个 Partition 内部是有序的，但 Partition 之间不保证顺序。
我的经验：刚开始做风电项目时，我习惯把每个风场的数据单独放一个 Topic。后来发现风场数量一多，Topic 管理变得极其混乱。现在我建议按数据类型分 Topic，按风场 ID 或风机 ID 做 Partition 键。这样既清晰，又方便扩展。
1.2 Topic 与 Partition 设计：风电场景的特殊考量
Topic 和 Partition 怎么设计？这问题我当年也纠结过。直接说结论：
Topic 划分原则
- 按数据类型划分：振动数据、温度数据、功率数据、状态数据各一个 Topic。
- 按数据重要程度划分：关键告警数据单独一个 Topic，普通运行数据另一个。
- 避免过多 Topic：Kafka 集群对 Topic 数量有限制，太多 Topic 会影响性能。
Partition 数量设计
Partition 数量 = 你期望的吞吐量 ÷ 单个 Partition 的吞吐量。但实际项目中，我一般这样估算：
| 场景 | 数据量 | 建议 Partition 数 |
|---|---|---|
| 小型风场（10-20台风机） | ~50MB/s | 6-12 |
| 中型风场（50-100台风机） | ~200MB/s | 24-48 |
| 大型风场（200+台风机） | ~1GB/s | 64-128 |
避坑指南：我曾经在一个项目里把 Partition 设成了 256 个，结果 Broker 频繁触发 rebalance，消费者组来回震荡。后来发现，Partition 数不是越多越好。一般建议 Partition 数不超过 Broker 数的 10 倍。
1.3 数据可靠性保证：消息到底丢没丢？
做风电的人最怕什么？数据丢了！
Kafka 提供了三个维度的可靠性保证，我一个个说：
1.3.1 Producer 端：acks 参数
acks=0：不等待确认。性能最高，但可能丢消息。acks=1：等待 Leader 确认。默认值，性能与可靠性平衡。acks=all：等待所有副本确认。最安全，但延迟最高。
我的建议：风电场景下，关键数据（如振动、温度）用 acks=all，普通运行数据用 acks=1。别为了省那点延迟把命根子丢了。
1.3.2 Broker 端：副本机制
Kafka 的副本机制说白了就是「多存几份」。每个 Partition 可以有多个副本，其中一个叫 Leader，其余叫 Follower。
- 副本数建议：生产环境至少 3 个副本。
- ISR（In-Sync Replicas）：只有与 Leader 保持同步的副本才算 ISR。如果某个副本落后太多，会被踢出 ISR。
注意：副本数不是越多越好。我见过有人设了 5 个副本，结果集群网络带宽被副本同步占满，正常业务反而受影响。3 个副本是经过验证的最佳实践。
1.3.3 Consumer 端：手动提交 Offset
默认情况下，Kafka 消费者是自动提交 Offset 的。但自动提交有个问题：如果消费者在处理消息的过程中挂了，重启后会从已提交的 Offset 开始消费，中间那批消息就丢了。
解决方案：手动提交 Offset。等消息处理完再提交，确保不丢消息。
// 伪代码示例：手动提交 Offset
while (true) {
ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
for (ConsumerRecord<String, String> record : records) {
// 处理消息
process(record);
// 处理完成后手动提交
consumer.commitSync();
}
}1.4 Kafka 在风电场景的调优实践
理论说完了，来点干货。这是我在多个风电项目里总结出来的调优经验：
1.4.1 批量与压缩
风电数据的特点是「小消息、高频率」。每条消息可能只有几十字节，但每秒几万条。这时候批量发送和压缩就特别重要。
- batch.size：建议设为 16KB-64KB。太小了浪费网络带宽，太大了增加延迟。
- linger.ms：建议设为 5-10ms。让 Producer 等一会儿，攒够一批再发。
- compression.type：建议用 snappy 或 lz4。压缩比高，CPU 开销小。
1.4.2 内存与 JVM 调优
Kafka 重度依赖操作系统页缓存。说白了，Kafka 自己不做缓存，全靠 OS 的 Page Cache。
- 建议给 Kafka 分配 6-8GB 堆内存，剩下的内存留给 OS 做 Page Cache。
- JVM 垃圾回收器：用 G1GC。我见过用 CMS 的，Full GC 一来，整个集群卡住好几秒。
1.4.3 磁盘与 I/O
Kafka 是顺序写磁盘的，所以机械硬盘也能跑。但风电场景数据量大，建议用 SSD。
- 挂载多块磁盘做 RAID0，或者用 JBOD 模式。
- 每个 Broker 至少 4 块磁盘，分散 I/O 压力。
我的实战案例：某风场项目，初期用 3 台 Broker，每台 2 块 1TB HDD。结果高峰期磁盘 I/O 打满，消息堆积到几百万条。后来换成 6 台 Broker，每台 4 块 SSD，问题彻底解决。说白了，硬件投入不能省。
1.4.4 网络与连接
风电场的网络环境往往不太理想——带宽有限、延迟高、偶尔断连。这时候需要调整 Kafka 的网络参数：
- max.in.flight.requests.per.connection：建议设为 1。防止乱序。
- retries：建议设为 3-5 次。网络抖动时自动重试。
- request.timeout.ms：建议设为 30s-60s。别设太短，风场网络延迟高。
1.5 知识体系总览
说了这么多，我画了一张图帮你梳理一下 Kafka 在风电场景的核心逻辑：
这张图把 Kafka 在风电场景的完整链路画出来了。从数据源到 Producer，再到 Kafka 集群的核心组件，最后到 Consumer 消费。每个环节都有对应的调优策略。
1.6 总结
Kafka 在风电场景里，说白了就是三个关键词：高吞吐、高可靠、可扩展。
- Topic 设计：按数据类型分，别按风场分。
- Partition 设计：数量适中，别贪多。
- 可靠性保证：关键数据用 acks=all，手动提交 Offset。
- 调优实践：批量发送、压缩、合理配置内存和磁盘。
嗯，今天就聊到这儿。下一章咱们讲讲 Kafka 在风电场景的监控与运维——毕竟，光会搭不会管，等于白干。