Apache Pulsar 消息保留（Retention）
背景
全文全摘自博文推荐 | 一文带你看懂 Pulsar 的消息保留和过期策略
有些话，第一次看时没看明白，后面在看了几次之后按自己的理解复制了一遍
介绍
默认情况下，Pulsar Broker 会对消息做如下处理：
- 当消息被 Consumer 确认之后，会立即执行删除操作。
- 对于未被确认的消息会存储到 backlog 中。
有时默认行为并不能满足生产需求，因此Pulsar提供了如下配置策略来覆盖这些行为：
- Retention策略: 用户可以将 Consumer 已经确认的消息保留下来。
- TTL 策略: 对于未确认的消息，用户可以通过设置 TTL 来使未确认的消息到达已经确认的状态。
上述两种策略的设置都是在 NameSpace 的级别进行设置。
Retention 策略
Retention 策略的设置提供了两种方式
- 消息的大小，默认值：
defaultRetentionSizeInMB=0 - 消息被保存的时间，默认值：
defaultRetentionTimeInMinutes=0
可以在 broker.conf 中对这两项内容进行配置，也支持通过命令行的配置
Backlog
backlog 是未被确认消息的集合，有个前提是backlog是针对持久化的topic（有非持久化的topic）
Pulsar Broker 会将所有未确认或者未处理的消息都存放到 backlog 中。
同样的，可以在 NameSpace 级别对 backlog 的大小进行配置。
需要注意的是，对 backlog 进行配置时，需要明确以下两点：
- 在当前的 NameSpace 下，每一个 Topic 允许的backlog大小是多少
- 如果超过设定的 backlog 的阈值，将会执行哪些操作
当超过设定的 backlog 的阈值，Pulsar 提供了以下三种策略供用户选择：
| Policy | Action |
|---|---|
| producer_request_hold | Broker会继续提供服务，但是对于之后未确认的消息不做持久化操作 |
| producer_exception | Broker会抛出异常，断开与produce的连接 |
| consumer_backlog_eviction | Broker会删除backlog中之前的积压的消息 |
Time To Live （TTL）
默认情况下，Pulsar 会持久化所有未被确认的消息。如果未被确认的消息有很多，这种策略会造成大量的消息被积压，导致磁盘空间增大。
可以通过设置 TTL 使得未被确认的消息进入到被确认的状态，当超过设定的 TTL 时间之后，配合相应的 Retention 策略将消息丢弃。
TTL 的一个典型使用场景是，当 Consumer 由于某些原因出现故障，不能正常消费消息，这时 Producer 还在不断的往 Topic 中生产消息，会造成 Topic 中有大量的未确认的消息出现，这时你可以通过设置 TTL 将这些未确认的消息变为已确认的状态。
TTL、Backlog 与 Retention 的区别和联系
可以发现，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 是当消息处于被确认的状态时，可以对已确认的消息进行的相应的保留策略
参考链接