济南做网站最好的单位,wordpress 邮件设置,网站开发与设计案例,如何微信小程序注册Kafka怎么保证数据不丢失#xff1f;这个问题要从3个方面来保证数据不丢失#xff1a;生产者、服务端、消费者。01producer 生产端是如何保证数据不丢失的1.ack的配置策略acks all (或-1)生产者在发送消息之后#xff0c;需要等待ISR中所有的副本都成功写入消息之后才能够收… Kafka怎么保证数据不丢失这个问题要从3个方面来保证数据不丢失生产者、服务端、消费者。01producer 生产端是如何保证数据不丢失的1.ack的配置策略acks all (或-1)生产者在发送消息之后需要等待ISR中所有的副本都成功写入消息之后才能够收到来自服务端的成功响应在配置环境相同的情况下此种配置可以达到最强的可靠性。即在发送消息时需要leader 向fllow 同步完数据之后也就是ISR队列中所有的broker全部保存完这条消息后才会向ack发送消息表示发送成功。2.retries的配置策略在kafka中错误分为2种一种是可恢复的另一种是不可恢复的。可恢复性的错误如遇到在leader的选举、网络的抖动等这些异常时如果我们在这个时候配置的retries大于0的也就是可以进行重试操作那么等到leader选举完成后、网络稳定后这些异常就会消息错误也就可以恢复数据再次重发时就会正常发送到broker端。需要注意retries(重试)之间的时间间隔以确保在重试时可恢复性错误都已恢复。不可恢复性的错误如超过了发送消息的最大值(max.request.size)时这种错误是不可恢复的如果不做处理那么数据就会丢失因此我们需要注意在发生异常时把这些消息写入到DB、缓存本地文件中等等把这些不成功的数据记录下来等错误修复后再把这些数据发送到broker端。3.如何选取(1)高可用型配置acks allretries 0 retry.backoff.ms100(毫秒) (并根据实际情况设置retry可能恢复的间隔时间)优点这样保证了producer端每发送一条消息都要成功如果不成功并将消息缓存起来等异常恢复后再次发送。缺点这样保证了高可用但是这会导致集群的吞吐量不是很高因为数据发送到broker之后leader要将数据同步到fllower上如果网络带宽、不稳定等情况时ack响应时间会更长(2)折中型配置acks 1 retries 0 retries 时间间隔设置 (并根据实际情况设置retries可能恢复的间隔时间)优点保证了消息的可靠性和吞吐量是个折中的方案缺点性能处于2者中间(3)高吞吐型配置acks 0优点可以相对容忍一些数据的丢失吞吐量大可以接收大量请求缺点不知道发送的消息是 否成功02broker端是如何保证数据不丢失的unclean.leader.election.enablefalse设置为 false(默认参数为 true)意思是当存有你最新一条记录的 replication 宕机的时候Kafka 自己会选举出一个主节点如果默认允许还未同步你最新数据的 replication 所在的节点被选举为主节点的话你的数据将会丢失因此这里应该按需将参数调控为 false03consumer端是如何保证数据不丢失的在consumer消费阶段对offset的处理关系到是否丢失数据是否重复消费数据因此我们把处理好offset就可以做到exactly-once at-least-once(只消费一次)数据。当enable.auto.committrue时表示由kafka的consumer端自动提交offset,当你在pull(拉取)30条数据在处理到第20条时自动提交了offset,但是在处理21条的时候出现了异常当你再次pull数据时由于之前是自动提交的offset所以是从30条之后开始拉取数据这也就意味着21-30条的数据发生了丢失。当enable.auto.commitfalse时由于上面的情况可知自动提交offset时如果处理数据失败就会发生数据丢失的情况。那我们设置成手动提交。当设置成false时由于是手动提交的可以处理一条提交一条也可以处理一批提交一批由于consumer在消费数据时是按一个batch来的当pull了30条数据时如果我们处理一条提交一个offset这样会严重影响消费的能力那就需要我们来按一批来处理或者设置一个累加器处理一条加1如果在处理数据时发生了异常那就把当前处理失败的offset进行提交(放在finally代码块中)注意一定要确保offset的正确性当下次再次消费的时候就可以从提交的offset处进行再次消费。点一下在看再走吧
