kafka中消息传输一致中的最多一次、最少一次、恰好一次是什么意思？精确一次（Exactly-once-semantics）是如何实现的？

小提示：后面[ ]的是我为了方便记忆提出来的关键字

1.至少一次语义：【重试，消息可能会重复被消费】

–如果生产者的acks设置为-1(或all)，【设置】
–并且生产者在发送消息后也收到了确认ack(Kafka broker的)，【收到】
–那么这就意味着消息已经被精确一次写入到了Kafka topic。【已经】

–但是，如果生产者接收ack超时或者收到了错误，【但是】
–它就会认为消息没有写入Kafka topic然后会尝试重新发送消息。【重试】

–如果broker恰好在消息已经成功写入Kafka topic后，【恰好…成功】
–只是在发送ack前，出了故障，【只是…故障】
–那么生产者的重试机制就会导致这条消息被写入Kafka两次，【重试.导致】
–这样就会导致同样的消息被消费者消费不止一次。【导致…消费】
–这种方式会导致重复的工作和错误的结果。【重复…错误】

2.至多一次语义：【不重试，消息可能会没有被消费】

–如果生产者在ack超时或者返回错误的时候不重试发送消息，
–那么消息有可能最终并没有写入Kafka topic中，
–这样就可能出现消息并没有被消费者消费到的情况。

3.精确一次语义：【生产者有重试机制，且发送的消息只会被消费一次】

–即使生产者重试发送消息，也只会让消息被发送给消费者一次。

4.如何实现的呢？【也就是Spark Steaming拉取数据时，如何实现恰好一次？】

主要有两种方案：通过【幂等性】和【事务】这两个特性来实现恰好一次

----幂等性------
–1.什么是幂等性呢？ – 就是一种被执行多次造成的影响和只执行一次造成的影响一样
–2.怎么实现幂等性？
–开启幂等机制： 【在producer.properties中设置】 enable.idempotence=true [aɪ’dempətəns]幂等性
– 同时注意：
- 重试次数要大于0：retries>0 【开启重试机制】
【–因为只有大于0时失败了才会有重试】
- 还要使用acks机制:acks=-1 【开启确认机制】
【–因为这样kafka broker才会给生产者发送确认信号acks】
- max.in.flight.requests.per.connection<=5 (默认是5) 【每个连接最大执行中的请求数】
【–不知道】 【这3个都要设置，不然会报ConfigException异常】

–3.幂等性的实现原理： --1.每一个生产者在初始化时会生成一个producer_id,(因为可能会有多个生产者) --并为每个目标分区维护一个"序列号"(SequenceNumber); --2.生产者每发送一条消息就会将<produce_id,分区>对应的"序列号"+1 --3.broker端会为每一对<produce_id,分区>维护一个序列号，对于每收到的一条消息， --会判断服务端的序列号(old)和接收到消息中的序列号(new)进行对比； --即服务器会检查消息中的produce_id和序列号和之前的有没有相同来到达过滤的目的， --4.若：sn_old+1==sn_new broker就正常接收 --因为：比如此时如果old=2，那么下一个就正常应该是3了 --若：sn_old+1>sn_new
broker --比如若old=3，new=3,那么说明重复了，就直接丢弃 --若：sn_old+1<sn_new broker
–比如若old=3，new=5,那么说明中间没有收到4的，说明中间有数据没有被写入，可能是发生了乱序(前发后面的，再发前面的),也可能是producer在发送的过程中丢失了数据，出现这种情况，会抛出OutOfOrderSequenceException异常()

–消息重试的时候也是发往同一个分区，因为它有分区器，底层设置了同一个序列号的发往同一个分区

----事务机制------ Kafka现在支持使用新事务API原子性的对跨partition进行写操作，该API允许producer发送批量消息到多个partition。该功能同样支持在同一个事务中提交消费者offsets，因此真正意义上实现了end-to-end的exactly-once
delivery语义

–注意：

• 1:需要开启幂等性
• 2:要保证副本数>=3
• 3:在写入一条数据过程中，必须要有一半以上副本写入成功才行

–2020.11.28