Pulsar 持久化策略与分层存储详解

在 Apache Pulsar 中，持久化策略与分层存储 是实现 长期数据保留、成本优化、资源控制 的核心机制。通过合理配置 保留策略（Retention）、积压策略（Backlog Quota） 和 分层存储（Tiered Storage / Offload），你可以在保证数据可用性的前提下，有效管理存储资源、防止磁盘打满、降低总体拥有成本。

---

📘 Pulsar 持久化策略与分层存储详解

---

一、保留策略（Retention Policy）

1. 什么是保留策略？

• Retention 定义了消息在被所有订阅消费后，仍然在系统中保留的时间或空间上限。
• 即使消息已被消费，仍可被重新读取（如用于调试、重放、审计）。

✅ 类比：Kafka 的 log.retention.hours，但 Pulsar 更精细。

---

2. 配置方式

通过 pulsar-admin 为 命名空间（Namespace） 设置：

pulsar-admin namespaces set-retention my-tenant/my-namespace \
  --time 72h \
  --size 10G

参数	说明
--time	消息最大保留时间（如 72h、7d）
--size	消息最大保留字节数（如 10G）

⚠️ 任一条件满足即触发删除。

---

3. 适用场景

场景	配置建议
日志分析	--time 7d
金融交易审计	--time 7y
实时监控	--time 24h
测试环境	--time 1h --size 1G

---

4. 工作机制

• 每个订阅维护一个 消费游标（Cursor）。
• 当所有订阅的游标都超过某条消息时，该消息进入“可删除”状态。
• Broker 后台任务定期扫描并删除超出保留策略的消息。

✅ 消费者仍可通过 reset-cursor 重放已保留的消息。

---

二、积压策略（Backlog Quota）

1. 什么是积压（Backlog）？

• Backlog 是指某个订阅中 已接收但未确认（unacked） 的消息数量。
• 如果消费者处理慢或宕机，Backlog 会持续增长，占用 Bookie 磁盘。

⚠️ Backlog 过大会导致磁盘耗尽、Broker OOM。

---

2. 积压配额（Backlog Quota）

用于限制单个订阅的 backlog 上限。

配置命令：

pulsar-admin namespaces set-backlog-quota my-tenant/my-namespace \
  --limit 5G \
  --policy producer_request_hold

参数	说明
--limit	最大 backlog 大小（字节）
--policy	达到上限后的处理策略

---

3. 积压策略（Policy）详解

策略	说明	适用场景
producer_request_hold	生产者阻塞等待，直到 backlog 降低	✅ 推荐：保护系统
producer_exception	生产者抛异常（TopicBusyException）	要求快速失败
consumer_backlog_eviction	删除最老的未确认消息（FIFO）	防止磁盘打满，允许丢失

✅ 推荐生产环境使用 producer_request_hold，避免数据丢失。

---

4. 工作流程

消费者处理慢
   ↓
Backlog 增长
   ↓
达到 backlogQuota.limit
   ↓
触发 policy：
   ├─ hold → 生产者暂停
   ├─ exception → 生产者失败
   └─ eviction → 删除老消息

---

5. 监控与调优

# 查看订阅 backlog
pulsar-admin topics stats my-topic --subscription sub1

# 输出示例
"subscriptions": {
  "sub1": {
    "msgBacklog": 100000,
    "msgRateOut": 100,
    "msgRateRedeliver": 0
  }
}

✅ 建议：监控 msgBacklog，设置告警。

---

三、分层存储（Tiered Storage / Offload）

1. 什么是分层存储？

• 分层存储（Tiered Storage） 是将 Pulsar 中的“冷数据”（旧 Ledger）从本地 Bookie 存储 卸载（offload） 到低成本对象存储（如 S3、GCS、HDFS）的过程。
• 本地磁盘只保留“热数据”，实现 存储成本优化。

✅ 类比：数据库的“冷热分离”或 Kafka 的 Tiered Storage。

---

2. 支持的 Offload 存储介质

