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

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

1. 在生产阶段，消息队列通过请求确认机制，来保证消息的可靠传输。也就是 producer 将消息发到 broker 后，broker 会返回一个确认响应，表明收到了消息，它的实现方式是 producer 使用带有回调通知的 API，比如使用 producer.send(msg，callback)。还要设置 producer 中的 acks 参数 = all，表示所有副本都要接收到消息，才算消息发送成功。还要设置 producer 中的 retries ，也就是重试次数，尽量设置大一点，如果消息发送失败就重试。
2. 在存储阶段，如果 Kafka 服务端（broker）出现故障，比如服务器宕机，就可能丢失消息，解决办法是：对于单个节点的 broker，在收到消息后，将消息先写入到磁盘，然后再给 producer 返回确认响应，也就是将 broker 端的刷盘方式配置为同步刷盘；对于多个节点组成的集群，可以将它配置为至少将消息发送到2个以上的节点，再给 producer 返回确认响应，这样即使某个节点宕机，其他节点也可以顶替，也就是在服务端设置 replication.factor >=3 ，表示至少一个 leader 副本，两个 follower 副本，虽然造成了数据冗余，但提高了数据的安全性。还要在服务端设置 min.insync.replicas > 1，表示消息至少要被写入到两个副本才算成功发送，这样才能确保 leader 副本挂了，还有 follower 副本。同时需要设置 replication.factor = min.insync.replicas + 1。这样设置是为了保证系统的可用性，因为如果两者相等，那么只要有一个副本挂了，整个分区就无法工作了。
3. 在消费阶段，也是通过请求确认机制，来保证消息的可靠传输。也就是消费端收到消息，并且执行完所有消费业务逻辑后，再返回确认响应。Kafka 通过 offset 在分区中记录消费者当前消费的位置，如果先更新 offset 再消费，可能出现消息丢失，比如当前 offset 指向 5，如果先将 offset 更新到 10，然后开始消费，结果消费到 7 的时候临时有事中止了一会，那再次消费时就会从 10 开始消费，这样就丢失了 8 到 10 之间的消息。为了对抗这种消息丢失，可以通过先消费 再更新 offset 的方式来解决。（这种方法容易造成消息重复）

二. RocketMQ 如果保证消息不丢失？