消息队列高手课
李玥
京东零售技术架构部资深架构师
立即订阅
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讲)
结束语 | 程序员如何构建知识体系?
消息队列高手课
登录|注册

27 | Pulsar的存储计算分离设计:全新的消息队列设计思路

李玥 2019-09-26
你好,我是李玥。
之前的课程,我们大部分时间都在以 RocketMQ、Kafka 和 RabbitMQ 为例,通过分析源码的方式,来讲解消息队列的实现原理。原因是,这三种消息队列在国内的受众群体非常庞大,大家在工作中会经常用到。这节课,我给你介绍一个不太一样的开源消息队列产品:Apache Pulsar。
Pulsar 也是一个开源的分布式消息队列产品,最早是由 Yahoo 开发,现在是 Apache 基金会旗下的开源项目。你可能会觉得好奇,我们的课程中为什么要花一节课来讲 Pulsar 这个产品呢?原因是,Pulsar 在架构设计上,和其他的消息队列产品有非常显著的区别。我个人的观点是,Pulsar 的这种全新的架构设计,很可能是消息队列这类中间件产品未来架构的发展方向。
接下来我们一起看一下,Pulsar 到底有什么不同?

Pulsar 的架构和其他消息队列有什么不同?

我们知道,无论是 RocketMQ、RabbitMQ 还是 Kafka,消息都是存储在 Broker 的磁盘或者内存中。客户端在访问某个主题分区之前,必须先找到这个分区所在 Broker,然后连接到这个 Broker 上进行生产和消费。
在集群模式下,为了避免单点故障导致丢消息,Broker 在保存消息的时候,必须也把消息复制到其他的 Broker 上。当某个 Broker 节点故障的时候,并不是集群中任意一个节点都能替代这个故障的节点,只有那些“和这个故障节点拥有相同数据的节点”才能替代这个故障的节点。原因就是,每一个 Broker 存储的消息数据是不一样的,或者说,每个节点上都存储了状态(数据)。这种节点称为“有状态的节点(Stateful Node)”。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《消息队列高手课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(12)

  • DFighting
    其实存储计算分离在数据的相关性不大的情况下优势会很明显,我理解这种是对数据和计算进行了一种操作和对象的切分,在大多数情况下,操作和对象的耦合度不高,可以使用,因为无状态、单一功能这就是微服务架构的优势。但是这里有个天然的缺陷就是牺牲了大量的磁盘读写和网络IO的性能,如果计算和对象耦合度过大,也就是计算需要频繁读写多数据源的数据,那这种就不如传统的MQ了。不过随着数据量的增大,读写计算分离应该是趋势,如果数据和计算耦合度过高,优先思路应该是重新划分业务模块和整合数据源,把耦合相关的劣势转换为优势,不过这一点很难,需要业务专家、技术专家、架构专家和数据专家等的一起努力。

    作者回复: 👍

    2019-10-25
    3
  • 好好写代码
    消息队列大部分应用的场景还是需要快速去消费数据,吞吐量比持久化优先级高。
    2019-09-26
    1
  • Jxin
    回答问题:
    1.mq这一侧的计算复杂度和存储管理难度都未到做更细拆分的程度。
    2.在这些mq出来前,k8s这种容器编排的方案还没有。做结构拆分势必会增加复杂度,导致入门门槛提高,进而就不易于推广。而开源项目,亲和易推广也是很重要的指标。



    自己的想法:
    存储层在引入k8s的pv,pvc管理后,存储的管理复杂度就可以跟业务开发说再见了。毕竟上云后,这块东西就由云服务商承接走了。这样有利于更轻量的开发,亲和拥抱变化的市场环境。所以老师说是趋势。
    2019-11-10
  • boyxie
    可以用在对实时性要求不高的应用,比如定时任务类型的,可以存储海量数据
    2019-10-30
  • DFighting
    读了文章才发现,我们使用Flink做ETL真的很不适合,因为Flink适合计算,存储应该另外设计,系统设计存在明显的缺陷
    2019-10-25
  • 亚洲舞王.尼古拉斯赵四
    我有一下的几点想法:
    1.性能方面的考虑:像文中说的,使用计算存储分离的设计方式,原本broker只需要在本地进行消息查找,但是现在却需要连接到另一个集群中进行查找消息,增加了网络耗时,一旦并发大,带宽占满了,性能就会明显下降。
    2.成本原因:
    这里的成本包括两方面:一方面是部署成本,本来只需要一个集群部署,现在我还好增加一个存储集群,增加了使用者的钱方面的成本;另一方面是使用者的学习成本,新引入一个集群,无论使用的是什么存储系统,如果想要更好的解决可能出现的问题,使用者都要去学习这个新的存储系统,增加了使用者的学习成本。
    2019-10-11
  • 张天屹
    老师你好,请教一个本章的题外问题,对于严格的局部顺序性要求场景,比如十个分区,十个消费者线程,一一对应是可以保证的。但是绝不能一对多/批量预取,这个不设置多线程消费就可以了,但是在进程角度的话,为了保证顺序性,一个分区也只能被一个进程消费,那就没办法做消费者集群了吗,只有一个单体的消费者服务的话,可靠性是不是不太好,如果宕机了下游就完全挂了,这种情况怎么办呢?

    作者回复: 使用消息队列来保证严格顺序时,对于消费者是没有要求的。不需要单线程或者单进程,所以使用消费者集群是完全没有问题的,依然可以保证严格顺序。

    消费者唯一需要保证的和接收普通消息是一样的,就是:先执行消费逻辑,再确认消费。

    2019-09-27
    2
  • 游弋云端
    个人觉得从微服务的思想来讲,专业的人干专业的事,进行服务的细粒度拆分,不做大而全的系统,这样架构清晰,可扩展性强。其他消息队列适合快速部署,可以做到对外依赖少的精简配置,例如kafka要去ZK,要支持单节点配置等,这与Pulsar是不同的。在后续的微服务、容器等演进的趋势下,个人认为Pulsar会更具有竞争力。目前来看,只能说各有千秋,各有不同的应用场景。
    2019-09-26
  • Better me
    消息队列本身作为中间层应该以提升更好的性能为导向,但目前Pulsar的存储计算分离架构等于在中间层在分层,在架构上可以做到服务化单一职责,以及无状态的broker节点,但却有少许的性能损耗,如果以后能解决性能损耗的问题,那么存储计算分离架构必然是未来的趋势
    2019-09-26
  • A9
    是否使用存储计算分离也是一种trade off的体现。采用分离的架构,整个架构上模块更加清晰,能够降低开发成本,提升开发效率。不采用存储计算分离的架构,可能开发难度较大,不过整体效率更高。对于开发消息中间件来说,尤其是之前消息队列诞生时,计算机性能普遍性能交叉,可能牺牲一点开发的效率,获取更高的性能才是更重要的。
    另外,最近流计算的流行,同样的存储计算分离架构可能有能直接进行配合(并不太了解流计算)
    总结来说,算是诞生的时代背景占了相当大的原因吧
    2019-09-26
  • leslie
    不一样的思路:非常喜欢老师这种方式,不仅仅是基于当下,而是持久;让我觉得不仅仅是一个User,而是在User中去扩展。
          就像之前学计算机组成原理是徐老师曾经提过基于CPU的MQ:当时问徐老师为什么有了CPU还需要有GPU?老师让我去看David Patterson老爷爷的文章,包括现在阿里做的GPU减负的是内存,应当是差不多的不一样的思路吧。
         感谢老师分享不一样的新东西:让我们不仅仅基于当下、研究当下,甚至可以在MQ的方向上扩展研究下去。期待老师后面的继续分享。
    2019-09-26
  • 有铭
    消息队列的性能是个很重要的需求,既然存储计算分离了也就等于加了中间层。我们都知道加了中间层那是会损失性能的
    2019-09-26
收起评论
12
返回
顶部