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核心技术与实战
登录|注册

11 | 无消息丢失配置怎么实现?

胡夕 2019-06-27
你好,我是胡夕。今天我要和你分享的主题是:如何配置 Kafka 无消息丢失。
一直以来,很多人对于 Kafka 丢失消息这件事情都有着自己的理解,因而也就有着自己的解决之道。在讨论具体的应对方法之前,我觉得我们首先要明确,在 Kafka 的世界里什么才算是消息丢失,或者说 Kafka 在什么情况下能保证消息不丢失。这点非常关键,因为很多时候我们容易混淆责任的边界,如果搞不清楚事情由谁负责,自然也就不知道由谁来出解决方案了。
那 Kafka 到底在什么情况下才能保证消息不丢失呢?
一句话概括,Kafka 只对“已提交”的消息(committed message)做有限度的持久化保证。
这句话里面有两个核心要素,我们一一来看。
第一个核心要素是“已提交的消息”。什么是已提交的消息?当 Kafka 的若干个 Broker 成功地接收到一条消息并写入到日志文件后,它们会告诉生产者程序这条消息已成功提交。此时,这条消息在 Kafka 看来就正式变为“已提交”消息了。
那为什么是若干个 Broker 呢?这取决于你对“已提交”的定义。你可以选择只要有一个 Broker 成功保存该消息就算是已提交,也可以是令所有 Broker 都成功保存该消息才算是已提交。不论哪种情况,Kafka 只对已提交的消息做持久化保证这件事情是不变的。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Kafka核心技术与实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(90)

  • 阳明
    总结里的的第二条ack=all和第六条的说明是不是有冲突

    作者回复: 其实不冲突。如果ISR中只有1个副本了,acks=all也就相当于acks=1了,引入min.insync.replicas的目的就是为了做一个下限的限制:不能只满足于ISR全部写入,还要保证ISR中的写入个数不少于min.insync.replicas。

    2019-06-27
    5
    23
  • lmtoo
    最后一个问题,难道新增分区之后,producer先感知并发送数据,消费者后感知,消费者的offset会定位到新分区的最后一条消息?消费者没有提交offset怎么会从最后一条开始的呢?

    作者回复: 如果你配置了auto.offset.reset=latest就会这样的

    2019-06-27
    6
  • cricket1981
    consumer改用"从最早位置"读解决新加分区造成的问题
    2019-06-27
    6
  • 曹伟雄
    单个 Consumer 程序使用多线程来消费消息说起来容易,写成代码却异常困难,因为你很难正确地处理位移的更新,也就是说避免无消费消息丢失很简单,但极易出现消息被消费了多次的情况。
    关于这个问题,老师能否提供个java代码的最佳实践? 谢谢!

    作者回复: 写过一两篇,https://www.cnblogs.com/huxi2b/p/7089854.html,

    但总觉得不太完美。如果你想深入了解的话,推荐读一下Flink Kafka Connector的源码

    2019-06-30
    5
  • 杰锅不是锅
    老师,我想问个问题,假如一个topic有3个partion ,我有三个消费端去消费topic,这三个消费端,是怎么去对应三个partion?曾经在线上遇到过消费太慢,导致消息重新均衡,重复消费了,有好的解决方法吗?

    作者回复: 通常情况下能够保障每个consumer消费一个分区。如果消费慢,需要看到底是哪里慢?是Kafka给你消息的速度慢还是你自己处理消息的速度慢。可以适当增加max.poll.interval.ms看看

    2019-07-14
    4
  • 💪😊
    新建分区丢失是因为没有offset就从lastest开始读取,可以改成没有offset的时候从ealiest读取应该就可以了
    2019-07-05
    1
    4
  • nightmare
    多线程消费这么确保手动提交offset管理不会丢失呢,期待老师给一个消费端最佳实践
    2019-06-28
    4
  • 巧克力黑
    老师,你好。仔细阅读文稿后,仍有一些困惑
    1、如果只用 send()方法(fire and forget), 即使配置retries,producer也是不知道消息状态,是不会重试的。所以说配置retries,要搭配send(msg, callback),这么理解正确么?
    2、配置了retries, producer是怎么知道哪条消息发送失败了,然后重试

    作者回复: 1. 不是。如果配置了retries,即使调用send(msg)也是会重试的。这是Kafka producer自己实现的机制,不需要用户干预
    2. Broker发送response给producer,里面会保存error信息以及那个(些)batch出错了

    2019-06-28
    3
    3
  • 永光
    看了评论区回答还是不太理解,第二条ack=all与第六条min.insync.replicas 怎样协调工作的,总感觉是有冲突的。
    问题是:
    第二条的“已提交”和第六条的“已提交”是同一个意思吗?如果是同一个意思,那定义为什么不一样呀?

    作者回复: acks=all表示消息要写入所有ISR副本,但没要求ISR副本有多少个。min.insync.replicas做了这样的保证

    2019-06-27
    4
    3
  • 明翼
    这个问题我想个办法就是程序停止再增加分区,如果不能停止那就找个通知机制了。请教一个问题min.insync.replicas这个参数如果设置成3,假设副本数设置为4,那岂不是只支持一台broker坏掉的情况?本来支持三台坏掉的,老师我理解的对不对

    作者回复: 嗯嗯,是的。本来就是为了更强的消息持久化保证,只能牺牲一点高可用性了~~

    2019-06-27
    2
    3
  • ban
    老师,
    如果我有10个副本,isr=10,然后我配置ack=all,min.insync.replicas=5,
    这时候这两个参数以谁为准,生产一个消息,必须是全部副本都同步才算提交,还是只要5个副本才算提交?

    作者回复: min.insync.replicas是保证下限的。acks=all的含义是producer会等ISR中所有副本都写入成功才返回,但如果不设置min.insync.replicas = 5,默认是1,那么假设ISR中只有1个副本,只要写入这个副本成功producer也算其正常写入,因此min.insync.replicas保证的写入副本的下限。

    2019-08-03
    2
  • Alan
    1 外部持久化每个topic的每个消费者组的每个patition的offset。

    2 程序重启时继续上一次的offset

    3 监控每个partition的offset,每次的from offset和to offset是不是线性连续的消费

    4 允许重复消费,在消费端去重
    2019-06-28
    2
  • QQ怪
    不知道是不是可以这样,生产者感知到了有新分区加入立即通知broke端下的消费者不能消费消息,直到消费端都感应到了加入的新分区之后,生产者和消费者才继续工作
    2019-06-27
    2
  • 空知
    老师问下
    第7条 一个副本挂掉 整个分区不能用了 是因为每次都必须保证可用副本个数 必须跟提交时候一致 才可以正常使用,又没有冗余副本导致的嘛?

    作者回复: 是因为不满足min.insync.replicas的要求了。比如该参数=2,当前ISR中只剩1个副本了,那么producer就没法生产新的消息了。

    2019-06-27
    1
    2
  • 没事走两步
    如果consumer改用"从最早位置"读解决新加分区造成的问题,那会不会导致旧的分区里的已被消费过的消息重新全部被消费一次

    作者回复: 只要位移没有越界以及有提交的位移,那么就不会出现这种场景。

    2019-06-27
    1
    2
  • 老师好,有个问题,就是:retries 和 send里面的callback,是什么关系?因为有说retries是kafka自动重试的次数,那么还要callback干吗,callback的意义在哪里呢? 如果一定要坚持用send(callback)api,那么retries是用来干吗的呢? 这两者之间的关系是什么呢?谢谢。

    作者回复: callback可以处理消息发送之后的逻辑,不一定就是失败的逻辑。retries是预防那种瞬时错误的,比如网络抖动这种问题,让Kafka自动重试一下会比较方便不是吗

    2019-11-16
    1
  • 浪迹人生
    请问消息的createTimestamp 是在生产者服务器上生成的,还是在进入不同partition 后生成的?我能不能根据这个时间戳来判断不同分区的消息原始全局顺序?谢谢🙏

    作者回复: 在生产者服务器上生成的。个人感觉不可以,毕竟每个producer服务器上的时钟不是实时同步的。事实上,用时钟来保证同步性是一件非常不靠谱的事情

    2019-11-01
    1
  • 知行合一
    老师,课后问题会出一节课统一解答吗
    2019-08-24
    1
    1
  • 玉剑冰锋
    老师好,针对producer为filebeat有什么是建议配置的吗?我们生产好像没有配置这方面的参数
    2019-06-27
    1
  • jfwwlong
    可以用send里的future.get来代替callback吗

    作者回复: future.get()相当于同步发送了,使用callback实现的是异步发送。到底使用哪个取决于你的选择了

    2019-12-10
收起评论
90
返回
顶部