下载掌阅APP，畅读海量书库
立即打开
本章到此为止讨论了处理消息的早期系统，简要提及了像 RabbitMQ、ActiveMQ 和Apache Kafka 这样的系统。开发这样的系统需要大量的资源，还需要庞大的社区维护系统，以使其在开发者市场中保持活力。那么，为什么我们还需要一个新的系统呢？原因在于Apache Pulsar解决了其他事件代理系统没有解决的问题：
·将流和队列统一
·模块化
·性能
事件流需要一个有序的消息序列。有序序列使很多我们在第1章中介绍过的应用程序得以实现，它广泛地应用于我们日常使用的各类应用程序中。然而，事件流有独特的语义，它需要消费者决定如何处理流中的事件。如果应用程序不需要使用有序序列呢？如果每个客户端只需要获取下一个可用的事件，而不关心该事件在数据流中的位置呢？
Pulsar 中的主题可以是一个队列或一个事件流，如图 2-4 所示。这种灵活性意味着Pulsar集群可以为本章提到过的所有交互方式提供平台。
图2-4 在共享（Shared）订阅中，每个订阅者都会收到生产者产出的所有消息
我们之前讨论过发布/订阅模型中队列和事件流模型的不同之处。虽然这两个模型的区别足以促成不同的软件架构，但为了开发可靠的应用程序，开发者很可能需要同时使用这两种模型。软件开发团队围绕事件流和队列分别设计一套特定系统的做法并不罕见。虽然这种“有的放矢”的方法不失为明智之举，但也存在缺点。其一便是同时管理两个系统的运维负担，因为每个系统都有独特的维护计划和流程、最佳实践及运维范式。另一个缺点是，为了编写应用程序，开发者需要熟悉多种范式和API。
Pulsar 的模块化设计让它能同时满足队列和事件流模型的使用场景。我们会在第3章深入了解 Pulsar 的所有组件，但为了更好地引出后续的讨论，我们会在此介绍 Pulsar 的部分组件。Pulsar的设计明显地分离了系统中的不同职责。Pulsar系统中的一些职责包括：
·在有限时间段内为消费者存储数据
·在较长时间段内为消费者存储数据
·保证主题中数据的顺序
Pulsar 的短期存储由Pulsar Broker 负责
，长期存储由Apache BookKeeper 负责。这样的设计丰富了用户体验，也让Pulsar能广泛地用于解决消息领域中的多种问题。
对一个成熟的公司来说，从如 RabbitMQ、MQTT 或 Kafka 等现有消息系统迁移到Pulsar可能不太现实。因为每个消息系统都有自己独特的协议，需要使用特定的客户端库，且有独特的范式和语言。对一些大公司来说，迁移过程可能需要耗费数年的时间。幸运的是，Pulsar 可以和已有的消息系统同时使用，例如公司可以同时使用 Pulsar 和RabbitMQ，并逐渐将RabbitMQ的主题迁移到Pulsar，或通过Pulsar桥接框架
同时运行两套系统。Pulsar 桥接框架提供了将消息从 AMQP 0.9.1 协议（RabbitMQ 使用的协议）转换到 Pulsar 协议的机制。在这种模型下，之前使用 RabbitMQ 的应用程序可以继续使用 RabbitMQ 客户端，Pulsar 桥接框架会将以 AMQP 0.9.1 格式发送的消息在后台转换为 Pulsar 协议的消息。当团队成员做好相关配置后，他们可以继续从 Pulsar 中消费RabbitMQ消息。
在 Pulsar 的生态系统中，Pulsar 模块化设计的强大之处也显而易见。Pulsar 支持“函数即服务”（如图2-5所示），并且拥有在Pulsar主题数据之上使用SQL的能力，能通过最少的配置支持变化数据捕获（Change Data Capture，CDC）。这些功能为构建完善的事件驱动型应用程序提供了额外的组件和工具。
图2-5 Pulsar Functions是Pulsar内置的流处理运行时间
到此为止，我们已经讨论了高性能事件代理的三个重要特性。事件代理需要做到以下3点：1）可靠地存储数据；2）可靠地将数据投递给消费者；3）让消费者能迅速消费生产者产生的数据。要很好地完成这三项任务，需要缜密的设计和优化资源使用。所有事件代理都必须面对同样的磁盘读写速度、CPU、内存及网络的限制。在后面的章节中，我们会更深入地了解 Apache Pulsar 中的一些设计考量，但现在，我们可以先看看 Pulsar 中的部分设计如何带来了出色的性能和良好的可扩展性。
在“模块化”小节中，我们讨论了 Pulsar 基于 Apache BookKeeper 实现的模块化存储。我们聚焦于这种模块化的设计如何让一些特性存储和读取 Pulsar 数据。Pulsar 管理员能以独立于 Pulsar代理节点的方式扩展 BookKeeper 集群。消息系统中的存储需求可能在每天、每月或者每年中都会变化，Pulsar 的设计让用户可以简单灵活地扩展集群存储。当涉及存储数据的可靠性问题时，存储系统的可扩展性是一个关键因素。
消息消费的可靠性取决于事件代理能否处理它所接收到的消息量。如果事件代理向消费者投递消息的速度无法跟上生产者生产消息的速度，很多故障会随之出现。客户端通过Pulsar 协议连接到 Pulsar 集群的一个节点上。因为 Pulsar 节点可以独立于 BookKeeper集群进行扩缩，因而想扩展消费能力也更加灵活。
最后，Pulsar的原始性能又如何呢？Pulsar 集群每秒可以接收多少条消息？每秒又可以在 BookKeeper 集群中安全地存储多少消息呢？虽然现在已经有很多关于 Apache Pulsar的基准测试 [2] 和性能报告，但是你应该对这些基准测试持保留态度。如本章前文所述，每个消息系统都有所限制。设计这些消息系统的工程师会利用他们对系统的独特理解及测试环境，因此，设计能准确衡量每个系统性能的基准测试是徒劳的。尽管如此，Apache Pulsar作为一个高性能的消息系统已声名在外，数百家企业都选择了Pulsar 来管理它们的事件流平台。