从kafka端看:kafka持久化是通过顺序写,直接追加写硬盘日志文件的;
日志有两个配置参数:M,强制操作系统讲文件刷新到磁盘之前写入的消息数;S,强制系统讲文件刷新到磁盘之前的时间(秒).也就是说在系统崩溃的情况下,最多会丢失M条消息和S秒的数据.
从生产端看:
生产者的消息发送方式send(msg),该方法可以将一条消息发送出去,但是对发送出去的消息没有掌控能力,无法得知其最后去向是否到达了kafka,所以这是一种不可靠的发送方式.虽然这个方法会返回futrue作为返回通过get可以获取到结果,但是这是同步的方式,基本上不会用到.
接下来就得看send(msg,callback)该方法可以将一条消息发送出去,并且可以从callback回调中得到该条消息的发送结果,并且callback是异步调用的.在间距性能的情况下,也对消息具有比较好的掌控.
光是通过send(msg,callback)还不能保证消息的可靠,还需要生产者配置ack策略;
kafka的ack配置通过acks指定value实现;
当acks=0时,生产者将完全不会管服务器是否收到消息,该记录添加到套接字缓冲区中并视为已发送.重试配置不会生效
acks=1时,当leader接收到消息就会直接给客户端返回成功,一般情况下这种模式能够很好的保证数据不丢失了,是同时兼顾了性能和可靠性的方式
acks=all或者-1时,当leader接收到消息并且同步到了一定数量的follower,才能向生产者发送成功的消息.同步到follower数量由broker端的min.insync.replicase决定.
broker端的配置:
1.min.insync.replicas 当写入副本数<min.insync.replicas时,生产者会收到一个either NotEnoughReplicas or NotEnoughReplicasAfterAppend的异常,所以这个参数必须小于replication.factor副本数,
2.unclean.leader.election.enable 这个配置主要针对folloer数据落后比较多的情况下不能被选举为leader,否则会丢失最新的一部分数据
