我在之前写过很多关于消息队列的文章炒股配资要求，有 Kafka 的，也有 RocketMQ 的，不论是 Kafka 还是 RocketMQ 其设计思想都是利用本地机器的磁盘来进行保存消息队列，这样其实是有一定的弊端的：
数据有限，使用者两个消息队列的同学应该深有感触，一般会服务器保存最近几天的消息，这样的目的是节约存储空间，但是就会导致我们要追溯一些历史数据的时候就会导致无法查询。
扩展成本高，在数据库中的弊端在这里同样也会展现。
针对这些问题 ApachePulsar 出现了，pulsar 最初由 Yahoo 开发，在 18 年的时候一举将 kafka 连续两年 InfoWorld 最佳开源数据平台奖夺了过来。
在 Pulsar 的架构中，数据计算和数据存储是单独的两个结构：
展开剩余55%数据计算也就是 Broker，其作用和 Kafka 的 Broker 类似，用于负载均衡，处理 consumer 和 producer 等，如果业务上 consumer 和 producer 特别的多，我们可以单独扩展这一层。
数据存储也就是 Bookie，pulsar 使用了 Apache Bookkeeper 存储系统，并没有过多的关心存储细节，这一点其实我们也可以借鉴参考，当设计这样的一个系统的时候，计算服务的细节我们需要自己多去思考设计，而存储系统可以使用比较成熟的开源方案。
Pulsar 理论上来说存储是无限的，我们的消息可以永久保存，有人会说难道硬盘不要钱吗？当然不是我们依然要钱，在 Pulsar 可以进行分层存储，我们将旧的消息移到便宜的存储方案中，比如 AWS 的 s3 存储，而我们当前最新的消息依然在我们比较贵的 SSD 上。在这个模式下不仅是存储是无限，我们的计算资源扩展也是无限的，因为我们的计算资源基本上是无状态的，扩展是没有任何成本的，所以 Pulsar 也搞出了一个多租户的功能，而不用每个团队单独去建立一个集群，之前在美团的确也是这样的，比较重要的 BG 基本上都有自己的 Mafka 集群，防止互相影响。
Kafka 最新的一些提议炒股配资要求，也在向这些方面靠拢，比如也在讨论是否支持分层存储，当然是否采用 “计算和存储分离” 架构这个也是不一定的，但是我认为 “计算和存储分离” 的方向也是消息队列未来发展的主要方向。
发布于：湖南省