Kafka核心技术与实战
胡夕
人人贷计算平台部总监，Apache Kafka Contributor
立即订阅
8408 人已学习
课程目录
已完结 46 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么要学习Kafka？
免费
Kafka入门 (5讲)
01 | 消息引擎系统ABC
02 | 一篇文章带你快速搞定Kafka术语
03 | Kafka只是消息引擎系统吗？
04 | 我应该选择哪种Kafka？
05 | 聊聊Kafka的版本号
Kafka的基本使用 (3讲)
06 | Kafka线上集群部署方案怎么做？
07 | 最最最重要的集群参数配置（上）
08 | 最最最重要的集群参数配置（下）
客户端实践及原理剖析 (14讲)
09 | 生产者消息分区机制原理剖析
10 | 生产者压缩算法面面观
11 | 无消息丢失配置怎么实现？
12 | 客户端都有哪些不常见但是很高级的功能？
13 | Java生产者是如何管理TCP连接的？
14 | 幂等生产者和事务生产者是一回事吗？
15 | 消费者组到底是什么？
16 | 揭开神秘的“位移主题”面纱
17 | 消费者组重平衡能避免吗？
18 | Kafka中位移提交那些事儿
19 | CommitFailedException异常怎么处理？
20 | 多线程开发消费者实例
21 | Java 消费者是如何管理TCP连接的?
22 | 消费者组消费进度监控都怎么实现？
深入Kafka内核 (5讲)
23 | Kafka副本机制详解
24 | 请求是怎么被处理的？
25 | 消费者组重平衡全流程解析
26 | 你一定不能错过的Kafka控制器
27 | 关于高水位和Leader Epoch的讨论
管理与监控 (12讲)
28 | 主题管理知多少?
29 | Kafka动态配置了解下？
30 | 怎么重设消费者组位移？
31 | 常见工具脚本大汇总
32 | KafkaAdminClient：Kafka的运维利器
33 | Kafka认证机制用哪家？
34 | 云环境下的授权该怎么做？
35 | 跨集群备份解决方案MirrorMaker
36 | 你应该怎么监控Kafka？
37 | 主流的Kafka监控框架
38 | 调优Kafka，你做到了吗？
39 | 从0搭建基于Kafka的企业级实时日志流处理平台
高级Kafka应用之流处理 (3讲)
40 | Kafka Streams与其他流处理平台的差异在哪里？
41 | Kafka Streams DSL开发实例
42 | Kafka Streams在金融领域的应用
结束语 (1讲)
结束语 | 以梦为马，莫负韶华！
特别放送 (2讲)
加餐 | 搭建开发环境、阅读源码方法、经典学习资料大揭秘
用户故事 | 黄云：行百里者半九十
Kafka核心技术与实战
登录|注册
14 | 幂等生产者和事务生产者是一回事吗？
胡夕 2019-07-04
你好，我是胡夕。今天我要和你分享的主题是：Kafka 消息交付可靠性保障以及精确处理一次语义的实现。
所谓的消息交付可靠性保障，是指 Kafka 对 Producer 和 Consumer 要处理的消息提供什么样的承诺。常见的承诺有以下三种：
最多一次（at most once）：消息可能会丢失，但绝不会被重复发送。
至少一次（at least once）：消息不会丢失，但有可能被重复发送。
精确一次（exactly once）：消息不会丢失，也不会被重复发送。
目前，Kafka 默认提供的交付可靠性保障是第二种，即至少一次。在专栏第 11 期中，我们说过消息“已提交”的含义，即只有 Broker 成功“提交”消息且 Producer 接到 Broker 的应答才会认为该消息成功发送。不过倘若消息成功“提交”，但 Broker 的应答没有成功发送回 Producer 端（比如网络出现瞬时抖动），那么 Producer 就无法确定消息是否真的提交成功了。因此，它只能选择重试，也就是再次发送相同的消息。这就是 Kafka 默认提供至少一次可靠性保障的原因，不过这会导致消息重复发送。
Kafka 也可以提供最多一次交付保障，只需要让 Producer 禁止重试即可。这样一来，消息要么写入成功，要么写入失败，但绝不会重复发送。我们通常不会希望出现消息丢失的情况，但一些场景里偶发的消息丢失其实是被允许的，相反，消息重复是绝对要避免的。此时，使用最多一次交付保障就是最恰当的。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Kafka核心技术与实战》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(56)
dream老师，请问一下，事务型 Producer 可以实现一组消息要么全部写入成功，要么全部失败，但是事务型 Producer 是具体怎么实现多分区以及多会话上的消息无重复的呢？作者回复: 主要的机制是两阶段提交（2PC）。引入了事务协调器的组件帮助完成分布式事务
2019-07-04 14
时隐时现幂等性producer和事务型producer实现原理都没有涉及，这篇有点太肤浅了2019-09-08 12
Jowin研究了一下kafka的设计文档，基本搞清楚了幂等和事务消息，一些理解，https://www.jianshu.com/p/f77ade3f41fd， 欢迎大家一起交流。2019-07-26 1 7
calljson文中提到了幂等性，希望能够讲解下幂等性原理，如何实现，这样大家才能明白为何幂等性无法保证：跨回话、跨分区2019-07-09 6
风中花我一直认为事务，不到必须时是不用得东西，那么我想知道，胡老师实际中，你们有用到过吗，在一些什么场景下使用？老师可以简单说下吗，谢谢作者回复: 我们没有使用。事务更多用在Kafka Streams中。如果要实现流处理中的精确一次语义，事务是不可少的。
2019-07-04 4
知易版本0.11.0.2，设置transactional.id并开启事务后，须同时保证retries>12019-08-02 3
October我所理解的kafka事务是这样的：生产者的事务能够保证一条消息仅仅会保存在kafka的某一个分区上，不会出现在多个分区上，另外，能够保证多条消息原子性的发送到多个分区。也就是说它只保证了从producer端到broker端消息不丢失不重复。但对于consumer端，由于偏移量的提交和消息处理的顺序有前有后，依然可能导致重复消费或者消息丢失消费，如果要实现消费者消费的精确一次，还需要通过额外机制在消费端实现偏移量提交和消息消费的事务处理。不知道自己理解的对不对，希望老师指正。作者回复: 嗯嗯，我觉得很有道理：）
2019-07-04 3
巧克力黑老师，你好
幂等性为什么只保证单分区有效？是因为下一次消息重试指不定发送到哪个分区么。如果这样的话是不是可以采用按消息键保序的方式？这样重试消息还发送到同一个分区。作者回复: 重启之后标识producer的PID就变化了，broker就不认识了。要想认识就要让broker和producer做更多的事，也就是事务机制做的那些事。
重试还是发送到同一个分区2019-07-05 2
nightmare实现上可以用kafka的幂等性来保证单分区单会话的精准一次语义，如果是一批消息，可以路由到同一个分区2019-07-04 2
James对于单会话单分区幂等性～可以使用key分区策略，来实现多分区单会话幂等性。2019-11-14 1
涛老师，kafka中的事务提交异常，broker端的数据还是会写入日志，相当于只是记录一下失败状态，在消费端通过隔离级别，来过滤掉出这部分消息，不进行消费。为什么事务异常了，还要将数据写入日志呢？直接删除掉不好吗？像DB那样。作者回复: Kafka broker基本上还是保持append-only的日志型风格，不做删除处理
2019-10-06 1
B+Tree个人觉得由消费者来根据自身需求来保证幂等性要更好2019-10-06 1- 奇奇事务还有用 冥等生产者没什么用，反正消费端都是有可能重复消费的，业务上必须做去重处理
作者回复: Kafka Streams依靠幂等producer和事务机制来保证EOS
2019-08-28 1 
Lukia老师好，对这段话不太了解“首先，它只能保证单分区上的幂等性，即一个幂等性 Producer 能够保证某个主题的一个分区上不出现重复消息，它无法实现多个分区的幂等性。” 其中，幂灯性producer无法实现对个分区的的幂等性能否举个具体的例子说明？谢谢老师作者回复: 对于实现多个分区的原子性写入，幂等性producer就做不到
2019-07-27 1
莫道不销魂老师我对今天的内容还是有些不理解，希望老师帮我解答下
1、幂等性是通过pid+seq来实现的，我看一些讲解说seq是针对分区级别的，假如目前topic 有两个分区 B和C，这时候我对该topic连续发送两条消息（轮询方式），那么B和C的seq是连续的还是相互独立的，即B-seq=1,C-seq=1 还是B-seq=1,C-seq=2
2、如果消息发送失败，在进行retry的时候 还是会向同一个分区发送吗？还是选择新的分区
3、看老师你发的事务代码，同时发两条消息，如果设置了幂等性理论上这两条消息应该在两个分区都能实现exactly once才对啊 ，都有自动重发的机制了为什么还要开启事务，是因为在会重试超过次数就放弃重试吗作者回复: 如果涉及多个分区的原子写入，幂等producer就无法实现了，只能依靠事务
2019-07-08 1 1
明翼老师请教个问题啊，我们在一个生产环境是日志入kafka，然后读取kafka的数据入到es里面，由于数据比较多，所以入到kafka的数据可能要过半天到一天才可以处理完，结果发现一个很奇怪的现象就是kafka的入的数据越快，那么入es的速度也越快，本来怀疑是kafka数据在cache里面所以快的，但是我们的数据延迟了很久，不太可能在cache，而且通过读kafka的程序日志分析，读kafka环节一直很快，只是入es的时间有快又慢，这个可能是什么问题那？作者回复: 如果consumer能够读取page cache中的数据而不是要去磁盘执行物理读，那么可以用上zero copy，速度应该是很快的。你可以看下你的consumer消费时broker的物理读IO，如果很低，大概率走的是page cache。另外如果读kafka很快，es忽高忽低，那是不是应该查一下ES的写入？
2019-07-05 1 1- October一个幂等性 Producer 能够保证某个主题的一个分区上不出现重复消息，也就是说同一条消息可能出现在不同的分区上，可是producer端没有收到broker的ack，就会重试，重试应该能保证同一条消息分区是不会改变的，为什么这条消息会出现在其他分区呢。
作者回复: “也就是说同一条消息可能出现在不同的分区上” --- 不可能。。。。。。
2019-07-04 2 1 
Rosy老师，当大数据量写入kafka时，broker会报以下异常：org.apache.kafka.commons.errors.OutOfOrderSequenceException，这个问题应该如何排查呢？是Producer端的幂等性问题吗？作者回复: 看上去是个已知的Kafka bug，升级到新版本试试吧
2019-12-03
陈华应老师，事务型producer不会重复发送消息吗？如果发送的这一批到broker了，但是broker返回的确认消息producer没有收到，再次尝试，broker会去重吗？或者consumer端会去重啊？作者回复: producer端可能发送重复消息，broker端有一套机制来去重（幂等性依赖seq number机制，事务依赖各种marker来标记）
2019-11-09
朱东旭您好，胡老师，听说启用幂等还可以防止同分区消息乱序，请问是真的吗。。作者回复: 不启用幂等也可以保证同分区下无消息乱序的。
2019-11-02 1
收起评论