消息队列高手课
李玥
京东零售技术架构部资深架构师
立即订阅
8426 人已学习
课程目录
已完结 41 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (2讲)
开篇词 | 优秀的程序员,你的技术栈中不能只有“增删改查”
免费
预习 | 怎样更好地学习这门课?
基础篇 (8讲)
01 | 为什么需要消息队列?
02 | 该如何选择消息队列?
03 | 消息模型:主题和队列有什么区别?
04 | 如何利用事务消息实现分布式事务?
05 | 如何确保消息不会丢失?
06 | 如何处理消费过程中的重复消息?
07 | 消息积压了该如何处理?
08 | 答疑解惑(一) : 网关如何接收服务端的秒杀结果?
进阶篇 (21讲)
09 | 学习开源代码该如何入手?
10 | 如何使用异步设计提升系统性能?
11 | 如何实现高性能的异步网络传输?
12 | 序列化与反序列化:如何通过网络传输结构化的数据?
13 | 传输协议:应用程序之间对话的语言
14 | 内存管理:如何避免内存溢出和频繁的垃圾回收?
加餐 | JMQ的Broker是如何异步处理消息的?
15 | Kafka如何实现高性能IO?
16 | 缓存策略:如何使用缓存来减少磁盘IO?
17 | 如何正确使用锁保护共享数据,协调异步线程?
18 | 如何用硬件同步原语(CAS)替代锁?
19 | 数据压缩:时间换空间的游戏
20 | RocketMQ Producer源码分析:消息生产的实现过程
21 | Kafka Consumer源码分析:消息消费的实现过程
22 | Kafka和RocketMQ的消息复制实现的差异点在哪?
23 | RocketMQ客户端如何在集群中找到正确的节点?
24 | Kafka的协调服务ZooKeeper:实现分布式系统的“瑞士军刀”
25 | RocketMQ与Kafka中如何实现事务?
26 | MQTT协议:如何支持海量的在线IoT设备?
27 | Pulsar的存储计算分离设计:全新的消息队列设计思路
28 | 答疑解惑(二):我的100元哪儿去了?
案例篇 (7讲)
29 | 流计算与消息(一):通过Flink理解流计算的原理
30 | 流计算与消息(二):在流计算中使用Kafka链接计算任务
31 | 动手实现一个简单的RPC框架(一):原理和程序的结构
32 | 动手实现一个简单的RPC框架(二):通信与序列化
33 | 动手实现一个简单的RPC框架(三):客户端
34 | 动手实现一个简单的RPC框架(四):服务端
35 | 答疑解惑(三):主流消息队列都是如何存储消息的?
测试篇 (2讲)
期中测试丨10个消息队列热点问题自测
免费
期末测试 | 消息队列100分试卷等你来挑战!
结束语 (1讲)
结束语 | 程序员如何构建知识体系?
消息队列高手课
登录|注册

29 | 流计算与消息(一):通过Flink理解流计算的原理

李玥 2019-10-01
你好,我是李玥。
在上节课中,我简单地介绍了消息队列和流计算的相关性。在生产中,消息队列和流计算往往是相互配合,一起来使用的。而流计算也是后端程序员技术栈中非常重要的一项技术。在接下来的两节课中,我们一起通过两个例子来实际演练一下,如何使用消息队列配合流计算框架实现一些常用的流计算任务。
这节课,我们一起来基于 Flink 实现一个流计算任务,通过这个例子来感受一下流计算的好处,同时我还会给你讲解流计算框架的实现原理。下一节课中,我们会把本节课中的例子升级改造,使用 Kafka 配合 Flink 来实现 Exactly Once 语义,确保数据在计算过程中不重不丢。
无论你之前是否接触过像 Storm、Flink 或是 Spark 这些流计算框架都没有关系,因为我们已经学习了消息队列的实现原理,以及实现消息队列必备的像异步网络传输、序列化这些知识。在掌握了这些知识和底层的原理之后,再来学习和理解流计算框架的实现原理,你会发现,事情就变得非常简单了。
为什么这么说,一个原因是,对于很多中间件或者说基础框架这类软件来说,它们用到很多底层的技术都是一样;另外一个原因是,流计算和消息队列处理的都实时的、流动的数据,很多处理流数据的方法也是一样的。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《消息队列高手课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(6)

  • 张天屹
    老师你好,请教个概念,虽然处理统计的程序叫做“流”计算,但是比如每5秒或者1分钟这样的时间间隔统计一次,那么对于有向无环图的每个节点,其实还是按照“批处理的”吗,即必须等这一分钟的结果汇集为一批处理完了,才传输到协议个Task节点。

    作者回复: 不是这样的,每条数据是实时流过的,并不会等待。
    只有做按时间汇聚的那个节点,它会记录汇总的中间结果(注意,它只记录汇总的中间结果,并不知把所有数据都攒起来),在每个时间窗口结束后会在流中产生一条新的数据(也就是统计结果),流往下游。

    比如,每分钟统计数据条数,汇聚的这个节点每流过一条数据,统计值就+1,它不会保存流过的数据,等到时间窗口结束,这个统计就做完了,它直接生成一条统计结果数据,发往下游。

    2019-10-04
    6
  • 囊子
    老师您好,采用时序数据库比如prometheus,然后用grafana去做展示监控指标信息。感觉从表现形式上和流计算有些类似,时序数据库也支持统计功能。这两种形式的架构和使用场景,老师有什么看法呢?(除了并行计算这个点)

    作者回复: 场景不太一样,这种场景更在乎的是海量吞吐,快速查询,对于数据可靠性和一致性的要求没那么高,毕竟一个图标上少一两个点也没什么关系。

    2019-10-09
    2
  • DFighting
    上一篇留言无意提交了,文章具体内容可以谷歌搜索Streaming 101,Streaming 102

    作者回复: Streaming 101 这篇博文就是Flink的理论基础。

    2019-10-28
  • DFighting
    taskmanager.numberOfTaskSlots表示TaskManager可以支配的CPU内核数,和并行度并不是一个层次的概念,一个基础配置,一个是运行时可以从集群中分配到多少资源。
    ps:关于流计算的相关知识有两篇文章可以学习下,我觉得他们是最好的Flink入门papper了
    2019-10-28
  • 川杰
    如果服务端在处理过程是失败了呢?所以,需要客户端收到服务端明确的告知:”数据我收到并且处理成功了“,才能保证数据不会丢失。
    老师您好,对于上一问题,我还有疑问。
    对于服务端处理过程中的失败,假设场景: 业务A处理完毕后,数据需要落地,结果数据保存时出现异常,无法正常落地。
    对于这种场景,应该是业务处理完毕后就发送确认给消息产生者吧?
    我想表达的意思是,对于服务端这种业务场景,是否使用ACK,应该还是要具体问题具体分析的吧?

    作者回复: 一般应该是数据持久化完成后在发送消费成功确认。

    2019-10-02
  • 川杰
    老师,请问网上说的ACK机制,在消息队列中到底什么场景下要使用呢?
    我理解,异步线程发送消息后,虽然主线程没法捕获异常,但子线程也可以判断出是否发送成功。那么为什么还要等待接收方返回一个数据处理完的结果呢?

    作者回复: 这个原因很简单,你想一下,客户端发送成功并不等于服务端处理成功,如果数据在网络传输过程中丢了呢?如果服务端在处理过程是失败了呢?所以,需要客户端收到服务端明确的告知:”数据我收到并且处理成功了“,才能保证数据不会丢失。

    2019-10-01
收起评论
6
返回
顶部