关于apache:博文推荐-一文带你看懂-Pulsar-的消息保留和过期策略

编者荐语：

原文作者冉小龙，首发于公众号“腾讯云中间件”，公布已取得原帐号受权。如需转载，请返回联系。本文次要为大家介绍 Apache Pulsar 的音讯保留和过期策略，供大家参考。

对于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。
GitHub 地址：http://github.com/apache/pulsar/

默认状况下，Pulsar Broker 会对音讯做如下解决：

当音讯被 Consumer 确认之后，会立刻执行删除操作。
对于未被确认的音讯会存储到 backlog 中。

然而，很多线上的生产环境下，这种默认行为并不能满足咱们的生产需要，所以，Pulsar 提供了如下配置策略来笼罩这些行为：

Retention 策略：用户能够将 Consumer 曾经确认的音讯保留下来。
TTL 策略：对于未确认的音讯，用户能够通过设置 TTL 来使未确认的音讯达到曾经确认的状态。

上述两种策略的设置都是在 NameSpace 的级别进行设置。

Retention 策略的设置提供了两种形式：

音讯的大小，默认值：defaultRetentionSizeInMB=0
音讯被保留的工夫，默认值：defaultRetentionTimeInMinutes=0

咱们能够在 broker.conf 中对这两项内容进行配置也能够通过命令行的模式。上文提到过，这两种策略的设置，都是在 NameSpace 的级别进行设置，所以当咱们应用命令行配置时，应用 NameSpaces 来进行配置，具体如下：

root@e6df71e544ea:/pulsar# ./bin/pulsar-admin namespaces set-retention
The following options are required: --size, -s --time, -t
Set the retention policy for a namespace
Usage: set-retention [options] tenant/namespace
  Options:
  * --size, -s
       Retention size limit (eg: 10M, 16G, 3T). 0 or less than 1MB means no
       retention and -1 means infinite size retention
  * --time, -t
       Retention time in minutes (or minutes, hours, days, weeks eg: 100m, 3h, 2d,
       5w). 0 means no retention and -1 means infinite time retention

如上所示：咱们能够通过 -s 或者 -t 来指定咱们须要配置的大小或者工夫。

当你设置 Retention 策略之后，能够通过如下命令来查看具体的信息：

$ pulsar-admin namespaces get-retention [your tenant]/[your-namespace]
{
  "retentionTimeInMinutes": 10,
  "retentionSizeInMB": 0
}

backlog 是未被确认音讯的汇合，它有一个大前提是，这些音讯所在的 Topic 是被 Broker 所长久化的，在默认状况下，用户创立的 Topic 都会被长久化。换句话说，Pulsar Broker 会将所有未确认或者未解决的音讯都寄存到 backlog 中。

同样的，咱们能够在 NameSpace 级别对 backlog 的大小进行配置。须要留神的是，对 backlog 进行配置时，咱们须要明确以下两点：

在以后的 NameSpace 下，每一个 Topic 容许的大小是多少
如果超过设定的 backlog 的阈值，将会执行哪些操作

当超过设定的 backlog 的阈值，Pulsar 提供了以下三种策略供用户抉择：

你能够通过 set-backlog-quota 在 NameSpace 级别对 backlog 进行配置，具体如下：

root@e6df71e544ea:/pulsar# ./bin/pulsar-admin namespaces set-backlog-quota
The following options are required: -l, --limit -p, --policy
Set a backlog quota policy for a namespace
Usage: set-backlog-quota [options] tenant/namespace
  Options:
  * -l, --limit
       Size limit (eg: 10M, 16G)
  * -p, --policy
       Retention policy to enforce when the limit is reached. Valid options are:
       [producer_request_hold, producer_exception, consumer_backlog_eviction]

如上所示，set-backlog-quota 提供了两个参数，-l 用来指定你设置 backlog 的大小，-p 用来指定，当超过你设置的 backlog 的阈值之后，Broker 将会执行的策略。

当你设置 backlog 之后，能够通过如下命令，查看相应的信息：

$ pulsar-admin namespaces get-backlog-quotas [your tenant]/[your namespace]
{
  "destination_storage": {
    "limit" : 2147483648,
    "policy" : "producer_request_hold"
  }
}

如果你冀望勾销 backlog 的配置，能够应用如下命令：

$ pulsar-admin namespaces remove-backlog-quota [your tenant]/[your namespace]

当有音讯积压时，你能够通过 clear-backlog 来革除积压的音讯。革除 backlog 中积压的音讯是绝对危险的操作，所以零碎会提醒你，是否确认要删除 backlog 中的音讯，clear-backlog 提供了 -f(--force) 的参数来屏蔽该提醒。

$ pulsar-admin namespaces clear-backlog [your tenant]/[your namespace]

默认状况下，Pulsar 会长久化所有未被确认的音讯。如果未被确认的音讯有很多，这种策略会造成大量的音讯被积压，导致磁盘空间增大。有些场景下，音讯并不需要被长久化，用户更冀望的行为是，将这些未被确认的音讯间接抛弃。这种状况下，你能够通过设置 TTL 使得未被确认的音讯进入到被确认的状态，当超过设定的 TTL 工夫之后，配合相应的 Retention 策略将音讯抛弃。

TTL 的一个典型应用场景是，当 Consumer 因为某些起因呈现故障，不能失常生产音讯，这时 Producer 还在一直的往 Topic 中生产音讯，会造成 Topic 中有大量的未确认的音讯呈现，这时你能够通过设置 TTL 将这些未确认的音讯变为已确认的状态。

