上一节在docker容器运行并体验了单机模式的Pulsar，使用命令行管理工具pulsar-admin创建了租户、命名空间和Topic，了解了Pulsar Admin REST API。 本节将对pulsar的租户、命名空间、Topic相关的内容做一下整理。

Pulsar被设计为一个多租户系统，租户可以跨集群分布，每个租户都可以有单独的认证和授权机制，可以针对租户设置存储配额、消息生存时间TTL和隔离策略。 Pulsar的多租户功能使其可以为组织中的不同部门、不同团队提供安全且独占的消息服务，允许不同部门、不同团队之间共享。这样一个Pulsar实例下边多个Pulsar集群可以成为整个组织的消息平台服务。 Pulsar使用租户、命名空间、主题的层次结构支持多租户，这就是Pulsar的逻辑架构，描述了在Pulsar中如何存储数据的逻辑结构。

pulsar-logical-arch.png

在上图中将租户划给了组织的不同的部门或团队，实际上租户代表了组织中特定的业务单元，产品线、核心功能，这些由不同的部门或团队负责。

pulsar-logical-arch2.png

租户(Tenant)

租户可以跨集群分布，表了组织中特定的业务单元，产品线、核心功能，这些由组织不同的部门或团队负责。每个租户都可以有单独的认证和授权机制，可以针对租户设置存储配额、消息生存时间TTL和隔离策略。

命名空间(Namespace)

命名空间是租户的管理单元，每个租户下可以创建多个命名空间。可以通过在命名空间上设置的配置策略来管理该命名空间下的Topic，这样就可以在命名空间的级别上为该命名空间的所有Topic设置访问权限、调整复制设置、管理跨集群跨地域的消息复制，控制消息过期时间。

主题(Topic)和分区主题(Partitioned Topic)

在Pulsar中所有消息的读取和写入都是和Topic进行，Pulsar的Topic本身并不区分发布订阅模式或者生产消费模式(独占, 一个消息只能被一个消费者消费)，Pulsar是依赖于各种订阅类型来控制消息的使用模式。

在RabbitMQ中有Exchange的概念，而Exchange的类型分为dircet, topic, fanout, header四中类型，可以通过组合Producer，Exchange, Queue, Consumer来实现这两种模式。

在Kafka中有Topic、Topic分区、消费者组的概念，Consumer被分组，Topic的每个分区只能被一个消费者组中的一个消费者消费。例如，一个Topic有4个分区，消费者组1中有4个消费者，消费者组2中有2个消费者，这两个消费者组都订阅了这个Topic，则组1中每个消费者分配到1个分区，组2中每个消费者分配到2个分区。Kafka很好的实现了发布订阅模式，多个消费者组可以消费同一个消息。如果只把Kafka中的一个Topic和只有一个消费者的消费者组进行关联，就模拟除了生产消费独占模式，但这也存在其缺点。

默认情况下一个Topic中的消息只能由Pulsar服务层中的一个Broker提供服务，因此单个Topic的吞吐量受限于为其提供服务的Broker的计算能力。 好在Pulsar还支持分区主题(partitioned topic)，这允许多个Broker提供服务，就可以将负载分布到多台机器上。在Pulsar内部，分区主题被实现为N个内部Topic，N是分区数量，分区跨Broker的分布由Pulsar自动管理，这对用户来说是完全透明的。 Pulsar将分区主题实现为多个内部主题，这样就可以在需要增加分区数量的时候不必重新平衡整个主题，Pulsar只需在其内部创建新的分区(内部主题)就能够立即接收新的消息，使客户端能在不中断的情况下对现有分区进行消息读写。

当生产者发布消息到分区主题时，不需要特意指定路由模式，默认使用RoundRobinPartition路由模式，将以轮循的方式将消息均匀分布到各个分区。目前支持以下3种路由模式:

  • SinglePartition: 如果没有消息key提供，将会随机选择一个单独的分区来发布消息，可用于将来自特定生产者的消息分组在一起，以在没有键值(key)时维护消息顺序。
  • RoundRobinPartition: 如果没有消息key提供，将以轮循的方式将消息均匀分布到各个分区
  • CustomPartition: 定制实现路由模式，控制消息分发到Topic的分区中

如果提供了消息key，会以key做hash，然后分配消息到指定分区。因此分区中消息的顺序与路由模式和消息的key有关:

  • 按key分区，即所有拥有相同的key的消息有序，将会被发送到相同的分区
  • 按producer，当路由模式为SinglePartition，且消息没有提供key时，来自于相同的Producer的消息有序

Topic的URL，持久化Topic和非持久化Topic

Pulsar Topic默认是持久化的，即会保存还没确认的消息到BookKeeper集群的bookies节点中。持久化Topic的消息数据可以在broker重启或者订阅者出问题的，故障转移之后继续存在。 Pulsar还支持非持久性topic，这些topic的消息从不持久化存储到磁盘，只存在于内存中，当使用非持久topic分发时，关闭Broker或者关闭订阅者，非持久化Topic上所有的瞬时消息都会丢失，客户端可能会出现丢失消息的情况。 非持久topic中，broker会立即发布消息给所有连接的订阅者，而不会在BookKeeper中存储。 如果有一个订阅者断开连接，broker将无法重发这些瞬时消息，订阅者将永远无法收到这些消息了。

虽然非持久消息传递通常比持久消息传递快，因为它避免了将数据持久化到磁盘相关的延迟，但只有在您确定具体的业务场景能够容忍消息丢失时，才建议使用它。

  • 持久化Topic URL的格式为: persistent://tenant/namespace/topic-name
  • 非持久化Topic URL的格式为: non-persistent://tenant/namespace/topic-name

参考