27 | Pulsar的存储计算分离设计：全新的消息队列设计思路
李玥
该思维导图由 AI 生成，仅供参考
你好，我是李玥。
之前的课程，我们大部分时间都在以 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/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
Pulsar是一款开源的分布式消息队列产品，其架构设计采用了存储计算分离的方式，与传统消息队列产品有着显著区别。Pulsar的Broker无状态，不保存元数据和消息数据，而是依赖于BookKeeper集群和ZooKeeper集群来存储消息数据和元数据。这种设计使得Pulsar的负载均衡策略更加灵活，可以根据Broker的负载情况动态调整分区与Broker的对应关系。同时，Pulsar通过一次性写入的方式解决了并发写入控制的问题，避免了使用分布式锁对性能造成的损失。此外，Pulsar还提供了集群间数据复制的特色功能，可实现不同集群之间的数据共享。存储计算分离的设计思想将系统的存储职责和计算职责分离开，使得计算节点无状态，具有易于开发、调度灵活的优点，故障转移和恢复也更加简单快速。尽管存储计算分离设计也存在一些缺点，但对于大部分分布式的业务系统来说，采用这种设计仍然是非常划算的。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《消息队列高手课》，新⼈⾸单¥59
《消息队列高手课》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(18)
- 最新
- 精选
DFighting其实存储计算分离在数据的相关性不大的情况下优势会很明显，我理解这种是对数据和计算进行了一种操作和对象的切分，在大多数情况下，操作和对象的耦合度不高，可以使用，因为无状态、单一功能这就是微服务架构的优势。但是这里有个天然的缺陷就是牺牲了大量的磁盘读写和网络IO的性能，如果计算和对象耦合度过大，也就是计算需要频繁读写多数据源的数据，那这种就不如传统的MQ了。不过随着数据量的增大，读写计算分离应该是趋势，如果数据和计算耦合度过高，优先思路应该是重新划分业务模块和整合数据源，把耦合相关的劣势转换为优势，不过这一点很难，需要业务专家、技术专家、架构专家和数据专家等的一起努力。作者回复: 👍
2019-10-25244
张天屹老师你好，请教一个本章的题外问题，对于严格的局部顺序性要求场景，比如十个分区，十个消费者线程，一一对应是可以保证的。但是绝不能一对多/批量预取，这个不设置多线程消费就可以了，但是在进程角度的话，为了保证顺序性，一个分区也只能被一个进程消费，那就没办法做消费者集群了吗，只有一个单体的消费者服务的话，可靠性是不是不太好，如果宕机了下游就完全挂了，这种情况怎么办呢？作者回复: 使用消息队列来保证严格顺序时，对于消费者是没有要求的。不需要单线程或者单进程，所以使用消费者集群是完全没有问题的，依然可以保证严格顺序。 消费者唯一需要保证的和接收普通消息是一样的，就是：先执行消费逻辑，再确认消费。
2019-09-273
好好写代码消息队列大部分应用的场景还是需要快速去消费数据，吞吐量比持久化优先级高。2019-09-26122
亚洲舞王.尼古拉斯赵四我有一下的几点想法： 1.性能方面的考虑：像文中说的，使用计算存储分离的设计方式，原本broker只需要在本地进行消息查找，但是现在却需要连接到另一个集群中进行查找消息，增加了网络耗时，一旦并发大，带宽占满了，性能就会明显下降。 2.成本原因： 这里的成本包括两方面：一方面是部署成本，本来只需要一个集群部署，现在我还好增加一个存储集群，增加了使用者的钱方面的成本；另一方面是使用者的学习成本，新引入一个集群，无论使用的是什么存储系统，如果想要更好的解决可能出现的问题，使用者都要去学习这个新的存储系统，增加了使用者的学习成本。2019-10-11113
峰本来就是数据管道结果管道还要套层管道，计算本来就很轻，分离出去一种浪费的感觉。2019-12-256- DFighting读了文章才发现，我们使用Flink做ETL真的很不适合，因为Flink适合计算，存储应该另外设计，系统设计存在明显的缺陷2019-10-2526
Jxin
回答问题： 1.mq这一侧的计算复杂度和存储管理难度都未到做更细拆分的程度。 2.在这些mq出来前，k8s这种容器编排的方案还没有。做结构拆分势必会增加复杂度，导致入门门槛提高，进而就不易于推广。而开源项目，亲和易推广也是很重要的指标。 自己的想法： 存储层在引入k8s的pv，pvc管理后，存储的管理复杂度就可以跟业务开发说再见了。毕竟上云后，这块东西就由云服务商承接走了。这样有利于更轻量的开发，亲和拥抱变化的市场环境。所以老师说是趋势。2019-11-104
boyxie可以用在对实时性要求不高的应用，比如定时任务类型的，可以存储海量数据2019-10-302
游弋云端个人觉得从微服务的思想来讲，专业的人干专业的事，进行服务的细粒度拆分，不做大而全的系统，这样架构清晰，可扩展性强。其他消息队列适合快速部署，可以做到对外依赖少的精简配置，例如kafka要去ZK，要支持单节点配置等，这与Pulsar是不同的。在后续的微服务、容器等演进的趋势下，个人认为Pulsar会更具有竞争力。目前来看，只能说各有千秋，各有不同的应用场景。2019-09-262
leslie不一样的思路：非常喜欢老师这种方式，不仅仅是基于当下，而是持久；让我觉得不仅仅是一个User，而是在User中去扩展。 就像之前学计算机组成原理是徐老师曾经提过基于CPU的MQ：当时问徐老师为什么有了CPU还需要有GPU？老师让我去看David Patterson老爷爷的文章，包括现在阿里做的GPU减负的是内存，应当是差不多的不一样的思路吧。 感谢老师分享不一样的新东西：让我们不仅仅基于当下、研究当下，甚至可以在MQ的方向上扩展研究下去。期待老师后面的继续分享。2019-09-262
收起评论
