Dubbo 无法直接对 Redis 热点 Key 限流，因其不感知 Redis 层逻辑；需通过 @SentinelResource 透传参数，配合 Sentinel 热点规则、Redis 逻辑过期与分布式锁四层联动才能有效防护。
为什么 Dubbo 直接连 Redis 热点 Key 不行
Dubbo 本身不处理 Redis 层的缓存逻辑，它只管服务间 RPC 调用。所谓“Redis 热点服务调用”，实际是指：某个 Dubbo 接口（比如 getProductDetail(String productId)）内部查 Redis，而这个 productId 是热点，缓存过期瞬间大量请求穿透——这问题出在业务代码里，不是 Dubbo 能自动感知或拦截的。
直接在 Dubbo 层对 Redis Key 做限流会失效，因为：
- Dubbo 的
tps过滤器只统计接口整体 QPS，无法识别不同productId的访问频次差异 -
ExecuteLimitFilter控制的是并发线程数，对缓存击穿这种“同一 Key 大量串行请求打库”场景无感 - Redis 本身没把 Key 级别流量暴露给 Dubbo，两者不在同一观测平面
必须把热点参数透传到 Sentinel 或 AHAS
要实现“按 productId 限流”，得让限流组件知道你在调用哪个 Key。Dubbo 提供了天然埋点能力，但需要显式配合：
- 用
@SentinelResource注解标记方法，并确保参数顺序和索引明确（productId是第 0 个参数） - 在
SphU.entry()手动传参时，args必须是基本类型或 String；若传对象，Sentinel 无法提取字段值做热点判断 - AHAS 控制台配置热点规则时，“参数索引”填 0，“QPS 阈值”设为比如 100，“例外项”可加白名单如
"10001"（运营后台 ID）
示例关键代码：
@SentinelResource(value = "getProductDetail", blockHandler = "handleBlock")
public Product getProductDetail(String productId, int version) {
// productId 将作为热点参数被 Sentinel 统计
return cacheService.getFromRedis(productId);
}
Redis 层必须配逻辑过期 + 互斥锁兜底
仅靠 Dubbo 上游限流不够。一旦 Sentinel 拦截失败（比如误判、规则未生效），或者缓存刚重建完成又遭遇新一波请求，击穿仍会发生。所以 Redis 层必须有第二道防线：
- 缓存写入时存两个字段：
product:10001（真实数据） +product:10001:expire（时间戳，比 TTL 多延 2 分钟） - 读取时先检查
:expire字段是否过期；若已过期，用 Redisson 的RLock.tryLock(3, 10, TimeUnit.SECONDS)抢锁 - 抢到锁的线程异步重建缓存，其他线程返回旧值（允许短暂脏读）或降级兜底（如本地缓存）
注意：不要用 SETNX + DEL 组合实现锁，没有自动续期，Dubbo 接口超时（常见 3s）后锁可能提前释放，导致重复重建。
监控和压测验证不能跳过
线上配置完热点规则，不代表万事大吉。最容易被忽略的是验证环节：
- 用
curl -X POST http://localhost:8719/clusterNode?resource=your-resource-name查看 Sentinel 实时统计，确认hotItems列表里真有productId出现 - 压测时故意让缓存过期，观察数据库慢 SQL 是否归零、Redis
GET命中率是否回升到 99%+、Sentinel 控制台是否出现blockQps计数 - 如果
blockQps一直为 0，大概率是参数没传进去，或用了包装类（如Integer而非int），Sentinel 默认不支持
真正防住击穿，靠的不是某一个开关，而是 Dubbo 参数透传 + Sentinel 热点规则 + Redis 逻辑过期 + 分布式锁四层联动。少一层，都可能在凌晨三点收到告警电话。
