延迟双删的延迟时间怎么从「写死 500ms」改成跟着 MySQL 主从复制延迟动态调：你们线上有可复现的取数方法吗

背景

社区里对「双删 / 延迟双删 / MQ 失效」怎么选已经有不少讨论（见引用），我们线上也是「先更新 DB，再删 Redis」+ 延迟双删兜底，代码里延迟时间是一个写死的常量 500ms，注释写着「参考网上经验值」。

最近一次事故让我意识到这个数字经不起推敲：某天大促，主从复制延迟被大事务打到 2.3s，延迟双删的第二次删除在 500ms 就执行完了——结果从库还没追上主库，读请求打到从库读到旧值、回填缓存，脏窗口反而被「双删」合法化了一次。换句话说，延迟窗口小于复制延迟时，双删不但没兜住，还帮旧值又续了命。

所以我想把 500ms 改成动态值：延迟时间 = f(当前主从复制延迟 + 安全余量)。但卡在这个 f 怎么算、取数怎么取上。

现象 / 卡点

1. 复制延迟本身是抖动的：平时 0ms 上下，偶发尖峰到几百 ms 甚至秒级，固定 500ms 是「平时太大（白等）、尖峰时太小（兜不住）」两头不讨好。
2. 我想知道的「复制延迟」到底取哪个量：Seconds_Behind_Master（或 8.0 的 Seconds_Behind_Source）是瞬时值，读它和用它之间已经变了；要不要取近 N 秒的 P99/P999？N 取多大？
3. 安全余量加多少：除了复制延迟，链路里还有主库 binlog 写盘、网络、从库 apply 队列，这几段有没有可观测的量？还是只能拍一个「经验系数 × 延迟」？
4. 延迟双删的执行侧：如果延迟是动态的，第二次删除用什么调度（延迟队列 / timer 线程池 / MQ 延迟消息）？各自的坑是什么（timer 线程池满了延迟被吞、MQ 延迟消息精度粒度）？
5. 极端情况：复制延迟持续飙到 10s+ 时，延迟窗口跟不跟？还是直接放弃双删、把读切回主库 / 降级？

已尝试

• 查了 SHOW SLAVE STATUS / SHOW REPLICA STATUS 的 Seconds_Behind_Master，确认它只反映 SQL 线程 apply 的位点差，不含网络传输段；
• 用 binlog 位点差（Exec_Master_Log_Pos vs Read_Master_Log_Pos）粗估了网络段延迟，但没形成稳定的计算式；
• 想接 pt-heartbeat 实测端到端复制延迟，但还没在压测环境跑过基线。

期望得到的答案形态

1. 一个可复现的公式或决策流程：延迟时间 = 什么指标 + 什么余量，指标从哪取（SQL / pt-heartbeat / 自埋点），取多长窗口的什么分位；
2. 生产里真实用过的数字：你们的安全余量是固定 ms、固定倍数、还是分位数放大？大促 / 尖峰时怎么表现；
3. 第二次删除的调度选型与踩坑（延迟队列 vs timer vs MQ 延迟消息）；
4. 如果你们认为「动态延迟双删」本身就不如「binlog 驱动失效 / 读走主库」，也欢迎直接说，并给判据。

引用了社区两条相关讨论作为上下文，避免重复讨论「选哪种策略」，这次只聚焦「延迟窗口这个数怎么来」。