kafka：如何保证消息不丢失不重复

消息丢失是什么造成的？（从生产端和消费端两个角度来考虑）

消息重复是什么造成的？（从生产端和消费端两个角度来考虑）

如何保证消息有序？

如果保证消息不重不漏，损失的是什么？

消费端重复消费：很容易解决，建立去重表。

消费端丢失数据：也容易解决，关闭自动提交offset，处理完之后受到移位。

生产端重复发送：这个不重要，消费端消费之前从去重表中判重就可以。

生产端丢失数据：这个是最麻烦的情况。

kafka动态维护了一个同步状态的副本的集合（a set of In-Sync Replicas），简称ISR。

在这个集合中的节点都是和leader保持高度一致的，任何一条消息只有被这个集合中的每个节点读取并追加到日志中，才会向外部通知说“这个消息已经被提交”。

只有当消息被所有的副本加入到日志中时，才算是“committed”，只有committed的消息才会发送给consumer，这样就不用担心一旦leader down掉了消息会丢失。

消息从leader复制到follower, 我们可以通过决定producer是否等待消息被提交的通知(ack)来区分同步复制和异步复制。

同步发送：

发出消息后，必须阻塞等待收到通知后，才发送下一条消息。

特点：同步发送模式虽然吞吐量小，但是发一条收到确认后再发下一条，既能保证不丢失消息，又能保证顺序。

异步发送：

一直往缓冲区写，然后一把写到队列中去。

特点：异步的可能会丢失数据。

如何保证有序：

如果有一个发送失败了，后面的就不能继续发了，不然重发的那个肯定乱序了。

生产者在收到发送成功的反馈之前，不能发下一条数据，但我感觉生产者是一个流，阻塞生产者感觉业务上不可行，怎么会因为一条消息发出去没收到反馈，就阻塞生产者。

解决策略：

1.异步方式缓冲区满了，就阻塞在那，等着缓冲区可用，不能清空缓冲区。

2.发送消息之后回调函数，发送成功就发送下一条，发送失败就记在日志中，等着定时脚本来扫描。

注意：发送失败可能并不真的发送失败，只是没收到反馈，定时脚本可能会重发。

ack：

ack确认机制设置为0，表示不等待响应，不等待borker的确认信息，最小延迟，producer无法知道消息是否发生成功，消息可能丢失，但具有最大吞吐量。

ack确认机制设置为-1，也就是让消息写入leader和所有的副本，ISR列表中的所有replica都返回确认消息。

ack确认机制设置为1，leader已经接收了数据的确认信息，replica异步拉取消息，比较折中。

ack确认机制设置为2，表示producer写partition leader和其他一个follower成功的时候，broker就返回成功，无论其他的partition follower是否写成功。

ack确认机制设置为 "all" 即所有副本都同步到数据时send方法才返回, 以此来完全判断数据是否发送成功, 理论上来讲数据不会丢失。

min.insync.replicas=1  意思是至少有1个replica返回成功，否则product异常

block.on.buffer.full = true
acks = all
retries = MAX_VALUE
max.in.flight.requests.per.connection = 1
使用KafkaProducer.send(record, callback)
callback逻辑中显式关闭producer：close(0) 
unclean.leader.election.enable=false
replication.factor = 3 
min.insync.replicas = 2
replication.factor > min.insync.replicas
enable.auto.commit=false

消息处理完成之后再提交位移

产生数据丢失的两种情况：

1）同步模式：有3种状态保证消息被安全生产，但是在配置为1（只保证写入leader成功）的话，如果刚好leader partition挂了，数据就会丢失。
2）异步模式：当缓冲区满了，如果配置为0（还没有收到确认的情况下，缓冲池一满，就清空缓冲池里的消息），数据就会被立即丢弃掉。

在数据生产时避免数据丢失的方法：

1）同步模式：确认机制设置为-1，也就是让消息写入leader和所有的副本。
2）异步模式：如果消息发出去了，但还没有收到确认的时候，缓冲池满了，在配置文件中设置成不限制阻塞超时的时间，也就说让生产端一直阻塞，这样也能保证数据不会丢失。
在数据消费时，避免数据丢失的方法：如果使用了storm，要开启storm的ackfail机制。

如果没有使用storm，确认数据被完成处理之后，再更新offset值。低级API中需要手动控制offset值。

消息队列的问题都要从源头找问题，就是生产者是否有问题。

讨论一种情况：

如果数据发送成功，但是接受response的时候丢失了，机器重启之后就会重发。

重发 解决：

消费端增加去重表就能解决，但是如果生产者丢失了数据，问题就很麻烦了。

重复消费 解决：
（1）去重：将消息的唯一标识保存到外部介质中，每次消费处理时判断是否处理过。
（2）不管：大数据场景中，报表系统或者日志信息丢失几条都无所谓，不会影响最终的统计分析结果。

问题1：丢失消息

