在CDN业务中，成百上千个边缘节点每天都在产生海量的访问日志、带宽统计数据和健康检查信息。如果这些数据直接同步写入数据库或者由中心服务逐台拉取，系统很容易在流量高峰期被打垮。Kafka作为一款成熟的分布式消息队列，恰好能解决这类问题：节点把数据异步投递到Kafka，下游的日志分析、计费、监控等系统按自己的节奏消费，上下游彻底解耦。本文就从架构、代码和配置三个层面，聊聊CDN场景下Kafka的实践要点。
一、CDN场景下为什么需要Kafka
CDN的边缘节点分布在全国甚至全球各地，每个节点都会定时上报访问日志、带宽峰值、缓存命中率等指标。假设有1000个节点，每个节点每秒上报100条数据，就是每秒10万条的写入压力。如果中心服务采用同步接口接收，一旦下游的统计分析模块处理变慢，请求就会堆积，最终导致数据丢失或节点上报阻塞。
引入Kafka之后，整个数据链路变成了典型的生产者-消费者模型。边缘节点作为Producer把日志写入Kafka的Topic，Kafka负责把数据持久化到磁盘并按Partition分布到多个Broker上，下游的消费组各自独立拉取数据。这样一来，即使某个下游系统故障几小时，数据依然完好地保存在Kafka中，恢复后可以从上次的消费位置继续处理，这就是所谓的削峰填谷和故障隔离能力。
此外，Kafka的顺序写磁盘加上零拷贝传输机制，让它单机就能轻松支撑每秒几十万条消息。对于CDN这种写多读少、允许少量延迟但对可靠性要求高的场景，Kafka几乎是标配选择。
二、核心概念与分区设计
Kafka有几个绕不开的概念。Topic是逻辑上的消息分类，比如可以为访问日志建一个cdn-access-log的Topic，为节点心跳建一个cdn-node-heartbeat的Topic。Partition是Topic的物理分片，同一个Partition内的消息严格有序，不同Partition之间不保证顺序。Consumer Group是消费组，同一个组内的消费者平分Partition，不同组之间互不干扰。
分区数量的设计需要权衡。分区越多，并行度越高，但也会增加Broker端的文件句柄和元数据开销。对于CDN日志上报场景，一般建议按节点数量和下游消费者的处理能力来估算，比如1000个节点、下游部署6个消费者实例，设置12到24个分区比较合理。另外要特别注意Partition数只能增加不能减少，上线前要规划好。
消息的Key也很有讲究。Kafka默认按Key的哈希值决定消息落入哪个Partition，如果希望同一个节点的日志按时间顺序被消费，可以用节点ID作为Key，这样同一节点的数据会进同一个分区，保证局部有序。
三、生产者与消费者代码实践
下面用Java客户端演示CDN节点日志上报的核心代码。生产者部分开启了幂等和确认机制，保证消息不丢失。
Properties props = new Properties();
props.put("bootstrap.servers", "kafka1.ipipp.com:9092,kafka2.ipipp.com: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", 5); // 失败重试次数
props.put("enable.idempotence", "true"); // 开启幂等，防止重复消息
Producer<String, String> producer = new KafkaProducer<>(props);
String logLine = "node-bj-01|2024-06-01 10:00:00|GET /video.mp4|HIT|102400";
// 用节点ID作为Key，保证同一节点数据进入同一分区
producer.send(new ProducerRecord<>("cdn-access-log", "node-bj-01", logLine));
producer.close();
消费者部分需要注意消费位置的手动提交，避免自动提交导致消息丢失。下面的代码演示了一个负责统计带宽的消费组。
Properties props = new Properties();
props.put("bootstrap.servers", "kafka1.ipipp.com:9092");
props.put("group.id", "bandwidth-stat-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"); // 关闭自动提交
KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(Collections.singletonList("cdn-access-log"));
while (true) {
ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(500));
for (ConsumerRecord<String, String> record : records) {
// 解析日志并累计带宽
System.out.println("partition=" + record.partition()
+ " offset=" + record.offset()
+ " value=" + record.value());
}
consumer.commitSync(); // 处理完成后再同步提交位移
}
四、可靠性配置与常见踩坑点
要保证CDN数据管道不丢消息，需要生产端、Broker端、消费端三方配合。生产端设置acks=all并开启重试；Broker端设置replication.factor至少为3，min.insync.replicas设置为2，避免单机故障导致数据不可用；消费端坚持先处理完业务再提交位移的原则。
实践中常见的坑有几个。一是消费速度跟不上生产速度导致积压，此时可以增加消费者实例数量，但要注意实例数超过分区数后多出来的实例会空闲，必要时得扩分区。二是消息体过大，CDN日志如果单条超过1MB会被默认配置拒绝，建议在节点侧做压缩或者分片上报。三是重复消费，比如消费组发生再均衡时未提交位移会导致部分消息被重新处理，下游业务最好做好幂等设计，例如用日志的唯一ID去重。
最后建议对Kafka集群本身做好监控，重点关注消息延迟、消费组Lag值和磁盘使用率这三个指标，Lag持续增长往往意味着下游处理能力不足，是扩容的明确信号。只要架构和配置到位，Kafka完全能够支撑CDN这种大规模、高并发的数据分发需求。