本文介绍一种基于应用层逻辑的轻量级方案，通过动态更新文档 ttl 实现双重过期控制：既保证数据最长存活 90 天，又自动清除连续 30 天未被访问的冷数据，无需额外监控或扫描。
本文介绍一种基于应用层逻辑的轻量级方案，通过动态更新文档 ttl 实现双重过期控制：既保证数据最长存活 90 天，又自动清除连续 30 天未被访问的冷数据，无需额外监控或扫描。
在 Couchbase 中，单个文档仅支持一个 expiry（TTL）字段，原生不支持“创建后 90 天强制删除”与“最后访问后 30 天自动淘汰”并存的双维度过期机制。但可通过应用层协同设计，巧妙复用 TTL 字段实现等效效果——核心思想是：将 TTL 视为“绝对过期时间戳”，而非固定时长，并在每次读/写操作中动态刷新。
✅ 推荐实现方案（双阶段 TTL 模拟）
-
初始化文档时：
- 写入业务数据的同时，添加 created_at 时间戳（如 ISO 8601 格式或 Unix 毫秒时间戳）；
- 设置初始 TTL 为 当前时间 + 30 天（即首次过期窗口），确保闲置文档在 30 天后自动被后台进程清理。
-
每次读取或更新文档时（关键步骤）：
- 查询当前文档，获取其 created_at 字段；
- 计算新 TTL 值：created_at + 90 天（即该文档最长生命周期终点）；
- 使用 upsert() 或 replace() 并显式传入 expiry 参数（单位：秒或毫秒，取决于 SDK），覆盖原有 TTL。
# 示例：Python SDK（couchbase 4.0+）实现动态 TTL 刷新
from couchbase.options import UpsertOptions
from datetime import datetime, timedelta
def upsert_with_refreshed_ttl(collection, key, doc_data, created_at=None):
now = datetime.now()
# 若为新建文档，设置 created_at；否则复用已有值
if created_at is None:
created_at = now
# 最长存活至 created_at + 90 days
max_expiry = created_at + timedelta(days=90)
ttl_seconds = int((max_expiry - now).total_seconds())
# 执行 upsert 并设置 TTL
collection.upsert(
key,
{**doc_data, "created_at": created_at.isoformat()},
UpsertOptions(expiry=ttl_seconds)
)? 为什么有效？
- 未被访问的文档：初始 TTL 30 天到期后即被自动删除；
- 被访问的文档：每次访问都重置 TTL 为 created_at + 90天，因此只要在 90 天内至少访问一次，就能延续生命周期；
- 即使某次访问发生在第 85 天，TTL 仍会设为 created_at + 90天（即剩余 5 天），而非 now + 30天，从而严格保障“最长 90 天”的硬性约束。
⚠️ 注意事项与最佳实践
- 避免竞态条件：若高并发下频繁读写同一 Key，建议在 get-and-touch（如 SDK 支持）或原子 lookup_in + mutate_in 操作中完成时间戳读取与 TTL 更新，减少往返开销与不一致风险；
- 时钟一致性：确保应用服务器与 Couchbase 集群系统时间偏差
- TTL 精度限制：Couchbase TTL 最小单位为秒，毫秒级精度不可靠；
- 监控验证：可通过 cbstats 或 Couchbase Web Console 的 Data Buckets → Active Docs 查看平均 TTL 分布，辅助评估策略有效性；
- 冷热分离进阶：若业务规模持续增长，可结合 N1QL 定期分析 meta().expiration 字段分布，识别长期未刷新的 Key 模式，为后续分片或归档策略提供依据。
该方案零依赖外部组件、无性能侵入、完全兼容 Couchbase 原生 TTL 清理机制，是处理百万级键中“低频访问冷数据”问题的高效、可靠且生产就绪的实践路径。
