Sentinel热点参数限流与系统自适应保护均基于实时统计、动态规则和滑动窗口实现：前者针对高频参数值精准限流，需配置paramParser和sentinel-parameter-flow-control模块；后者依据CPU/Load/RT等指标动态调控QPS，自动触发保护并快速失败。
Sentinel 的热点参数限流和系统自适应保护，核心是通过 实时统计 + 动态规则 + 滑动窗口 实现的，不是靠静态阈值硬拦，而是感知真实流量特征与系统水位后智能干预。
热点参数限流：只对高频调用的参数值限流
它解决的是“某几个用户 ID、商品 ID 或接口参数值被高频刷”，而其他参数正常的问题。Sentinel 不是对整个接口限流，而是识别出“热值”并单独控制。
-
依赖参数解析器：需在 @SentinelResource 注解中指定
paramParser，或通过 SphU.entry() 手动传入具体参数值（如 user_id=1001）；Sentinel 会按参数类型+值做聚合统计 - 滑动时间窗口统计：默认 1 秒分 2 个格子（500ms 一格），持续统计每个参数值的 QPS；窗口滚动更新，保证数据新鲜
- 支持高级配置：可为不同参数值设置不同阈值（如 VIP 用户限流阈值更高）、支持参数索引定位（第 0 个参数是 userId）、支持例外项（某些值永远不触发限流）
-
注意点：热点规则需在控制台或 Nacos 动态配置，且应用必须引入
sentinel-parameter-flow-control模块；参数值不能是 null 或未解析成功，否则归入“UNKNOWN”组统一限流
系统自适应保护：根据系统负载自动调节入口流量
它不依赖人工预设 QPS，而是盯住 CPU 使用率、Load、平均 RT、入口 QPS、并发线程数这 5 个指标，用“慢启动 + 自适应降级”防止雪崩。
- 核心判据是 CPU 利用率：当 CPU ≥ 阈值（默认 100，即 100%），触发保护；也可关闭 CPU 判据，改用 Load（Linux）或 RT 上升趋势作为主要依据
-
动态计算允许通过的 QPS：公式类似
maxQps × min(1, CPU_occupy / 100)，CPU 越高，放行流量越少；RT 飙升时也会主动压低入口 QPS -
拒绝策略是“快速失败”：超出系统承受能力的请求，直接抛
SystemBlockException，不排队不等待，避免线程堆积 -
无需手动配规则：系统规则全局生效，只需在代码中开启（
SystemRuleManager.loadRules(...)）或通过控制台配置阈值；适合微服务集群中统一兜底
实际使用建议
- 热点限流适合「读多写少 + 参数差异大」场景，比如秒杀商品 ID、查询用户资料的 userId；别滥用在全量参数上，会增加统计开销
- 系统保护建议配合监控一起用：把 CPU、Load、RT 曲线和 Sentinel 的 block 数打到 Grafana，便于判断是真过载还是误触发
- 两类机制可叠加：先用系统保护兜底防雪崩，再用热点限流精准打击恶意调用；但注意系统规则优先级高于热点规则
- 本地测试时，CPU 利用率可能不准（Docker 或 Mac 虚拟化限制），建议用 Load 或 RT 指标验证系统保护逻辑
不复杂但容易忽略：所有规则都依赖 Sentinel 的 StatisticSlot 做实时采样，务必确认埋点已生效（SphU.entry 或 @SentinelResource 正确使用），否则统计为空，限流就形同虚设。
立即学习“Java免费学习笔记（深入）”；
