鹰潭市网站建设公司,网站 微信开发,有没有专门做化妆品小样的网站,网站空间和流量kafka消息交付可靠性保障和精确一次语义处理
消息交付可靠性保障#xff0c;指的kafka对Producer和Consumer要处理的消息提供什么样的承诺。总共就三种#xff1a;at most once 、at least once、axactly once kafka默认提供的是 at least once。原因是只有Broker提交消息并…kafka消息交付可靠性保障和精确一次语义处理
消息交付可靠性保障指的kafka对Producer和Consumer要处理的消息提供什么样的承诺。总共就三种at most once 、at least once、axactly once kafka默认提供的是 at least once。原因是只有Broker提交消息并且Producer收到Broker的应答才会认为该消息已经成功发送如果应答的过程网络抖动了则生产者没有收到应答只能选择重试。 kafka可以提供 exactly once通过幂等生产者或者事务生产者实现。
幂等性
幂等性操作可以安全地重试而不会破坏系统状态。如果是非幂等性操作还要担心多次执行对系统状态的影响。
幂等性Produder
开启props.put(“enable.idempotence”, ture) 原理空间换时间的思路。在Broker端多保留一些字段在Producer发送了具有相同字段的消息后将重复的消息“丢弃”。大致这么理解原理还需要深究。 局限性 1.只能保证单分区的幂等性即只能保证某个主题的某个分区上不出现重复的消息。无法实现多个分区的幂等性。 其实这里指的应该是不能保证消息原子性写入到多个分区一批消息要么全部写入成功要么全部失败看了后面的评论感觉是的。 一个幂等的Producer保证单分区的幂等性Producer消息会发给主题的多个分区每个分区都保证幂等性实际上就是实现了多分区的幂等性。 2.不能实现跨会话的幂等性。会话可以理解为Producer的一次运行。 重启后producer进程的PID就变化了broker就不认识了。想要broker能够认识就需要做更多事情也就是kafka事务做的事情。
事务Producer
数据库安全特性ACIDI指的是隔离性即并发执行的食物彼此隔离互不影响。隔离级别中read commited指的是读取数据库只能读取已提交的消息写数据只能覆盖已提交的消息。
kafka提供事务的支持主要是在read commited隔离级别。事务Producer提供了两个特性 1.保证一批消息原子性写入多个分区要么全部成功要么全部失败。
producer.initTransactions();
try {producer.beginTransaction();producer.send(record1);producer.send(record2);producer.commitTransaction();
} catch (KafkaException e) {producer.abortTransaction();
}record1和record2当作一个事务提交到kafka
2.Producer重启kafka依然能保证它发送消息的精确一次处理。
使用 Producer端
开启 enable.idempotence true设置Producer参数transaction.id在Producer中显式调用事务API Consumer端设置参数isolation.level为read_committed。如果设置为read_uncommitted则Consumer可以读取所有消息包括事务成功和事务中指写入的消息无论事务成功失败都会写入消息kafka事务失败不会回滚写入日志是append-only风格。当然事务Consumer是能看到非事务Producer的所有消息的。
评论区精选
1.对kafka事务的其他描述能够保证一条消息仅仅保存在kafka的某一分区上不会出现在多个分区上。另外能保证多条消息原子性发送到多个分区。也就是只保证Producer到Kafka Broker的消息不重复不丢失。 2.如何保证消费者精确一次消费kafka事务只保证Producer到Kafka Broker的消息不重复不丢失Consumer端由于提交偏移量和消息处理的顺序有前有后依然可能导致重复消费或者消息丢失如果要实现消费者端精确一次消费还需要额外的机制实现偏移量提交和消息消费的事务处理。
重复消费例子Consumer端处理逻辑比较重超时没提交ACK比如顺序是改库-远程调用-提交偏移量远程调用超时了但是处理逻辑已经执行了下次重新消费还会消费到重复的数据所以业务上要做幂等。
消息丢失例子先提交偏移量在处理消息处理消息过程发生异常。
3.事务Producer是怎么实现多分区以及多会话上的消息无重复原理 主要机制是两阶段提交2PC。引入事务协调器帮助完成分布式事务。
4.不启用幂等也能保证同分区下无消息乱序的方法。比如消息发送失败重发会导致在broker的消息顺序和producer发送消息的顺序不一样。max.in.flight.requests.per.connection 1来实现。这样producer会等待之前请求的消息发送成功才会发送下一个对吞吐量的影响
5.producer retry会保证消息发送到同一个分区不然幂等性无法保障。
6.幂等kafka有局限性说明kafka不能完全保证消费者重复消费最好使用业务去重。即使consumer读到了事务消息但还是可能由于rebalance等原因导致重复消费。
7.“那么你可能会问如果我想实现多分区以及多会话上的消息无重复应该怎么做呢答案就是事务transaction或者依赖事务型 Producer。这也是幂等性 Producer 和事务型 Producer 的最大区别”这句话的意思是说事务本身已经保证了事务内所有消息的幂等性了么 答曰事务提供的一致性要高于幂等性
8.我理解幂等是保证消息不重复事务是保证“批量消息”原子性写入不丢失。因为kafka本身已经保证当broker响应peoducer已提交后消息不丢失如果我没有批量写入需求是否就单独通过幂等保证精确一次呢 答曰依然不能保证多个分区同时写入消息的事务性
