exactly-once和kafka

　　Exactly-Once的概念是指"恰好一次"，简单讲就是同一个数据只会被处理一次，应用有机质保证不会重复处理同一条数据（如果数据因为因为网络业务异常被发送多次）；Exactly-Onece实现了操作的等幂性，如果在kafka处理数据全流程保证历史/重新处理数据结果都是一致的。

　　Kafka处理数据的这种等幂性要从三个点说起：

　　1. 重复发送数据等幂性：kafka客户端每次传输数据都会传送pid以及seqNo，前者说明的producer的标志，后者是当前producer消息的序列，这两个数据可以保证数据的唯一性；当出现重复数据，可以根据这两个字段进行判断；该特性默认关闭，需要设置enable.idempotence=true

　　2. 数据处理数据的等幂性：borker通过"事务"机制实现了分配数据到topic和partition之间的等幂。

　　注意，虽然代码中采用producer，但是这部分流程是在broker中实现的，我们看到kafka中通过设置了事务处理，实现了要么全部写入，要全部不写入；回滚通过读取日志实现（这个和mysql的binlog很类似）。

　　3. 消息的消费，注意消息消费也不是原子操作，而是有一套流程的：1）消息消费；2）消息的处理；3）把消息处理结果发送到某个topic中；4）偏移量发送到指定的topic中。前两部不是很清楚意思，有些混淆，但是后面两步通常会被忽略；保证exactly onece的机制第二部类似，对于这四个步骤，都会放到一个事务中，操作流程将会记录到Transaction Log中。

　　同样的消息处理的exactly因为都是有一定的成本的，默认是关闭，打开：processing.guarantee="exactly-once "

　　消息传输保障除了exactly-once之外，还有两种，分别是：

　　at most once：这个机制是指客户端数据最多传一次即可保证成功，简单讲就是完全没有数据保障，客户端传输一次就完事，网络异常，处理故障丢数据不再关心；

　　at least onece：这个是kafka默认的机制，就是数据可能会被传输多次，相同的数据可能会被处理多次，且处理过程不具有等幂性；即有重复的可能性（默认不会校验pid以及seqNo是否有重复）

 　　其实我们看到，传输保障并不是描述服务器端的机制，而是是客户端和服务器端（生产者-消费者）共通协作实现的。

参考：

https://blog.csdn.net/liangyihuai/article/details/82931140

kafka的exactly once机制描述的很清晰（本博客中图片就是来自于此文）

https://www.cnblogs.com/bonelee/p/6360644.html

https://www.cnblogs.com/foreach-break/p/distributed_system_and_transaction.html#_3

解释传输保障的三个级别，描述的还是比较清晰的