这一篇文章是对 TurboLock 中涉及的 层级时间轮看门狗 模块的解析，为的是梳理思路增加理解。

一、这个模块解决了什么问题？

场景

痛点：分布式锁的 TTL 与业务执行时长不匹配。导致锁在业务尚未完成时自动失效，出现“抢锁”风险。话说回来，

分布式锁有一个致命漏洞：业务执行时间可能超过锁的 TTL。导致锁自动过期，另一个协程趁虚而入。

Leader 持锁 → TTL=8s → 业务执行了 9s → TTL 到期 → 另一个 Leader 也拿到了锁

解法是自动续期在 TTL 到期前，由程序自动向 Redis 发送 EXPIRE 刷新过期时间。

为什么不能「一锁一协程」？

痛点：为每把锁启动独立的 goroutine，会导致内存和调度开销爆炸。

go func {
for {
time.Sleep
redis.EXPIRE
}
}

每个 goroutine 最少占用 2KB 栈空间 + 一个 runtime.Timer 对象。当锁数量达到万级时内存和调度开销将不可接受。

时间轮的答案

痛点：Panic‑free、低内存、统一调度——只需要一个 goroutine + 一个 time.Ticker。用数据结构取代成千上万的 goroutine，把 O 的调度开销降到 O 的链表操作。

整个程序只用一个 goroutine + 一个 time.Ticker,管理所有锁的续期。

二、数据结构全景图

timingWheel
│
├── tick: 100ms
├── 单 goroutine 驱动
│
├── Level0 ← 主力，覆盖 ~0.6s
│ ├── cursor0: 当前指针位置
│ └── slots0: 每个槽位是一个双向链表头
│
├── Level1 ← 兜底，覆盖 ~0.3min
│ ├── cursor1
│ └── slots1
│
└── Level2 ← 极端兜底。覆盖 ~1h
├── cursor2
└── slots2

槽位内的链表结构

slots0
▼┌──────────┐ ┌──────────┐ ┌──────────┐
│ task A │───→│ task B │───→│ task C │
│ key="x" │←───│ key="y" │←───│ key="z" │
│ ticks=6 │ │ ticks=4 │ │ ticks=2 │
└──────────┘ └──────────┘ └──────────┘

每个 *timerTask 同时是“待续期的锁描述”和双向链表节点。

为什么是三层层级？

单层 slot × 100ms = 只能覆盖几秒。
如果续期间隔 = 60s，需要覆盖 600 个 slot → 单层不够 → 加一层 Level1。每槽 = 秒，槽数 = 分钟。如果续期间隔 = 小时 → 双层仍不够 → 再加一层 Level2。每槽 = 分钟，槽数 = 小时。说起来，实际使用中续期间隔 ≈ TTL/10 ≈ 0.6s。远小于 Level0 能覆盖范围，绝大多数任务只在 Level0；Level1/Level2 是极端配置下的安全气囊。

三、主要数据结构逐字段解读

taggerTask

type timerTask struct {
key string // Redis 锁的键名
callback func error // 续期函数
ticks int // 续期间隔 ÷ 100ms，如 .6s →
cancelled bool // 惰性删除标记
prev。next *timerTask // 双向链表指针
}