面试题：消息队列 Kafka 在电商系统中如何保障消息的可靠性

Question

在电商系统使用 Kafka 架构时，可能会出现消息丢失或重复消费的问题。请阐述 Kafka 是通过哪些机制来保障消息的可靠性，避免这些问题发生的？

Answer 1

生产者端保障机制

1. ACK 机制：
   • acks = 0：生产者发送消息后，不需要等待任何 broker 的确认，就认为消息已发送成功。这种情况下，消息很容易丢失，因为如果 broker 还未收到消息，生产者就认为发送成功，一旦发生网络问题等情况，消息就会丢失。
   • acks = 1：生产者发送消息后，只要 leader 副本成功接收消息，就会给生产者发送确认。这种情况下，如果 leader 副本接收消息后还未来得及同步给 follower 副本就发生故障，消息可能丢失。
   • acks = all 或 acks = -1：生产者发送消息后，需要等待所有的 in - sync replicas（ISR）中的副本都成功接收消息，才会收到确认。这种方式可以最大程度保证消息不丢失，但可能会影响性能。
2. 重试机制：当生产者发送消息失败时（比如网络抖动等原因导致发送失败），可以通过配置 retries 参数，让生产者自动重试发送消息，直到达到最大重试次数。这可以避免因短暂的网络问题等导致消息丢失。

消费者端保障机制

1. 位移管理：
   • 自动提交位移：消费者可以配置 enable.auto.commit 为 true，并通过 auto.commit.interval.ms 配置自动提交位移的时间间隔。自动提交位移可能会导致重复消费，因为如果在提交位移后，消费者处理消息的过程中发生故障，重新启动后会从已提交的位移处开始消费，而之前已提交位移但还未完全处理完的消息就会被再次消费。
   • 手动提交位移：消费者可以配置 enable.auto.commit 为 false，然后在消息处理完成后手动调用 commitSync() 或 commitAsync() 方法提交位移。这样可以保证消息处理完成后才提交位移，避免重复消费和消息丢失。
2. 幂等性处理：对于一些业务场景，消费者可以在处理消息时实现幂等性。例如，在电商系统中，处理订单消息时，可以根据订单号等唯一标识判断消息是否已经处理过，如果已经处理过则不再重复处理，从而避免重复消费带来的业务异常。

Kafka 服务端保障机制

1. 副本机制：Kafka 采用多副本机制，每个分区都有多个副本，其中一个是 leader 副本，其他是 follower 副本。leader 副本负责处理读写请求，follower 副本从 leader 副本同步数据。当 leader 副本发生故障时，会从 ISR 中的 follower 副本中选举出新的 leader 副本，保证数据的可用性和可靠性，减少消息丢失的可能性。
2. ISR 机制：ISR（In - Sync Replicas）是指与 leader 副本保持一定程度同步的 follower 副本集合。只有在 ISR 中的副本才能被选举为新的 leader。如果 follower 副本长时间未向 leader 副本同步数据，会被移出 ISR。这样可以保证在 leader 故障时，从 ISR 中选举出的新 leader 拥有最新的数据，从而保障消息的可靠性，避免消息丢失。