Kafka生产者十八般武艺：从“发出去”到“发得好”，高手进阶之路
大家好，又见面了！今天我们还是用送快递的案例来继续聊聊，通过通俗易懂的方式让大家更加了解Kafka家族中那位勤勤恳恳的“快递员”——生产者（Producer）。在我们的数据世界里，它扮演着至关重要的角色，负责将宝贵的数据包裹（消息）安全、高效地送往Kafka这个庞大的“物流中转中心”。
这就像我们生活中寄快递一样。最开始，我们可能只是简单地把信件投进邮筒，至于它什么时候到、会不会丢，我们心里其实没底，这是一种“尽力而为”的发送。后来，有了挂号信，邮局会给你一个回执，告诉你他们收到了，这让我们安心了不少。再后来，有了顺丰、京东这样的现代物流，你不仅能实时追踪包裹的每一个动态，还能要求“签收回执”，确保收件人本人签收才算完成。如果包裹很重要，你甚至会要求保价，万一丢了还能获得赔偿。更进一步，如果你是一家大公司，每天要寄送成千上万的包裹，你可能还会和物流公司定制专属的派送路线，比如“所有发往北京的加急件，都走航空专线”，以确保最高的效率和最合理的成本。
我们今天的主角——Kafka生产者，它的成长之路也是如此。从最基础的“只管发，不管收”，到追求数据万无一失的“可靠投递”，再到处理海量数据时可能遇到的“重复投递”问题，以及对特定数据流“顺序”的严格要求，甚至根据业务需求定制“专属投递路线”。
第一章：如何确保消息“一定”发出去了？（ACK机制）
理解了现象后，我们来看现实中的第一个核心问题。作为开发者，当我们调用producer.send(message)时，最关心的莫过于：“这条消息，到底成功了没有？”。如果这是一笔支付成功的通知，或是一个关键的用户行为日志，它的丢失可能会导致严重的业务问题。我们绝不能像把信扔进邮筒那样，对消息的后续命运一无所知。我们需要一个明确的“回执”机制，来告诉我们投递任务的完成情况。在Kafka的世界里，这个回执机制就是大名鼎鼎的ACK（Acknowlegement）机制。它为我们提供了不同等级的可靠性承诺，让我们可以在性能和数据可靠性之间做出权衡。这就像选择快递服务，你可以选择平邮、挂号信，还是需要签收回执的特快专递。接下来，让我们一起来看看这三种不同的“服务等级”是如何运作的。
整体执行流程
ACK机制的核心思想是，生产者在发送消息后，等待Broker返回确认信号。根据生产者配置的acks参数不同，Broker返回确认的时机也不同，从而决定了消息的可靠性等级。
- acks = 0: 生产者发送消息后，不等待Broker的任何确认。只要消息在网络上发出，就认为成功。
- acks = 1 (默认): 生产者发送消息后，等待Partition的Leader Broker成功写入本地日志后，返回确认。
- acks = -1 (或 all): 生产者发送消息后，等待Partition的Leader Broker和所有ISR（In-Sync Replicas，同步副本）中的Follower Broker都成功写入日志后，才返回确认。
上图清晰地展示了不同 `acks` 配置下的决策流程和它们各自的特点，帮助我们直观地理解性能与可靠性之间的权衡。
技术原理与案例代码
在Java客户端中，配置acks非常简单，只需要在Producer的配置中加入一个参数即可。我通常是这样做的：
import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerConfig;
import org.apache.kafka.clients.producer.ProducerRecord;
import org.apache.kafka.common.serialization.StringSerializer;
import java.util.Properties;
public class AckMechanismDemo {
public static void main(String[] args) {
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
// ****** 核心配置在这里 ******
// 场景1: 最高吞吐量，但可能丢数据
// props.put(ProducerConfig.ACKS_CONFIG, "0");
// 场景2: 默认配置，可靠性和性能的平衡
// props.put(ProducerConfig.ACKS_CONFIG, "1");
// 场景3: 最高可靠性，保证数据不丢失
props.put(ProducerConfig.ACKS_CONFIG, "all"); // 或者 "-1"
try (KafkaProducer<String, String> producer = new KafkaProducer<>(props)) {
ProducerRecord<String, String> record =
new ProducerRecord<>("critical-data-topic", "order-id-123", "order-details");
// 异步发送，通过Callback获取结果
producer.send(record, (metadata, exception) -> {
if (exception == null) {
System.out.printf("消息发送成功！Topic: %s, Partition: %d, Offset: %d%n",
metadata.topic(), metadata.partition(), metadata.offset());
} else {
System.err.println("消息发送失败: " + exception.getMessage());
// 在这里可以加入重试逻辑或者记录失败日志
}
});
producer.flush(); // 确保消息被发送出去
}
}
}
代码说明： 上述代码演示了如何配置acks参数。考虑到实际生产环境中，我们不能容忍关键数据的丢失，因此代码中默认使用了acks="all"。同时，我们使用了producer.send方法的异步回调形式，这是最佳实践。无论发送成功还是失败，我们都能在回调函数中得到通知，从而进行相应的处理，比如记录日志或者触发告警。
原理详细解释
让我们用寄快递的例子，来一步步拆解这三种ACK模式。
上面的序列图生动地展示了不同`acks`级别下，生产者、Leader节点和Follower节点之间的交互时序，一目了然。
- acks = 0 (扔进邮筒): 生产者把消息丢给网络连接后就拍拍屁股走人了。这就像你把信扔进街边的邮筒，你相信邮递员会收走，但没有任何凭证。优点是速度极快，网络开销最小。缺点是如果当时Broker宕机或者网络抖动，消息就永远丢失了，而你毫不知情。适用于对丢失不敏感的数据，如监控指标、日志采集等。
- acks = 1 (挂号信): 生产者发送消息后，会一直等待，直到Leader Broker（分区的“主负责人”）成功将消息写入自己的磁盘日志中。这就像你去邮局柜台寄挂号信，工作人员收下并盖章后，给了你一张回执。这证明邮局已经收到了你的信。优点是可靠性大大提高，性能也不错。缺点是，如果在Leader返回ACK后，但数据还没来得及同步给Follower副本时，Leader宕机了，那么新选举出的Leader上就没有这条数据，导致数据丢失。
- acks = -1 (特快专递+全员签收): 这是最强的可靠性保证。生产者不仅要等Leader写入成功，还要等所有在ISR列表中的Follower副本都从Leader那里同步完这条数据，并向Leader发送确认后，Leader才会向生产者返回最终的ACK。这就像一份绝密文件，不仅要送到收件公司，还必须该公司所有相关负责人都签字确认后，快递员才能离开。优点是几乎不会丢数据。缺点是，它需要等待整个同步链条完成，延迟最高，对网络带宽要求也更高。
记住，这个细节很重要：选择
acks=-1，必须配合min.insync.replicas参数使用才有意义。这个参数在Broker端配置，表示一个分区至少要有多少个副本（包括Leader）处于ISR状态，才能对外提供写服务。通常建议设置为min.insync.replicas > 1，比如2。这样，配合acks=-1，就能确保数据至少写入了两个不同的Broker上，才算成功，大大增强了容灾能力。
第二章：消息发重了怎么办？（幂等性Producer）
理解了现象后，我们来看一个新的挑战。为了实现最高级别的数据可靠性，我们选择了acks=-1。但网络是不可靠的，可能会发生这样的情况：Broker已经成功处理了消息，但在返回ACK给生产者的途中网络断了，或者ACK延迟到达。生产者因为没收到ACK，会认为发送失败，然后触发重试机制（通过retries参数配置）。结果，同一条消息被发送了两次，导致数据重复。对于订单、支付这类业务，数据重复是灾难性的。这就像你网上支付，因为网络问题，你点了一次“支付”按钮，但系统处理了两次，扣了你双倍的钱，这谁能接受？为了解决这个“天大”的难题，Kafka引入了优雅的解决方案——幂等性（Idempotence）生产者。让我们一起来看看，它是如何施展魔法，让重复的请求只被处理一次的。
整体执行流程
开启幂等性后，Kafka的生产者和Broker内部会协同工作，自动为我们处理消息的去重。
-
生产者初始化：生产者启动时，会向Kafka集群申请一个唯一的生产者ID（PID）。
-
发送消息：对于每个分区，生产者内部会维护一个从0开始递增的序列号（Sequence Number）。每发送一条消息，序列号就加1。PID和序列号会随着消息一起被发送给Broker。
-
Broker处理：Broker会为每个【PID-Partition】组合缓存最新的序列号。当收到消息时，它会检查消息中的序列号。
- 如果收到的序列号比缓存中的大1，说明是新消息，正常处理。
- 如果收到的序列号小于或等于缓存中的，说明是重复消息，直接丢弃，并向上游返回成功的ACK。
上图是一个状态图，描述了幂等性生产者从初始化获取PID，到循环发送带有序列号的消息，再到Broker端进行判断的核心状态流转。
技术原理与案例代码
开启幂等性非常简单，只需要一个配置参数。我建议大家这样使用，因为它几乎没有性能损失，却能带来巨大的可靠性提升。
import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerConfig;
import org.apache.kafka.clients.producer.ProducerRecord;
import org.apache.kafka.common.serialization.StringSerializer;
import java.util.Properties;
public class IdempotentProducerDemo {
public static void main(String[] args) {
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
// ****** 开启幂等性的魔法开关 ******
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true");
// 注意：开启幂等性后，以下参数会自动调整为推荐值，无需手动设置，但了解一下有好处
// acks 会被强制设为 "all"
// retries 会被设为一个很大的值 (Integer.MAX_VALUE)
// max.in.flight.requests.per.connection 会被设为 5 (Kafka 2.x及以后) 或 1 (早期版本)
try (KafkaProducer<String, String> producer = new KafkaProducer<>(props)) {
for (int i = 0; i < 3; i++) {
// 模拟发送同一条消息
ProducerRecord<String, String> record =
new ProducerRecord<>("payment-topic", "user-A-payment", "amount:100");
producer.send(record, (metadata, exception) -> {
if (exception == null) {
System.out.printf("消息发送成功！Topic: %s, Partition: %d, Offset: %d%n",
metadata.topic(), metadata.partition(), metadata.offset());
} else {
System.err.println("消息发送失败: " + exception.getMessage());
}
});
}
producer.flush();
}
}
}
代码说明： 启用幂等性，我们只需要将enable.idempotence设置为true。Kafka客户端会自动帮我们处理好一切。这个配置背后，Kafka默默地将acks设置为了all，并开启了无限重试，这是为了确保在启用幂等性的前提下，消息不会因为重试次数耗尽而丢失。这种设计思路非常巧妙，即在保证“At Least Once”的基础上，通过幂等性机制裁剪掉重复的消息，从而实现了“Exactly Once”的投递语义（单分区内）。
原理详细解释
让我们把这个过程想象成去银行柜台存钱。
-
办理银行卡 (获取PID): 你第一次去这家银行，会办理一张银行卡，卡号是唯一的。这个卡号就是PID。
-
填写存款单 (附加序列号): 你每次存钱，都需要填写一张存款单，上面有个业务流水号。你第一次存钱，流水号是1；第二次是2，以此类推。这个流水号就是Sequence Number。
-
柜员处理 (Broker校验): 你把存款单和钱交给柜员。
- 柜员看了看你的卡号（PID），查了一下电脑里你上次的流水号是0。你这次给的是1，没问题，是新业务，他帮你存钱，并把系统里你的最新流水号更新为1。
- 假设这时网络不好，你以为没成功，又递了一次流水号为1的存款单。柜员再次看到你的卡号，查到系统里你的最新流水号已经是1了。你现在给的还是1，他立刻明白：“哦，这是重复操作。” 于是他不会再帮你存一次钱，而是直接告诉你：“先生，您这笔业务已经办好了。”（返回成功的ACK）。
温馨提示：Kafka的幂等性是分区级别的，并且只在单个生产者会话（即Producer实例的生命周期内）有效。如果你重启了生产者，PID会变，序列号会重置。如果想实现跨会话、跨分区的严格一次性，就需要引入Kafka事务（Transactional Producer）。
第三章：想让消息按顺序处理，怎么发？（指定Partition Key）
我们现在已经能做到可靠且不重复地发送消息了，真是太棒了！但新的需求又来了。在某些场景下，消息的消费顺序至关重要。比如:
一个电商订单的状态变更消息：已下单 -> 已付款 -> 已发货 -> 已签收。如果消费者收到的顺序是“已下单 -> 已发货 -> 已付款”，那业务逻辑就全乱了。Kafka本身只能保证在一个分区（Partition）内消息是有序的，而一个Topic通常有多个分区来提高吞吐量。那么，我们如何确保“同一订单”的所有相关消息，都能被发送到“同一个分区”，从而被消费者按顺序处理呢？答案就是——为消息指定一个Key。这就像我们管理文件，会把所有关于“项目A”的文档都放进名为“项目A”的文件夹里，这样查找和处理起来就井井有条了。
整体执行流程
当生产者发送一条带有Key的消息时，Kafka会通过一个分区器（Partitioner）来决定这条消息该去往哪个分区。默认的分区策略如下：
- 检查Key: 判断消息的
ProducerRecord中是否包含Key。 - 有Key: 对Key进行哈希运算（默认使用murmur2算法），然后将哈希值对Topic的分区总数取模，得到的结果就是目标分区的编号。
- 无Key: 消息会以轮询（Round-Robin）的方式，均匀地发送到Topic的所有可用分区中。
核心在于：只要Key相同，计算出的目标分区就一定相同。
上图的流程图清晰地展示了Kafka默认分区器的决策逻辑。带有相同Key的消息（如`order_123`）总是被路由到同一个分区，而没有Key的消息则被轮流分发。
技术原理与案例代码
在代码中指定Key非常简单，只需要在创建ProducerRecord对象时，传入Key参数即可。我通常是这样做的，大家可以参考一下。
import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerConfig;
import org.apache.kafka.clients.producer.ProducerRecord;
import org.apache.kafka.common.serialization.StringSerializer;
import java.util.Properties;
public class PartitionKeyDemo {
public static void main(String[] args) {
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true"); // 推荐开启
String topic = "order-status-topic";
String orderId = "ORD-20240520-001";
try (KafkaProducer<String, String> producer = new KafkaProducer<>(props)) {
// 确保同一订单的所有状态消息都使用相同的Key
producer.send(new ProducerRecord<>(topic, orderId, "CREATED"));
producer.send(new ProducerRecord<>(topic, orderId, "PAID"));
producer.send(new ProducerRecord<>(topic, orderId, "SHIPPED"));
producer.send(new ProducerRecord<>(topic, orderId, "DELIVERED"));
// 另一个订单的消息
String anotherOrderId = "ORD-20240520-002";
producer.send(new ProducerRecord<>(topic, anotherOrderId, "CREATED"));
producer.flush();
System.out.println("订单状态消息已发送。");
}
}
}
代码说明： 在上述代码中，我们为所有与订单ORD-20240520-001相关的消息都指定了相同的Key，即订单ID本身。这样一来，Kafka就能保证这四条消息会按照我们发送的顺序，依次进入同一个分区。消费者在消费这个分区时，就能按顺序处理这个订单的状态流转了。
原理详细解释
选择一个好的Key至关重要。一个好的Key应该具备以下特点：
- 业务关联性: Key必须与需要保证顺序的业务实体相关，如订单ID、用户ID、设备ID等。
- 分布均匀性: 如果Key的选择过于集中，比如所有消息都用了少数几个Key，会导致数据倾斜——少数分区数据量巨大，而其他分区很空闲，这会影响整个集群的负载均衡和吞吐量。因此，要选择基数（Cardinality）足够大的字段作为Key。
通过我的观察，我发现很多问题都可以通过选择合适的Key来解决。比如，在做用户画像系统时，使用用户ID作为Key，可以保证同一个用户的所有行为数据都在一个分区内，便于进行实时的聚合计算。
第四章：自定义分区策略：让消息去该去的地方
相信大家都对Key的作用有了深刻的认识。默认的分区策略（对Key哈希取模）在大多数情况下都工作的很好。但在某些特殊的业务场景下，我们可能需要更精细化的控制。比如，我们有一个业务，其中混杂了普通用户和VIP用户的数据。我们希望所有VIP用户的消息都进入一个特定的分区（比如分区0），以便下游有一个专门的、高优先级的消费者组来处理它们，提供更快的响应。而普通用户的消息则均匀地分布在其他分区。这时候，默认的分区器就无法满足我们的需求了。幸运的是，Kafka为我们提供了自定义分区策略的能力。这就像给我们的“快递公司”配备了一个智能分拣系统，可以根据包裹上的特殊标记（比如“VIP”标签），将其分拣到专属的传送带上。
整体执行流程
实现自定义分区策略，主要分为两步：
- 创建自定义分区器: 编写一个Java类，实现Kafka提供的
org.apache.kafka.clients.producer.Partitioner接口。在这个类中，我们可以根据自己的业务逻辑（比如根据消息的Key或Value）来决定消息应该发往哪个分区。 - 配置生产者: 在生产者的配置中，通过
partitioner.class参数，指定使用我们自己编写的分区器类。
上面的类图展示了自定义分区器的实现关系。我们只需要实现 `Partitioner` 接口，创建自己的 `VipPartitioner`，然后在 `KafkaProducer` 中配置使用它即可。
技术原理与案例代码
下面，我们就来动手实现一个前面提到的“VIP用户”分区策略。
第一步：编写自定义分区器
import org.apache.kafka.clients.producer.Partitioner;
import org.apache.kafka.common.Cluster;
import org.apache.kafka.common.InvalidRecordException;
import org.apache.kafka.common.PartitionInfo;
import org.apache.kafka.common.utils.Utils;
import java.util.List;
import java.util.Map;
public class VipPartitioner implements Partitioner {
private final String VIP_USER_PREFIX = "vip-";
@Override
public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
// 获取该topic的所有分区信息
List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
int numPartitions = partitions.size();
// 我们指定分区0为VIP专属分区
int vipPartition = 0;
if (keyBytes == null) {
throw new InvalidRecordException("Key cannot be null for VipPartitioner");
}
// 如果key以"vip-"开头，则发送到VIP专属分区
if (((String) key).startsWith(VIP_USER_PREFIX)) {
System.out.println("VIP user message, routing to partition " + vipPartition);
return vipPartition;
}
// 如果分区数小于等于1，非VIP用户也只能发到分区0
if (numPartitions <= 1) {
return 0;
}
// 普通用户的消息，均匀分布到除了VIP分区之外的其他分区
// 注意：这里我们使用哈希取模，但模的是 numPartitions - 1
int otherPartitions = numPartitions - 1;
int partition = (Utils.toPositive(Utils.murmur2(keyBytes)) % otherPartitions) + 1;
System.out.println("Normal user message, routing to partition " + partition);
return partition;
}
@Override
public void close() {
// 无需清理资源
}
@Override
public void configure(Map<String, ?> configs) {
// 无需配置
}
}
第二步：配置生产者使用该分区器
import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerConfig;
import org.apache.kafka.clients.producer.ProducerRecord;
import org.apache.kafka.common.serialization.StringSerializer;
import java.util.Properties;
public class CustomPartitionerDemo {
public static void main(String[] args) {
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
// ****** 指定使用我们的自定义分区器 ******
props.put(ProducerConfig.PARTITIONER_CLASS_CONFIG, VipPartitioner.class.getName());
String topic = "user-activity-topic";
try (KafkaProducer<String, String> producer = new KafkaProducer<>(props)) {
// VIP用户消息
producer.send(new ProducerRecord<>(topic, "vip-user-1", "Logged in"));
producer.send(new ProducerRecord<>(topic, "vip-user-2", "Viewed product A"));
// 普通用户消息
producer.send(new ProducerRecord<>(topic, "normal-user-101", "Added to cart"));
producer.send(new ProducerRecord<>(topic, "normal-user-102", "Searched 'kafka'"));
producer.flush();
System.out.println("用户活动消息已发送。");
}
}
}
代码与思路说明： 在VipPartitioner中，我们的逻辑很清晰：检查消息的Key是否以"vip-"开头。如果是，直接返回分区0。如果不是，就对Key进行哈希，然后对“剩余的分区数”（numPartitions - 1）取模，再加1，确保结果落在[1, numPartitions - 1]这个区间内。考虑到实际业务的复杂性和健壮性，我们使用了Kafka内置的Utils.murmur2哈希算法和Utils.toPositive来确保结果为正数，这比简单的key.hashCode()更可靠。这种方案能精确地将不同类型的流量分发到不同的分区，为下游实现差异化服务提供了基础。
结尾：全文总结
通过今天的讨论，相信大家对Kafka生产者有了更深入的理解。我们从最基础的可靠性保障，一路探索到高级的顺序控制和路由定制，让我们的“数据快递员”变得越来越智能和强大。
- 开篇：我们用“寄快递”的生动比喻，引出了Kafka生产者在不同阶段需要掌握的核心技能。
- 第一章：ACK机制：我们探讨了如何通过
acks参数（0, 1, -1）在性能和数据可靠性之间做权衡，确保消息“一定”能发出去。 - 第二章：幂等性Producer：我们学习了如何通过开启
enable.idempotence来解决网络重试可能导致的消息重复问题，实现分区内的“精确一次”投递。 - 第三章：指定Partition Key：我们掌握了利用消息Key来控制消息路由，从而保证相关消息（如同一订单的状态）能够被顺序消费的核心技巧。
- 第四章：自定义分区策略：我们更进一步，学习了如何通过实现
Partitioner接口来定制自己的消息分发逻辑，满足特殊的业务需求。
掌握这些技能，能让我们在面对复杂的业务场景时，更加游刃有余地使用Kafka。希望能帮助大家少走弯路，共同打造更高效、更可靠的技术解决方案。让我们共同进步，不断探索新技术。欢迎随时交流，一起分享经验！
扫一扫
536
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
