Multi Tenancy

成为一个多租户系统是 Pulsar 最初设计理念的一部分。 并且,Pulsar 提出了租户的概念。 租户可以跨集群分布,每个租户都可以有单独的认证和授权机制。 租户也是存储配额、消息 TTL 和隔离策略的管理单元。

Pulsar 的多租户性质主要体现在 topic 的 URL 中,其结构如下:

  1. persistent://tenant/namespace/topic

可以看到,租户是 topic 的最基本单位(比命名空间和 topic 名称更为基本)。

租户

可以为 Pulsar 实例中的每个租户分配:

命名空间

Pulsar 通过租户和命名空间这两个关键概念支持多租户。

  • Pulsar 为指定的多个租户配置了合适的容量。
  • 命名空间是一个术语,指租户的管理单元。 命名空间上设置的配置策略适用于在该命名空间中创建的所有 topic。 租户可以使用 REST API 和 pulsar-admin CLI 工具来创建多个命名空间。 例如,包含多个应用程序的租户可以为每个应用程序创建单独的命名空间。

同一命名空间中 topic 的名称如下:

  1. persistent://tenant/app1/topic-1
  2. persistent://tenant/app1/topic-2
  3. persistent://tenant/app1/topic-3

命名空间更改事件和主题级策略

Pulsar 是一个多租户的事件流处理系统。 管理员可以通过设置不同层次的策略来管理租户和命名空间。 然而,有些策略,例如数据保留策略和数据存储配额策略,仅仅只能在命名空间级别设置。 在许多使用场景中,用户需要对主题设置对应的策略。 命名空间更改事件提供了一个简单有效的方式去修改主题级别的策略。 在这种方法中,Pulsar 使用事件日志去保存命名空间的事件改变记录(比如主题策略改动)。 这种方式有以下好处:

  • 避免过多使用 Zookeeper, 给 Zookeeper 带来更高的负载。
  • Use Pulsar as an event log for propagating the policy cache. It can scale efficiently.
  • 可以使用Pulsar SQL 可以查询命名空间的改变日志,并对系统进行审计。

每个命名空间有一个叫做__change_events的系统主题。 这个系统主题用来保存这个命名空间的事件改变信息。 如图所示,教你怎么样使用命名空间更改事件去实现主题级别的策略控制。

  1. Pulsar Admin 客户端可以使用Restful API和服务端通信,去修改主题级别的策略。
  2. 任何一台 broker 收到HTTP请求后,会往这个命名空间的__change_events主题发送一条策略改变事件信息。
  3. Each broker that owns a namespace bundle(s) subscribes to the __change_events topic to receive change events of the namespace. It then applies the change events to the policy cache.
  4. 一旦这个策略缓存被更新,这个broker会发送返回信息给 Pulsar Admin 客户端。