同样的，你能够在 Namesapce 级别下，通过指定 set-message-ttl 对 TTL 进行设置，具体命令如下：

root@e6df71e544ea:/pulsar# ./bin/pulsar-admin namespaces set-message-ttl
The following option is required: --messageTTL, -ttl
Set Message TTL for a namespace
Usage: set-message-ttl [options] tenant/namespace
  Options:
  * --messageTTL, -ttl
       Message TTL in seconds
       Default: 0

如上所示，set-message-ttl 只有一个参数 -ttl，单位为秒，默认值为 0。

当你设置 TTL 策略之后，能够通过 get-message-ttl 查看相应的配置信息，具体如下：

$ pulsar-admin namespaces get-message-ttl [your tenant]/[your namespace]
60

在上述的形容过程中，能够发现，TTL 只去解决一件事件，将未被确认的音讯变为被确认的状态，TTL 自身不会去波及相应的删除操作，具体如下图所示：

在 T1 阶段，m1-m5 这 5 条音讯被确认，m6-m10 这 5 条音讯未被确认
在 T2 阶段，对 m6、m7、m8 这三条音讯设置 TTL 策略
在 T3 阶段，达到 TTL 设定的阈值，m6、m7、m8 这三条音讯被确认

通过上图能够看到，对于 backlog 中未被确认的音讯，当你设置 TTL 之后，会将未确认音讯的状态变为确认的状态。TTL 在这里所起到的作用就是将音讯的 Cursor 从 m5 挪动到 m8，m6、m7、m8 这三条音讯变为已确认状态。

Pulsar 是一个 multiple-subscription 的音讯零碎，对于 Topic 中的一条音讯，只有当所有订阅者都对这条音讯 ack 或者生产了，它能力被删除。

默认状况下，Pulsar Broker 会将所有未确认的音讯长久化到 backlog 中。TTL 的性能是，你能够将这些未被确认的音讯变为被确认的状态，而 Retention 所关注的点是，当音讯处于被确认的状态时，你能够对已确认的音讯进行的保留策略是什么。换句话说，backlog 是针对未确认的音讯，Broker 所做的解决是什么。Retention 是针对已确认的音讯，Broker 所做的保留策略是什么。

死信队列的相干介绍在此不做赘述。

在生产环境中，有时可能遇到品质差的数据是因为上游的起因导致的，必须由上游来解决，持续尝试解决其它的音讯曾经没有意义，这时候用户心愿在产生谬误时立刻进行解决。Pulsar 中提供了一种非凡的 Topic——死信队列。

死信队列与 TTL 都能够将未确认的音讯变为已确认的状态。他们之间次要的不同在于，在上图中的 T2 阶段，TTL 只是将未确认的音讯变为已确认的状态，死信队列的做法是将音讯抛弃到死信队列中，m6、m7、m8 这三条音讯变为被确认的状态。m9、m10 这两条无效音讯会失常解决，Broker 也会持续运行。之后，你能够从死信队列中查看有效音讯，并依据须要疏忽或修复并重新处理。用户能够依据本人的需要来确定未确认的音讯是通过 TTL 的模式将其变为确认状态还是通过死信队列的形式来实现，根据的次要规范就是看你需不要解决生产不了的音讯。

启动 Producer 往 Broker 发送音讯，设置了 TTL，没有启动 Consumer，同时设置了 Retention 策略为半小时，达到 Retention 的阈值之后，发现设置 TTL 的音讯并没有被移除，这是为什么呢？

在上述场景中，有一个问题须要留神， 没有启动 Consumer，在下面咱们说到，TTL 是将音讯设置的 Cousor 向前挪动，如果没有启动 Consumer，相当于 Cousor 没有被初始化，也就是如果没有 Consumer，你就没有必要去设置 TTL。

我设置了 Retention 策略，然而达到了 Retention 的阈值，Topic 中的数据并没有被删除掉，这是为什么呢？

这个是 Pulsar 外部的一个实现机制，在 Pulsar 中 Topic 是一个逻辑的概念，一个 Topic 对应一个 manage ledger，当你写数据的时候，实际上是将数据写到了 ledger 中，还记得在之前很多文章中提到的无关 Pulsar 设计的一个外围所在： 在 Pulsar 中，所有的操作都是异步的 ，所以当 Retention 达到指定阈值之后，是否删除对应 ledger 中的数据，这个操作也是异步的。delete 的操作是不会对以后 active 的 ledger 执行的。只有当数据写满了以后的 ledger，ledger 产生切换时，才会去真正的执行 retention 策略。

如果想要强制执行，能够应用 pulsar-admin 将以后的 ledger 强制卸载，迫使其产生 ledger 的切换。

冉小龙，腾讯云微服务产品核心研发工程师，Apache Pulsar Committer，Apache BookKeeper Contributor

Pulsar namespace 策略浅析
Message Lifecycle：Pulsar 里的信息传递到底是什么样子
了解 Apache Pulsar 工作原理

点击链接获取 Apache Pulsar 硬核干货材料！

关于apache:博文推荐-一文带你看懂-Pulsar-的消息保留和过期策略

Retention 策略

Backlog

Time To Live（TTL）

TTL、Backlog 与 Retention 的区别和分割

TTL 与死信队列

应用问题

场景一

场景二

对于作者

相干举荐