【1】消息发送的可靠性保证

对于生产者发送的数据，我们有的时候是不关心数据是否已经发送成功的，我们只要发送就可以了。在这种场景中，消息可能会因为某些故障或问题导致丢失，我们将这种情况称之为消息不可靠。虽然消息数据可能会丢失，但是在某些需要高吞吐，低可靠的系统场景中，这种方式也是可以接受的，甚至是必须的。

但是在更多的场景中，我们是需要确定数据是否已经发送成功了且Kafka正确接收到数据的，也就是要保证数据不丢失，这就是所谓的消息可靠性保证。

而这个确定的过程一般是通过Kafka给我们返回的响应确认结果（Acknowledgement）来决定的，这里的响应确认结果我们也可以简称为ACK应答。根据场景，Kafka提供了3种应答处理，可以通过配置对象进行配置。

在 Apache Kafka 中，ACK（Acknowledgment）指的是生产者在发送消息后，从 Kafka Broker 接收到的确认信号。这种确认机制是用来保证消息发送的可靠性的。Kafka 支持不同的 ACK 策略，这些策略允许生产者根据自己的需求来配置不同的确认级别。以下是 Kafka 中关于 ACK 的几个选项：

  1. No Acknowledgment (acks = 0)：
  • 在这种模式下，生产者在发送消息后不会等待任何确认就认为消息已经被成功发送。这意味着如果 Broker 在写入消息之前崩溃，消息可能会丢失。这种方式提供了最高的吞吐量，但是没有可靠性保障。
  1. Leader Acknowledgment (acks = 1)：
  • 在这种模式下，生产者在发送消息后会等待 Leader 副本确认消息已被写入。如果在确认之后 Leader 崩溃，那么消息仍然可能会丢失，因为还没有同步到 Follower 副本。这种方式提供了较好的吞吐量，但仍然存在一定的数据丢失风险。
  1. All In-Sync Replicas Acknowledgment (acks = all 或 acks = -1)：
  • 这是最严格的确认策略，生产者在发送消息后会等待所有 ISR（In-Sync Replicas）的确认。这意味着消息不仅写入了 Leader，还同步到了所有的 Follower 副本。这种方式虽然降低了吞吐量，但是提供了最强的数据持久性和可靠性保障。

选择哪种 ACK 策略取决于应用的具体需求。如果对数据丢失有严格的要求，那么通常会选择 acks=all，以确保消息的持久性和可靠性；如果对性能要求较高，并且可以接受一定程度的数据丢失风险，那么可以选择较低级别的确认策略。

需要注意的是，使用 acks=all 时，如果 ISR 中的任何一个副本无法同步消息，那么生产者将无法发送新的消息，直到问题解决。因此，在配置 ACK 时，也需要考虑集群的健康状况和副本的数量。

假设我们的分区有5个follower副本，编号为1，2，3，4，5：

Kafka【八】如何保证消息发送的可靠性、重复性、有序性_分布式

但是此时只有3个副本处于和Leader副本之间处于数据同步状态，那么此时分区就存在一个同步副本列表，我们称之为In Syn Replica，简称为ISR。此时，Kafka只要保证ISR中所有的4个副本接收到了数据，就可以对数据请求进行响应了。无需5个副本全部收到数据。

【2】消息发送的重复性

kafka为了提高数据可靠性提供了重试机制用来解决消息丢失问题。如果禁用重试机制，那么一旦数据发送失败，数据就丢失了。而数据重复，恰恰是因为开启重试机制后，如果因为网络阻塞或不稳定，导致数据重新发送。那么数据就有可能是重复的。

kafka提供了幂等性操作解决数据重复，并且幂等性操作要求必须开启重试功能和ACK取值为-1。

在 Apache Kafka 中，解决消息重复发送的问题通常涉及以下几个方面：

1. 幂等性生产者

Kafka 0.10.1 版本引入了幂等性生产者（Idempotent Producers）。启用幂等性后，生产者可以保证消息不会被重复发送。幂等性生产者依赖于事务日志来跟踪已发送的消息，并确保即使生产者崩溃，消息也只会被发送一次。

  • 实现原理：
  • 生产者为每条消息附加一个序列号。
  • Broker 使用序列号来检查消息是否已经被发送过。
  • 如果 Broker 发现序列号冲突，则拒绝该消息。
Map<String, Object> configMap = new HashMap<>();
configMap.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
// TODO 对生产的数据K, V进行序列化的操作
configMap.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
configMap.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
configMap.put(ProducerConfig.ACKS_CONFIG, "-1");//ACK应答
configMap.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true);//开启幂等性
configMap.put(ProducerConfig.RETRIES_CONFIG, 5);
configMap.put(ProducerConfig.BATCH_SIZE_CONFIG, 5);
configMap.put(ProducerConfig.REQUEST_TIMEOUT_MS_CONFIG, 3000);

KafkaProducer<String, String> producer = new KafkaProducer<String, String>(configMap);

kafka提供的幂等性操作只能保证同一个生产者会话中同一个分区中的数据不会重复，一旦数据发送过程中，生产者对象重启，那么幂等性操作就会失效。那么此时就需要使用Kafka的事务功能来解决跨会话的幂等性操作。但是跨分区的幂等性操作是无法实现的。

