消息队列高手课
李玥
美团高级技术专家
52199 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
进阶篇 (21讲)
消息队列高手课
15
15
1.0x
00:00/00:00
登录|注册

30 | 流计算与消息(二):在流计算中使用Kafka链接计算任务

计算结果再发给Kafka的B主题
发送给Flink的计算集群进行计算
数据从Kafka的A主题消费
配置isolation.level=read_committed
定义自动重启策略
设置保存CheckPoint的StateBackend
开启CheckPoint
配置Exactly Once语义
计算结果写入Kafka的主题ip_count_sink
计算任务消费ip_count_source的数据
日志服务发送日志数据到Kafka的主题ip_count_source
Flink基于两阶段提交算法实现分布式事务控制器
Kafka的事务和生产幂等特性
CheckPoint机制实现集群内计算任务的Exactly Once语义
Flink集群内部保证数据只被计算一次
端到端Exactly Once
包含计算任务的状态和数据源的位置信息
保存计算任务的快照
FlinkKafkaConsumer
CheckPoint配置
FlinkKafkaProducer
数据流向
配合Flink实现端到端Exactly Once
事务和生产幂等特性
Kafka配合Flink实现端到端Exactly Once
Exactly Once语义
CheckPoint机制
实战:Exactly Once版本的Web请求的统计
Kafka
Flink
流计算与消息(二):在流计算中使用Kafka链接计算任务
参考文章

该思维导图由 AI 生成,仅供参考

