Kafka-Delivery Guarantee

每种消息系统都会提供一些机制来保证消息传输的可靠性，Kafka也是如此。
Kafka提供了一下集中Delivery Guarantee：

1. at most once
2. at least once
3. exactly once

Producer的delivery gurantee

Kafka提供了replication机制，只有一条消息被broker接收到，那么该条消息就一定可用，主要的问题在于，当producer和broker的通信网络发生故障时，需要有一种机制来保证不丢失数据。Kafka的Producer此时会retry失败的数据，这样就可以保证在producer端的exactly once

Consumer的delivery gurantee

首先，来梳理一下Consumer消费数据的主要流程。

Consumer从Broker读取一条数据后，可以执行commit，然后会在zookeeper中保存当前consumer在分区上消费数据的offset，下一次消费数据时，会从上一次commit的offset位置开始读取。如果上一次没有commit，那么就会从上一次消费数据的起始位置开始消费数据，也可以选择默认提交，即consumer读取到一条数据后马上commit。但实际情况并非这么简单，这种复杂性就发生在读取数据和commit之间。

• 读取数据后马上执行commit。
  consumer读取数据后需要对数据进行处理，如果在处理过程中程序出现异常或宕机，当重新读取数据时当前数据就会丢失。
• 待处理完成后在执行commit。
  若在执行commit前出现故障，当再次读取数据时，将会读取上次处理完成但未提交的数据。

上面的问题也是经典的事务性问题。如果想更好的解决这个问题，那么一个有效的办法是在offset上加入读取和提交两个节点的标记，这样就能清晰的标明一条数据的读取状态和提交状态。