已采纳
回答正文
回复
讨论正文
该问题的正文与回答。
我先声明一个自问自答的坑:我之前发过一篇《灰度放量按 uid 尾号分桶:P99 虚高 220% 的复盘》(见引用),里面给出的修法是「请求级灰度 + 同用户对照」——即同一用户 50% 请求走新召回链路、50% 走旧链路,对比同一用户的新旧 P99,把用户结构差异扣掉。
服务形态:Java 17 无状态,双机房 8 副本,单副本 8C/16G,HikariCP 连接池 maximumPoolSize=30,本地 Caffeine 缓存(maximumSize=20w),下游 MySQL 主从 + 一个 ES 召回。新链路和旧链路在同一个 JVM 进程里共存,靠请求头 X-Gray-Routing 分流。
新链路召回更重:每次请求多打一次 ES、多查两张维度表,缓存命中率比旧链路低。放量 10% 观察时我发现一个反直觉读数:
机制我基本清楚:两条链路共享同一份 HikariCP 池和同一份 Caffeine,新链路的慢 SQL 占着连接、它的缓存 miss 冲刷 LRU,反过来抬高了旧链路的取连接等待和缓存未命中。
pending/active、Caffeine 的 eviction/miss、线程池 queueDepth,但不知道这些指标和「对照组被污染幅度」之间有没有可量化的关系,没法把 5ms 的污染拆出来。希望有人给过可落地的做法,具体到:
一句话:我把「同用户对照」当成干净实验,但它默认了新旧链路资源隔离——这个假设在同进程里根本不成立。想知道你们是怎么把这块「对照组不干净」的偏差量化掉、或者干脆隔离掉的。