第四章 Kafka高级API——Acks&Retries&幂等写

Kafka生产者在发送完一个的消息之后，要求Broker在规定的额时间Ack应答答，如果没有在规定时间内应答， Kafka生产者会尝试n次重新发送消息。
acks=1默认

• acks=1 Leader会将Record写到其本地日志中，但会在不等待所有Follower的完全确认的情况下做出响应。在这种情况下，如果Leader在确认记录后立即失败,但在Follower复制记录之前失败，则记录将丢失。
• acks=0 生产者根本不会等待服务器的任何确认。该记录将立即添加到套接字缓冲区中并视为已发送。在这种情况下，不能保证服务器已收到记录,
• acks=all 这意味着Leader将等待全套同步副本确认记录。这保证了只要至少一个同步副本仍处于活动状态，记录就不会丢失。这是最有力的保证。这等效于acks =-1设置.

如果生产者在规定的时间内,并没有得到Kafka的Leader的Ack应答, Kafka可以开启reties机制request.timeout.ms = 30000默认
retries = 2147483647默认

可能产生数据重复

幂等写

HTTP/1.1中对幂等性的定义是:一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外)。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。
Kafka在0.11.0.0版本支持增加了对幂等的支持。幂等是针对生产者角度的特性。幂等可以保证上生产者发送的消息，不会丢失，而且不会重复。实现幂等的关键点就是服务端可以区分请求是否重复，过滤掉重复的请求。要区分请求是否重复的有两点:
唯一标识:要想区分请求是否重复，请求中就得有唯一标识。例如支付请求中，订单号就是唯一标识
记录下已处理过的请求标识:光有唯一标识还不够，还需要记录下那些请求是已经处理过的，这样当收到新的请求时，用新请求中的标识和处理记录进行比较，如果处理记录中有相同的标识，说明是重复记录，拒绝掉。

不会丢失 retries
不会重复 去重

幂等又称为exactly once。要停止多次处理消息，必须仅将其持久化到Kafka Topic中仅仅一次。在初始化期间,kafka会给生产者生成一个唯一的ID称为Producer ID或PID。PID和序列号与消息捆绑在一起，然后发送给Broker。由于序列号从零开始并且单调递增，因此,仅当消息的序列号比该PID /TopicPartition对中最后提交的消息正好大1时,Broker才会接受该消息。如果不是这种情况，则Broker认定是生产者重新发送该消息。
enable.idempotence= false默认
注意:在使用幂等性的时候,要求必须开启retries=true和acks=all