TTL核心概念：过期时间、存活时间、时间戳、时钟同步问题
聊TTL之前，我们先搞清楚几个基础概念。说实话，很多人在生产环境里踩坑，根源就是对这几个概念的理解不够透彻。我自己也曾经因为搞混了「过期时间」和「存活时间」，导致缓存雪崩，那叫一个惨。
过期时间 vs 存活时间
这两个词经常被混用，但在系统设计里，它们有本质区别。
| 概念 | 英文 | 含义 | 典型场景 |
|---|---|---|---|
| 过期时间 | Expiration Time | 一个时间点，到了这个点就失效 | Session过期、过期 |
| 存活时间 | Time To Live (TTL) | 一个相对时长，从创建或刷新开始计时 | DNS缓存、Redis Key过期 |
举个例子你就明白了。你买了一张电影票，上面写着「2025年3月15日 19:30 失效」——这就是过期时间，一个固定的时间戳。而你买了一杯奶茶，店员说「这杯最好在2小时内喝完」——这就是存活时间，从你拿到奶茶那一刻开始倒计时。
核心区别：过期时间是时间点，存活时间是相对时长。前者依赖时钟，后者依赖计时器。
我在项目中遇到过一个问题：某个服务用Redis存用户登录态，设置的是TTL=3600秒。但用户每次操作都会刷新这个TTL。结果呢？用户登录后一直活跃，TTL不断被重置，理论上永远不会过期。但有一天凌晨，所有用户突然全部掉线了。查了半天才发现，是Redis集群的时钟出现了漂移，导致某些节点认为Key已经过期了。嗯，这就是时钟同步问题。
时间戳：时间 vs 相对时间
实现TTL机制时，底层有两种记录方式。
- 时间戳：记录过期的时间点，比如
expire_at = 1710000000。每次判断时，拿当前时间跟这个值比较。 - 相对时间戳：记录创建时间和TTL时长，比如
created_at = 1709996400, ttl = 3600。判断时计算created_at + ttl > now。
你想想看，哪种方式更好？
时间戳的优点是判断快，一次比较就行。缺点是一旦设置好，就不能轻易调整。相对时间戳更灵活，可以动态修改TTL，但每次判断都要做一次加法运算。
Redis内部用的是时间戳。当你执行 EXPIRE key 3600 时，Redis会立刻计算出过期时间点，存到Key的元数据里。这样做的好处是过期检查效率高——每秒扫描一次，直接比较时间戳就行。
我的建议：如果你自己实现TTL机制，优先用时间戳。原因很简单——减少计算开销，而且避免时钟漂移带来的累积误差。当然，前提是你的系统时钟是可靠的。
时钟同步问题：分布式系统的阿喀琉斯之踵
说到时钟，就不得不提分布式系统里最头疼的问题——时钟同步。
为什么会这样？因为每台机器的物理时钟都不一样。即使你用了NTP（网络时间协议），机器之间的时间差也可能在毫秒到秒级别。在某些极端情况下，甚至可能差几分钟。
我给大家画一张图，看看时钟不同步会带来什么后果。
看到没？同样的TTL设置，在不同节点上产生的实际过期时间可能相差几十秒。这在某些场景下是致命的。
我曾经踩过的坑：在一个分布式锁的实现里，我用Redis的TTL来做锁的自动释放。结果因为集群中两台机器的时钟差了2秒，导致锁提前释放，多个客户端同时拿到了锁，数据写入了脏数据。从那以后，我所有涉及TTL的分布式系统，都会强制要求NTP同步，并且把时钟偏差纳入TTL的冗余设计里。
如何应对时钟同步问题
既然时钟同步不可避免，那我们能做什么？
- 强制NTP同步：所有节点配置NTP服务，定期同步。这是基础，不做不行。
- 引入时钟冗余：设置TTL时，留出一定的缓冲时间。比如你希望Key在3600秒后过期，可以设置成3500秒，提前释放，避免时钟偏差导致的问题。
- 使用逻辑时钟：在分布式系统中，可以考虑用逻辑时钟（如Lamport时钟、向量时钟）替代物理时钟。但实现复杂度较高，一般用在强一致性场景。
- 中心化时间服务：所有节点从同一个时间服务获取时间，比如Google的TrueTime API。但说实话，大部分公司没这个条件。
我的习惯：在微服务架构里，我会在网关层统一注入一个时间戳，所有下游服务都用这个时间戳来判断TTL。虽然会增加一点网络开销，但能彻底避免时钟不同步的问题。当然，这需要业务方配合改造。
小结
TTL的核心概念其实不复杂，但每个细节都可能成为生产事故的导火索。过期时间和存活时间要分清楚，时间戳的选择要考虑性能，时钟同步问题更是分布式系统的必修课。
记住一句话：在分布式系统里，永远不要相信时钟。做好冗余，做好监控，才能在TTL这条路上走得稳。