四、如何保证消息不丢失（可靠传递）

Kafka / RocketMQ 如何保证消息不丢失（可靠传递）

1. 在生产端，Kafka 通过请求确认机制，来保证消息的可靠传输。也就是生产端（producer）将消息发到 broker 后，broker 会返回一个确认响应，表明收到了消息，它的实现方式是 producer 使用带有回调通知的 API，比如使用 producer.send(msg，callback)。还要设置 producer 中的 acks (阿可死)参数 = all，表示所有 broker 副本都要接收到消息，才算消息发送成功。此外还要设置 producer 中的 retries 参数为 MAX，表示如果消息发送失败就一直进行重试。

2. 在消费端，也是通过请求确认机制，来保证消息的可靠传输。也就是消费端收到消息，并且执行完所有消费业务逻辑后，再返回确认响应。（Kafka 通过 offset 在分区中记录消费者当前消费的位置，如果先更新 offset 再消费，可能出现消息丢失，比如当前 offset 指向 5，如果先将 offset 更新到 10，然后开始消费，结果消费到 7 的时候临时有事中止了一会，那再次消费时就会从 10 开始消费，这样就丢失了 8 到 10 之间的消息。为了对抗这种消息丢失，可以通过先消费 再更新 offset 的方式来解决）（这种方法容易造成消息重复）

3. 在存储端，如果 Kafka 服务端（broker）出现故障，比如服务器宕机，就可能丢失消息，解决办法是：对于单个节点的 broker，在收到消息后，将消息先写入到磁盘，然后再给 producer 返回确认响应，也就是将 broker 端的刷盘方式配置为同步刷盘；对于多个节点组成的集群，可以将它配置为至少将消息发送到2个以上的节点，再给 producer 返回确认响应，这样即使某个节点宕机，其他节点也可以顶替，也就是在服务端设置副本的数量 >=3（replication.factor >=3），表示至少一个 leader 副本，两个 follower 副本，虽然造成了数据冗余，但提高了数据的安全性。还要在服务端设置 最少的同步副本数量 >=2（min.insync.replicas >=2），表示消息至少要被写入到两个副本才算成功发送，这样才能确保 leader 副本挂了，还有 follower 副本。同时需要设置 副本数量 = 最少同步副本数量 + 1（replication.factor = min.insync.replicas + 1）。这样设置是为了保证系统的可用性，因为如果两者相等，那么只要有一个副本挂了，整个分区就无法工作了。