Pulsar namespace 策略的简单小介绍_Pulsar namespace

 

首先来简单回顾下上周 Pulsar 的动态:

  • Set message TTL on topic level
    https:///apache/pulsar/pull/7738

  • Set retention on topic level
    https:///apache/pulsar/pull/7747

  • Support consume transaction messages
    https:///apache/pulsar/pull/7781

  • Support subscription position and expose the producer setting
    https:///apache/pulsar/pull/7772

  • Pulsar 2.6.1 版本即将发布,敬请期待!

 

 

Namespace policies 概况

 

Namespace policies 和一些源数据是存储在 Global ZooKeeper 中,具体操作和源码部分,可以参考视频回放 11:00-12:55 部分。

 

Pulsar namespace 策略的简单小介绍_Pulsar namespace _02

不同的 namespace 下会对应不同的 configuration。这些 namespace policies 是通过 Pulsar Admin 进行设置,然后 broker 会处理此请求并写入到 Global ZooKeeper 中。当 broker 去进行一些 check message 等请求时,就会读取 Global ZooKeeper 中的 policies。

???? 隔离

不同的 namespace 也有不同的 policy。因为 topic 级别是没有隔离机制,很多人在配置 policy 时,就需要将其映射为 namespace,利用 namespace 的隔离机制来将不同 topic 进行不同 policy 的配置请求。

Pulsar namespace 策略的简单小介绍_Pulsar namespace _03

几种 policy 机制介绍

???? Retention_policies 

 

  • retentionTimeInMinutes
  • retentionSizeInMB
此配置主要是设置保留时长和保留大小。消费位置最早的订阅决定了你能保留消息多久。订阅之前的消息可被删除,这是 Pulsar 的默认行为,即消费完就可以被删除,释放空间留给之后的消息使用。由于流计算的需求,有些数据消费完还不能删除,需要再额外保留个三五天。这种情况下,就需要有 retention 来进行数据保留设置。

Pulsar namespace 策略的简单小介绍_Pulsar namespace _04

关于此 policy Demo 的演示,可以参考视频回放 16:50-22:50 时间段。

???? Message_ttl_in_seconds 

由于后边未开始被消费的订阅还没有处理完全,所以仍需要进行操作。这些未处理消息没有被删除,但是所有的 consumer 均已下线,那么消息是永远不会被确认的。这样消息就会被一直累积。

Pulsar namespace 策略的简单小介绍_Pulsar namespace _05

为了保证整个生产线的正常运作,可以在这些「橘色消息」部分添加 TTL。TTL 作用范围是没被确认的消息,通过移动 cursor 来实现确认目标。

Pulsar namespace 策略的简单小介绍_Pulsar namespace _06

TTL 的好处在于,可以保证消息的过期时间与 retention 的过期时间保持一致。一旦消息自动过期,会进入 retention 的处理流程,利用 retention 的特性进行数据清除。关于此 policy Demo 的演示,可以参考视频回放 24:00-29:00 时间段。

???? Replication_clusters

此 policy 主要应用于跨地域复制特性中。

Geo replication 里最核心的一个概念是 Configuration Store(老版本中称为 Global ZooKeeper),它存储的是集群复制信息,让集群之间互相了解各自的地址。同时还包括一些 clients 或 namespace 的相关配置信息。这样做的目的可以简化操作,只需一步即可将各个集群信息一同更新。

Pulsar namespace 策略的简单小介绍_Pulsar namespace _07

???? Max_producers_per_topic???? Max_consumers_per_topic???? Max_consumers_per_subscription

此类 policy 都会在达到最大限制后,收到相关提示命令。关于此 max 系列类的 policy Demo 展示,可以参考视频回放 29:30-33:40 时间段。

???? Backlog_quota_map

存在 backlog 里的消息,可以有 3 种 Retention Policy:

  • `Producer_request_hold`: producer 将进入等待状态,broker 将不会将 message 持久化

  • `Producer_exception`: broker 将断开 producer 的链接并且返回给客户端相应的错误

  • `Consumer_backlog_eviction`: 客户端开始丢弃积压消息

关于此 policy Demo 展示,可以参考视频回放 35:30-43:40 时间段。关于剩余其他的 policy Demo (topicDispatchRate、subscriptionDispatchRate、auth_policies)展示,可以参考视频回放 44:50-47:30 时间段。总结

 

本次分享主要向大家简要地说明了一些 namespace policy 的效果和 demo 展示,想要获取更多细节分享,可以参考下方回放视频。希望大家可以在看过视频后都能有所收获。