2. 事务支持

Kafka 从 0.11 版本开始支持事务，这使得生产者可以在事务上下文中发送消息。事务可以确保消息要么全部发送成功，要么全部不发送，从而避免部分消息丢失或重复发送的问题。

  • 实现原理：
  • 生产者开启事务，并在一个事务中发送一系列消息。
  • 生产者在消息发送完成后提交事务。
  • 如果生产者崩溃或出现其他异常，则可以回滚事务，取消未完成的消息发送。

事务支持可以用于确保消息的一致性和完整性。

【3】幂等性与事务支持

幂等性生产者（Idempotent Producers）和事务支持（Transactional Support）是两种不同的机制，它们各自解决了不同的问题，但在实际应用中可以结合起来使用。

幂等性生产者（Idempotent Producers）

幂等性生产者的设计目的是为了确保即使生产者崩溃或重试消息发送，消息也只被写入一次，从而避免重复消息。幂等性生产者不需要开启事务，而是通过以下机制来实现这一目标：

  • 消息序列化：生产者为每个分区的消息生成一个唯一的序列号。
  • 校验重复：Broker 会在接收到消息时检查序列号，如果发现序列号已经存在，则会拒绝这条消息。

幂等性生产者适用于那些希望避免重复消息，但又不需要事务一致性的情况。也就是说，它保证了即使生产者崩溃或重试发送，消息依然只被写入一次，但它并不保证消息的全局顺序或跨分区的一致性。

事务支持（Transactional Support）

事务支持则是为了实现更高级别的消息一致性和原子性，确保消息要么全部发送成功，要么全部不发送。事务支持可以用来处理跨多个分区甚至跨不同系统的复杂操作，确保这些操作作为一个整体成功或失败。

  • 事务上下文：生产者在事务上下文中发送消息，确保消息的发送是原子性的。
  • 提交或回滚：生产者可以在消息处理成功后提交事务，或者在处理失败时回滚事务。

事务支持适用于需要确保消息处理的原子性和一致性的场景，特别是在涉及到跨多个分区或多系统协调的情况下。

幂等性与事务的结合

在一些场景中，你可能会结合使用幂等性生产和事务支持，以达到更高的可靠性和一致性。例如：

  • 幂等性生产者 可以用来防止消息的重复发送。
  • 事务支持 可以用来确保跨多个分区或系统的操作的一致性。

在这种情况下，幂等性生产者确保单个消息不会重复写入，而事务支持则确保整个操作的原子性。

总结

  • 幂等性生产者：防止消息重复发送，适用于单个消息级别的去重。
  • 事务支持：确保操作的原子性和一致性，适用于需要跨分区或系统的一致性操作。

因此，幂等性生产者并不是必须与事务隔离使用才能保证消息的唯一性。相反，幂等性生产者本身就是为了解决消息重复发送问题而设计的。事务支持则是为了实现更高级别的数据一致性和操作的原子性。两者可以独立使用，也可以结合使用以满足不同的需求。

【4】消息发送的有序性保证

在 Apache Kafka 中，保证消息发送的有序性主要依赖于以下几种机制和策略：

1. 单一分区内的消息有序

Kafka 默认保证在一个主题（Topic）的单个分区（Partition）内部的消息是有序的。这是因为消息是按顺序追加到分区的日志文件中的。因此，如果你需要确保消息在主题内的顺序，可以将所有相关消息都发送到同一个分区。

如何实现单一分区内消息有序：

  • 固定分区器：你可以通过设置固定的分区器（Partitioner），使所有具有相同键的消息都被发送到同一个分区。例如，使用相同的键（Key）可以使消息被发送到同一分区，从而在该分区内保持顺序。

2. 使用幂等性生产者

尽管幂等性生产者的主要目的是防止消息重复发送，但如果你使用相同的键发送消息，并且启用了幂等性生产者，那么所有具有相同键的消息将被发送到同一个分区，并且在这个分区内保持顺序。

示例配置

假设你需要确保所有消息在一个主题内是有序的，你可以这样配置生产者：

Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
props.put(ProducerConfig.ACKS_CONFIG, "all");
props.put(ProducerConfig.RETRIES_CONFIG, Integer.MAX_VALUE); // 无限重试
props.put(ProducerConfig.MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION, 1); // 保证消息发送顺序
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true); // 启用幂等性

// 创建生产者
KafkaProducer<String, String> producer = new KafkaProducer<>(props);

这里的关键配置点是 max.in.flight.requests.per.connection 设置为 1，这可以确保在单个连接上一次只发送一条消息，从而在单一分区内保持消息的顺序。

注意事项

  • 单一分区限制：虽然单一分区内部可以保证消息有序，但这意味着所有相关消息都需要发送到同一个分区，这可能会导致性能瓶颈。
  • 并发处理：如果你需要高并发处理，而不仅仅关注消息的顺序，那么可能需要在多个分区之间平衡负载，并且在客户端实现适当的逻辑来处理顺序问题。

通过上述方法，Kafka 可以在不同程度上保证消息的有序性，但通常需要在性能和有序性之间做出权衡。