网站转出,婚庆公司策划书,购物网站欢迎页面怎么设计,c2c电商平台有哪几个文章目录 Kafka的发送模式Kafka的ack机制发送模式与ack的关联重试次数总结 在Kafka中#xff0c;发送模式与ack机制紧密相关#xff0c;它们共同影响着消息发送的可靠性和性能。
Kafka的发送模式 发后即忘#xff08;Fire and Forget#xff09;#xff1a;生产者发送消息… 文章目录 Kafka的发送模式Kafka的ack机制发送模式与ack的关联重试次数总结 在Kafka中发送模式与ack机制紧密相关它们共同影响着消息发送的可靠性和性能。
Kafka的发送模式 发后即忘Fire and Forget生产者发送消息后不等待任何来自服务器的确认继续处理下一条消息实现简单、低延迟但可能会有消息丢失。 同步发送Sync生产者发送消息后会阻塞等待服务器的确认响应确保消息发送成功可靠性高但会降低发送速度影响吞吐量。 异步发送Async生产者发送消息后通过回调函数处理服务器的响应消息发送后可继续执行其他操作能提高吞吐量也可通过回调函数处理发送结果。
Kafka的ack机制 ack0生产者发送消息后无需等待服务器确认服务器可能没收到消息就认为发送完成可能导致消息丢失延迟最低但可靠性差适用于允许少量消息丢失且追求极致性能的场景。 ack1生产者发送消息后只要分区的leader副本成功写入消息就会收到确认若leader副本写入后follower副本同步前leader故障可能丢失消息性能和可靠性较平衡。 ack-1或all生产者发送消息后需等待所有同步中的副本都成功写入消息才会收到确认保证消息不丢失可靠性最高但可能因等待所有副本确认而增加延迟降低吞吐量。
发送模式与ack的关联 发后即忘通常搭配ack0以追求最大的发送性能和最低延迟不在乎消息是否丢失。 同步发送常与ack1或ack-1搭配需确保消息可靠到达服务器若对消息可靠性要求极高选ack-1若能容忍一定程度数据丢失以换取性能选ack1。 异步发送可与各种ack值搭配根据业务场景选择。如对实时性要求高但能接受少量消息丢失可选ack1搭配异步发送通过回调函数处理发送结果若要保证消息可靠性可将ack-1与异步发送结合通过回调函数确保消息处理。
重试次数
retries参数用来配置生产者重试的次数默认值为0即在发生异常的时候不进行任何重试动作。消息在从生产者发出到成功写入服务器之前可能发生一些临时性的异常比如网络抖动、leader副本的选举等这种异常往往是可以自行恢复的生产者可以通过配置retries大于0的值以此通过内部重试来恢复而不是一味地将异常抛给生产者的应用程序。如果重试达到设定的次数那么生产者就会放弃重试并返回异常。不过并不是所有的异常都是可以通过重试来解决的比如消息太大超过max.request.size参数配置的值时这种方式就不可行了。
重试还和另一个参数retry.backoff.ms有关这个参数的默认值为100它用来设定两次重试之间的时间间隔避免无效的频繁重试。在配置retries和retry.backoff.ms之前最好先估算一下可能的异常恢复时间这样可以设定总的重试时间大于这个异常恢复时间以此来避免生产者过早地放弃重试。
Kafka可以保证同一个分区中的消息是有序的。如果生产者按照一定的顺序发送消息那么这些消息也会顺序地写入分区进而消费者也可以按照同样的顺序消费它们。对于某些应用来说顺序性非常重要比如MySQL的binlog传输如果出现错误就会造成非常严重的后果。如果将acks参数配置为非零值并且max.in.flight.requests.per.connection参数配置为大于1的值(这部分在kafka生产端之架构及工作原理中会详细讲解该配置)那么就会出现错序的现象如果第一批次消息写入失败而第二批次消息写入成功那么生产者会重试发送第一批次的消息此时如果第一批次的消息写入成功那么这两个批次的消息就出现了错序。一般而言在需要保证消息顺序的场合建议把参数max.in.flight.requests.per.connection配置为1而不是把acks配置为0不过 这样也会影响整体的吞吐。
总结
通过上面的讲解我们应该可以知道如何尽可能的保障生产者消息不丢失。
