Kafka中的Message Delivary机制

学习Kafka的读书笔记，暂未把文章设为翻译类型，因为并非直译文档。水平有限，还请路过高手指正。

<1> “最多(发送)一次”（At most once）：消息可以丢失但绝不会重新发送；
<2> “至少(发送)一次”（At least once)：消息绝不会丢失但是可能会被重新发送；
<3> “仅（发送）一次”（Exactly once)： 这是实际应用中最希望看到的，每个消息只会被发送一次且不会丢失；

从生产者角度，一个producer可以选择是否异步发送：
1> 若不选择异步发送，Producer在发送一个消息之后得不到及时ack的话，会继续重发，知道得到ack为止；（至少（发送）一次）
2> 若选择异步发送，Producer在发送一个message后就继续接下来的消息发送，而不管消息是否最终发送成功；（最多（发送）一次）

从消费者角度，一个Kafka Consumer有三种选择:
1> 读取N条消息（一批消息） ---> 保存最后一个消息之后要处理的Message Possition至log ---> 处理消息。 该流程保证“最多（发送）一次”：如果保存消息Position成功，但在处理消息完成前Consumer crash, 新的Consumer进程将从记录的position继续往下处理，因而有消息会被漏掉（未经处理).
2> 读取N条消息 （一批消息）---> 处理消息 ---> 记录最后一个消息之后要处理的Message Possition至log。 该流程保证“至少（发送）一次”：如果处理消息过程中consumer crash, 新的consumer进程在接管时会从上一次处理的末尾Position开始，一些消息可能会被重发发送。
3> 处理消息过程中，将每个消息的Position和消息本身存放在同一地方，要么Position和Message都update, 要么都没有。该流程可保证“仅（发送）一次”。当某个消息处理失败（Consumer挂掉），新的Consumer进程可以通过最后一个处理的Message position保证不会重复处理消息。

总的来说，Kafka默认支持“至少（发送）一次”；

如果用户希望支持“最多（发送）一次”，可以在producer端选择异步发送（关闭retry功能)，并且在处理一个批次消息前先记录该批次消息最后一个消息的Position。

若要实现“仅（发送）一次”，Kafka提供了Message Offset, Consumer可以同步保存每个消息的Offset和Message本身，所以实现“仅（发送）一次”比较方便。

Push vs Pull:

Push model不能适应不同消费者的消费能力和使用场景。理解起来很简单，消费者A每分钟只能处理10条消息，但Broker可能以每分钟100条的速率发送给A，这显然不合理。
Pull-based model可以由消费者根据自身的处理能力选择性的批处理消息，可以减少不必要的延迟产生(每次通过网络发送一个消息，会有会话延迟)