目前比较新版本的Kafka正式替换了Scala版本的old producer，使用了由Java重写的producer。新版本的producer采用异步发送机制。

      KafkaProducer.send(ProducerRecord)方法仅仅是把这条消息放入一个缓存中(即RecordAccumulator，本质上使用了队列来缓存记录)，同时后台的IO线程会不断扫描该缓存区，将满足条件的消息封装到某个batch中然后发送出去。显然，这个过程中就有一个数据丢失的窗口：若IO线程发送之前client端挂掉了，累积在accumulator中的数据的确有可能会丢失。
 

问题2：消息乱序

假设客户端代码依次执行下面的语句将两条消息发到相同的分区
producer.send(record1);
producer.send(record2);

如果此时由于某些原因(比如瞬时的网络抖动)导致record1没有成功发送。

同时Kafka又配置了重试机制和max.in.flight.requests.per.connection大于1(默认值是5，本来就是大于1的)。

那么重试record1成功后，record1在分区中就在record2之后，从而造成消息的乱序。

很多某些要求强顺序保证的场景是不允许出现这种情况的。

发送之后重发就会丢失顺序。

解决：

鉴于producer的这两个问题，我们应该如何规避呢？？

对于消息丢失的问题，很容易想到的一个方案就是：

既然异步发送有可能丢失数据， 我改成同步发送总可以。比如这样：producer.send(record).get();
这样当然是可以的，但是性能会很差，不建议这样使用。

因此特意总结了一份配置列表：

个人认为该配置清单应该能够比较好地规避producer端数据丢失情况的发生。

特此说明一下：软件配置的很多决策都是trade-off（平衡，权衡，按实际情况权衡一下，得到最终决策）。

下面的配置也不例外：
应用了这些配置，你可能会发现你的producer/consumer 吞吐量会下降，这是正常的，因为你换取了更高的数据安全性。
 

consumer端丢失消息的情形比较简单：

如果在消息处理完成前就提交了offset，那么就有可能造成数据的丢失。

由于Kafka consumer默认是自动提交位移的，所以在后台提交位移前一定要保证消息被正常处理了，因此不建议采用很重的处理逻辑，如果处理耗时很长，则建议把逻辑放到另一个线程中去做。

为了避免数据丢失，现给出两点建议：
enable.auto.commit=false

关闭自动提交位移，在消息被完整处理之后再手动提交位移。

消息的完整性和系统的吞吐量是互斥的，为了确保消息不丢失就必然会损失系统的吞吐量

producer：

1、ack设置-1

2、设置副本同步成功的最小同步个数为副本数-1

3、加大重试次数

4、同步发送

5、对于单条数据过大，要设置可接收的单条数据的大小

6、对于异步发送，通过回调函数来感知丢消息

7、配置不允许非ISR集合中的副本当leader

8、客户端缓冲区满了也可能会丢消息；或者异步情况下消息在客户端缓冲区还未发送，客户端就宕机

9、block.on.buffer.full = true

consumer：

1、enable.auto.commit=false  关闭自动提交位移

同一分区消息乱序：

假设a,b两条消息，a先发送后由于发送失败重试，这时顺序就会在b的消息后面，可以设置max.in.flight.requests.per.connection=1来避免

max.in.flight.requests.per.connection：限制客户端在单个连接上能够发送的未响应请求的个数。设置此值是1表示kafka broker在响应请求之前client不能再向同一个broker发送请求，但吞吐量会下降

原文参考：https://blog.csdn.net/qq_27388039/article/details/79660377

生产者如何保证数据的不丢失

kafka的ack机制：

在kafka发送数据的时候，每次发送消息都会有一个确认反馈机制，确保消息正常的能够被收到。

同步模式：

ack机制能够保证数据的不丢失，如果ack设置为0，风险很大，一般不建议设置为0

producer.type=sync

request.required.acks=1  //只leader

# 当所有的follower都同步消息成功后发送ack

request.required.acks=-1

异步模式：

通过buffer来进行控制数据的发送，有两个值来进行控制，时间阈值与消息的数量阈值，如果buffer满了数据还没有发送出去，如果设置的是立即清理模式，风险很大，一定要设置为阻塞模式。

结论：

生产者如何保证数据的不丢失：

producer有丢数据的可能，但是可以通过配置保证消息的不丢失。

producer.type=async  异步模式

request.required.acks=1  需要ack校验机制

queue.buffering.max.ms=5000  队列最大缓存时间大一些5秒

queue.buffering.max.messages=10000  队列最大缓存消息数量大些10000

queue.enqueue.timeout.ms = -1  进入队列超时时间设置为永不超时

batch.num.messages=200 每一批处理消息的数量设置小些200

消费者如何保证数据的不丢失

设置不自动提交，通过offset  commit  来保证数据的不丢失，kafka自己记录了每次消费的offset数值，下次继续消费的时候，接着上次的offset进行消费即可。

集群监控工具

ganglia

原文参考：https://blog.csdn.net/wangxingsen9/article/details/80045499