隨筆 20241023 Kafka 的幂等性与分区顺序性探讨

Kafka 的幂等性与分区顺序性探讨

        在分布式系统中，数据的重复、乱序和丢失一直是难以避免的问题。为了解决这些问题，Kafka 引入了幂等性（Idempotence）机制，使得消息在一定条件下可以保证有序且不重复。接下来，我们详细探讨 Kafka 的幂等性如何工作，以及其在单分区和多分区中的表现，重点讨论多分区下顺序性难以保证的原因。

1. Kafka 的幂等性是什么？

        幂等性是指在相同的输入下，重复执行某个操作的结果是相同的，即多次执行的结果与一次执行的结果完全一致。在 Kafka 中，幂等性主要用于避免消息重复发送和乱序问题。

        Kafka 通过为每一个生产者分配一个唯一的 PID（Producer ID），并对每条消息在每个分区中的顺序号 sequence number 进行跟踪来实现幂等性。即便在网络波动或重试的情况下，Kafka 能够确保消息不会被重复写入某个分区。

如何理解幂等性？

        你可以把幂等性想象成排队购票的过程。无论你重复排队多少次，系统都会记录你已经完成了这次购票操作，不会让你重复购票。这就是 Kafka 幂等性生产者的核心：无论生产者发送了几次相同的数据，Kafka 都只处理一次。

2. Kafka 幂等性在单分区中的实现

        Kafka 的幂等性在单分区内能够保证消息的顺序性和不重复性。

单分区有序性

        单分区中的消息是严格按照顺序发送和处理的。Kafka 通过维护每条消息的 sequence number，确保消息被按照生产者的发送顺序存储，并且能够通过这个编号防止消息被重复处理。

类比：

        你可以把单分区中的消息看作是一个人在排队登机。每个人都有明确的排队顺序，机场根据这个顺序安排登机，确保顺序性。如果有人试图重复登机（消息重复发送），系统会通过检查序号来阻止这种情况，需要順序正確才能正常售票        。

3. 多分区中的幂等性问题

        尽管 Kafka 能在单分区内完美地实现幂等性，但在多分区环境下，幂等性只能保证单个分区内的消息顺序和不重复，无法保证跨分区的消息顺序和幂等性。

多分区顺序问题

        当生产者将消息发送到多个分区时，不同分区可能分布在不同的 broker 上，而每个 broker 的处理速度、网络延迟等都会不同。由于这些物理和网络上的差异，消息在不同分区之间的顺序会被打乱，导致整体顺序性无法维持。

原因总结

1. 分区间的隔离性：每个分区是独立的，消息只在各自的分区内保持顺序，不同分区之间没有顺序关系。一旦数据被拆分到不同的分区，这种整体顺序就被打破了。

2. 不同的 broker 和物理隔离：分区可能被分配到不同的 broker（物理节点）上，而每个 broker 的处理速度、网络延迟等可能不同，这进一步导致了顺序上的不一致。

3. 并行性提升吞吐量，但牺牲顺序性：Kafka 的设计初衷是为了提升并发性和吞吐量。通过分区机制将数据分布到多个 broker 上并行处理，虽然提高了处理速度，但破坏了全局顺序性。也就是说，Kafka 优先考虑的是性能而非全局顺序。

类比：

        你可以把多分区的 Kafka 消息传输看作你和朋友分别在不同的城市乘坐航班，虽然每个机场内部有明确的登机顺序（单个分区有序），但由于你们分别去不同的机场（分区分布在不同的 broker 上），最终到达目的地的顺序可能会因为航班延误或机场处理效率的不同而被打乱。Kafka 多分区的情况类似，消息在分区之间的顺序可能会被打乱，无法保证跨分区的顺序性。

4. 粘性分区策略与负载均衡

        Kafka 通过粘性分区策略（Sticky Partitioning Strategy） 来尽量减少分区切换，以增强局部顺序性。该策略会将尽可能多的消息发送到上一次使用的分区中，直到该分区的缓冲区快要满时，才切换到下一个分区。这种做法减少了分区切换的频率，提升了单分区内消息的顺序性。

        然而，粘性分区策略可能导致部分分区的负载较高，而其他分区的负载较轻。这在一定程度上牺牲了负载均衡，尽管局部顺序性有所提升，但并不能解决全局顺序性的问题。

类比：

        粘性分区策略可以类比为机场登机。假设每架飞机有固定的座位数量，当一架飞机快满员时才会开始登下一架飞机。乘客（消息）会尽可能地被安排在同一架飞机上（同一分区），直到座位满员（缓冲区满），才开始安排登下一架飞机（切换分区）。这种方法提高了登机的顺序性，但如果机场只关注某架飞机的座位（分区负载），整体的效率（负载均衡）可能会有所下降。

5. ACK 机制与消息的可靠性

        Kafka 的 ACK 机制（Acknowledgment 确认机制）与消息的可靠性息息相关。生产者在发送数据时，可以通过设置不同的 ACK 级别来控制消息的可靠性：

• ACK = 0: 不等待任何确认，性能最高，但可靠性最低。
• ACK = 1: 只等待 Leader 分区确认消息接收，副本不强制同步，可靠性中等。
• ACK = -1 (All): 等待 Leader 和所有同步副本都确认消息接收后，才算消息发送成功，保证最高可靠性。

        在 ACK = -1 设置下，Kafka 使用 ISR（In-Sync Replica）机制，即只要消息被 Leader 和所有同步副本接收，Kafka 就认为消息发送成功，不必等待所有副本的同步。

类比：

你可以将 Kafka 的 ACK 机制理解为快递签收：

• ACK = 0: 快递员丢下包裹到 發貨地的快遞站 （實際還沒有發送）就走，不管你有没有收到。
• ACK = 1: 快递员需要得到你的签名（Leader 确认）（送到你的手上了，簽收了），但不关心其他副本是否收到。
  • ACK = -1: 快递员不仅需要你的签名，还要确认所有参与的快递员（所有同步副本）都收到确认后，才算完成，或者説，快遞已經被你簽收，你把商品複製了N份，分發給了你的N個兒子，所有兒子也簽收了，才算完結。

6. 总结

        Kafka 的幂等性设计在单分区内完美地实现了消息顺序性和不重复，但在多分区环境下，受制于分区间的物理隔离、broker 的不同处理速度等因素，Kafka 无法保证跨分区的全局顺序性。虽然通过粘性分区策略可以尽量减少分区切换以提升局部顺序性，但全局顺序性依然无法保证。

        Kafka 的设计初衷是为了解决高并发和高吞吐量的问题，它优先考虑的是系统性能而非全局顺序。在选择 Kafka 的消息可靠性时，用户可以通过调整 ACK 级别来平衡消息可靠性和系统性能。