你好,我是李玥。
上节课我们一起实现了一个流计算的例子,并通过这个例子学习了流计算的实现原理。我们知道,流计算框架本身是个分布式系统,一般由多个节点组成一个集群。我们的计算任务在计算集群中运行的时候,会被拆分成多个子任务,这些子任务也是分布在集群的多个计算节点上的。
大部分流计算平台都会采用存储计算分离的设计,将计算任务的状态保存在 HDFS 等分布式存储系统中。每个子任务将状态分离出去之后,就变成了无状态的节点,如果某一个计算节点发生宕机,使用集群中任意一个节点都可以替代故障节点。
但是,对流计算来说,这里面还有一个问题没解决,就是在集群中流动的数据并没有被持久化,所以它们就有可能由于节点故障而丢失,怎么解决这个问题呢?办法也比较简单粗暴,就是直接重启整个计算任务,并且从数据源头向前回溯一些数据。计算任务重启之后,会重新分配计算节点,顺便就完成了故障迁移。
回溯数据源,可以保证数据不丢失,这和消息队列中,通过重发未成功的消息来保证数据不丢的方法是类似的。所以,它们面临同样的问题:可能会出现重复的消息。消息队列可以通过在消费端做幂等来克服这个问题,但是对于流计算任务来说,这个问题就很棘手了。
对于接收计算结果的下游系统,它可能会收到重复的计算结果,这还不是最糟糕的。像一些统计类的计算任务,就会有比较大的影响,比如上节课中统计访问次数的例子,本来这个 IP 地址在统计周期内被访问了 5 次,产生了 5 条访问日志,正确的结果应该是 5 次。如果日志被重复统计,那结果就会多于 5 次,重复的数据导致统计结果出现了错误。怎么解决这个问题呢?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入介绍了如何在流计算中使用Kafka实现端到端的Exactly Once语义。首先,文章解释了流计算框架的分布式特点和数据持久化问题,然后详细介绍了Flink如何通过CheckPoint机制保证计算任务的Exactly Once语义。接着,文章讨论了Flink与Kafka配合实现端到端Exactly Once的原理,包括Flink基于两阶段提交算法实现的分布式事务控制器。通过对Kafka的事务和生产幂等特性的利用,结合Flink的CheckPoint机制和分布式事务控制器,实现了端到端的Exactly Once语义。文章还提供了一个实战案例,展示了如何使用Java语言实现具备Exactly Once特性的实时统计任务。总的来说,本文内容深入浅出,对于想要了解流计算与消息处理的读者具有很高的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《消息队列高手课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(9)

  • 最新
  • 精选
  • DFighting
    关于思考题,我在infoQ上找了一篇文章https://www.infoq.cn/article/58bzvIbT2fqyW*cXzGlG,不知道是不是这么实现的,请老师帮忙看下。

    作者回复: 是这样的。

    2019-10-28
    14
  • 张天屹
    老师你好,能介绍下Kafka 配合 Flink,与Kafka Stream 的核心区别吗

    作者回复: Kafka Stream目前来说,相关的生态还不够成熟,可以了解一下,但不建议在生产系统中使用。 它和flink最大的区别是,它是一个库,运行在你的应用程序进程内,而不是一个流计算框架。

    2019-10-05
    3
  • Geek_c24555
    老师好,请问下 rocketmq 可以配合 flink 实现exactly once 吗

    作者回复: 据我了解,RocketMQ目前还没有支持。你可以跟踪一下这个Issue:https://github.com/apache/rocketmq-externals/issues/500

    2020-06-13
    2
  • jack
    老师,使用spark streaming 和kafka时, 1、spark官方文档说,如果保存到checkpoint和把offset 提交到kafka,必须保证输出是幂等的,光使用事务是不行的; 2、那么如果无法保证输出是幂等的,是否只能把offset 保存在第三方的数据库(比如redis)中,但是这样做是否是不可以设置checkpoints ?否则spark依然会从checkpoint中读取,和从数据库中读取会造成冲突呢? 3、但不设置checkpoint,spark如何恢复现场呢?在提交命令时加入--supervise,好像yarn的模式不支持?即使使用supervise重启,没有checkpoint,也无法恢复现场吧?

    作者回复: A1:是这样的,所以Kafka的Exactly Once特性中是有事务和生产幂等(相当于流计算输出幂等)二个功能组成的。 A2:这个方法不太可行,因为你很难做到完美的故障恢复。原因我在课程中也讲到了。 A3:具体操作细节层面的问题,还是建议你以官方的文档为准。

    2019-10-09
    2
  • 不惑ing
    第25章讲kafka exactly once需要从kafka topicA读取计算再保存到kafka topocB,但从这章讲的流程看,最后不需要保存到kafka topicB,保存到其他hdfs里也可以, 所以最后一步保存位置有具体要求吗?

    作者回复: 理论上是可以的,但是实际上hdfs没有原生事务支持,实现起来比较困难。

    2019-10-06
    2
  • i_chase
    kafka ==> flink ==> kafka虽然实现了exactly once,但是最终进入output kafka的数据不也需要消费出来的吗? 是不是因为这里从output topic消费只是打印一下消息,即使重复消费也没关系?
    2022-03-28
  • Geek_7825d4
    Flink 中有个 AsyncIO 算子,自身提供了 Exactly Once 语义,但是一致有个问题不太清楚,AsyncIO 为了提升性能,提供异步无序处理的方式,这种情况下,假设有一个 offset 为 1 的数据 阻塞在异步中,会不会有1一个 offset 为 2 的消息已经被处理完了,并继续向下游发送。 此时当 2 已经端到端完成时, Flink 是否会向 Kafka Source 提交 2 位置的偏移量呢,这样如何保证 Exactly Once 呢
    2021-03-24
  • Heaven
    看了上面同学的留下的文章,发现Flink是维护两个位置offset和commitedOffset,内部在进行快照保存的时候,保存了offset作为快照内部位置,在快照完成之后,会变动维护的commitedOffset属性值,将变更后的commitedOffset提交到Kafka brokers或者ZK中
    2021-02-20
  • 长脖子树
    正好最近在看 flink , 这部分端到端的 exactly once 实现讲得很清晰!
    2020-08-26
收起评论
显示
设置
留言
9
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部