存储类型	插件名称	说明
AWS S3	S3ManagedLedgerOffloader	最常用
Google Cloud Storage (GCS)	GCSOffloader	GCP 用户
Azure Blob Storage	AzureBlobStorageOffloader	Azure 用户
HDFS	HDFS2Offloader	大数据生态集成
Aliyun OSS	OSSManagedLedgerOffloader	阿里云用户
FileSystem	FileManagedLedgerOffloader	本地 NAS（测试用）

✅ 插件位于 offloaders/ 目录下，需单独下载。

---

3. Offload 触发条件

(1) 自动触发（推荐）

通过配置 broker.conf：

# 启用 Offload
managedLedgerOffloadEnabled=true

# 达到此大小时触发 offload（如 1GB）
managedLedgerOffloadThreshold=1073741824

# Ledger 关闭后延迟删除本地数据（24小时）
managedLedgerOffloadDeletionLagMs=86400000

✅ 当 Ledger 关闭 且 大小 ≥ threshold 时触发。

(2) 手动触发

# 手动卸载某个 Topic
pulsar-admin topics offload persistent://my-tenant/my-namespace/my-topic

# 查看卸载状态
pulsar-admin topics offload-status persistent://my-tenant/my-namespace/my-topic

---

4. Offload 工作流程

1. Broker 检测到 Ledger 可归档
   ↓
2. 将 Ledger 打包上传至 S3/GCS
   ↓
3. 更新 Ledger 元数据（ZooKeeper）
   ↓
4. Bookie 的 GC 可删除本地文件
   ↓
5. 消费者读取时：
   ├─ 若在本地 → 正常读取
   └─ 若已归档 → Broker 从云存储拉回

✅ 对消费者透明，无需修改代码。

---

5. Offload 配置示例（S3）

# broker.conf
managedLedgerOffloadDriver=s3
s3ManagedLedgerOffloadBucket=my-pulsar-archive
s3ManagedLedgerOffloadRegion=us-west-2
s3ManagedLedgerOffloadMaxBlockSizeInBytes=67108864  # 64MB
s3ManagedLedgerOffloadReadBufferSizeInBytes=1048576  # 1MB

# 认证
s3ManagedLedgerOffloadAccessKey=your-access-key
s3ManagedLedgerOffloadSecretKey=your-secret-key
# 或使用 IAM Role
# s3ManagedLedgerOffloadUseIAMRole=true

---

6. Offload 的优势与挑战

优势	说明
✅ 降低成本	本地 SSD → 云存储，成本降低 5~10 倍
✅ 无限保留	满足合规与审计需求
✅ 释放磁盘	防止 Bookie 磁盘打满
✅ 解决碎片问题	归档后 Entry Log 可被 GC 回收

挑战	解决方案
❌ 首次读取延迟高	启用缓存或预加载
❌ 网络带宽消耗	限速、错峰 offload
❌ 权限与安全	使用 KMS 加密、IAM 精细控制

---

四、三大策略协同工作图解

[消息写入]
   ↓
Ledger-100 (Open)
   ↓
消费者消费部分消息
   ↓
Backlog 增长 → 受 backlogQuota 限制
   ↓
Ledger-100 关闭（达到大小/时间）
   ↓
→ 是否 ≥ offloadThreshold?
   ├─ 是 → 卸载到 S3
   └─ 否 → 等待
   ↓
所有订阅消费完毕
   ↓
→ 是否超出 retention?
   ├─ 是 → 删除（本地或云存储）
   └─ 否 → 继续保留

---

五、最佳实践建议

策略	建议
Retention	根据业务需求设置，金融类建议 7 年
Backlog Quota	设置 5G ~ 10G，策略用 producer_request_hold
Offload	生产环境必开，目标存储用 S3/GCS
监控	重点监控 backlog、disk_usage、offload_status
告警	backlog > 100万、disk > 80%、offload 失败
测试	模拟消费者宕机，验证 backlog 策略

---

✅ 总结

策略	作用	配置层级
Retention	控制已消费消息的保留时间	Namespace
Backlog Quota	控制未确认消息的积压上限	Namespace
Offload	将冷数据迁移到低成本存储	Namespace / Broker

📌 一句话总结：

Retention 管“已消费”，Backlog 管“未确认”，Offload 管“冷数据” —— 三者协同，构建一个低成本、高可靠、可审计的 Pulsar 持久化体系。