风控场景下如何设计超高并发频次计算服务？

原创文章，转载请标注。https://www.cnblogs.com/boycelee/p/19426008 架构师视角系列文章 《【架构师系列】风控场景下的配置中心设计思考》 https://www.cnblogs.com/boycelee/p/18355942 《【架构师系列】风控场景下超高并发频次计算服务的设计与实践》https://www.cnblogs.com/boycelee/p/19426008 目录架构师视角系列文章声明1、背景2、频次定义3、技术选型3.1、选择 Flink + Redis 还是 Java + Redis？选型对比3.2、为什么最终选择 Java + Redis，而不是 Flink + Redis？3.2.1、核心瓶颈是“热点 + ops/request”，不是“聚合能力不足”3.2.2、在热 Key 工程化做扎实的前提下，简单频次更偏向 Java + Redis3.3、选择“实时”频次计算还是“准实时”频次计算？3.3.1、实时频次3.3.2、准实时频次准实时频次4、系统设计4.1、难点4.2、思考4.2.1、思考清楚是否需要实时频次？4.2.2、为什么不需要实时频次？（1）技术角度：5ms 的确定性收益很低（2）业务角度：窗口统计下，5ms vs 50ms对识别率影响有限4.3、系统设计4.3.1、选择 Java + Redis 方案的难点如何解决？4.3.2 、从“同步读写”到“同步读、异步写”4.3.3、热 Key：探测 + 本地累加 + 批量写入（把“读写都热”变成“读热为主”）4.3.3.1、为什么常规手段不灵？4.3.3.2、为什么选“热 Key 动态探测”？4.3.3.3、核心机制：热 Key 本地累加 + 固定周期批量刷写4.3.3.4、本地缓存读结果4.4、存储设计4.4.1、统计窗口类型：为什么选择“滚动窗口”而不是“滑动窗口”？4.4.1.1、窗口策略的局限性4.4.1.2、频次策略的应用（解决）4.4.1.3、多维度的综合拦截策略4.4.2、存储结构设计5、整体架构7、总结8、最后 声明 原创文章，转载请标注。https://www.cnblogs.com/boycelee/p/19426008 1、背景 在风控体系里，频次计算几乎是绕不开的基础设施。尤其在流量风控/反爬场景，系统往往需要承接百万到千万级 QPS 的请求，并在固定窗口内基于“计数、比值、组合规则”做策略判定。 当业务进入 超高并发 + 指标爆炸 + 维度组合复杂 的阶段，频次系统通常会被三股力量同时拉扯： 链路时延预算被极度压缩：上游网关给流量安全底座分配总时延预算，底座为了保证自身稳定性，会继续压缩下游频次服务的时间（常见只剩 5ms 级别）。 指标与维度呈指数膨胀：从 10+ 指标增长到 100+；从单维（账号/IP）演进到多维组合（账号+设备+IP+接口+场景…），Key 空间随之快速膨胀。 热 Key 叠加“读写都热”：热点接口与热点资源会天然产生热 key，导致单分片 OPS 飙升、负载极不均匀，最终表现为尾延迟抖动；在这种模式下，简单“加机器/加分片”很难带来线性收益。 因此，频次系统的核心矛盾往往不是“算不算得动”，而是被迫在同一时间解决：尾延迟、扩展性、稳定性。 当你看到 P50 还不错但 P99/P999 明显飙升、并开始出现超时与失败时，本质上就是系统已经被“共享状态存储 + 热点 + 放大效应”拖进了高并发频次系统的典型瓶颈区间。 那么问题就变成：在这种极限约束下，频次系统应该怎么设计，才能既能跑得快、又能扩得开、还能稳得住？ 2、频次定义 频次统计本质上是在某个窗口内，对某个场景下、某个资源的请求进行计数或比值计算。 举例说明 在特定时间段内（如 10分钟、1 小时、1天），统计特定场景（如某个接口）下，特定资源（如账号、设备、IP）的请求数量，例如： 在 search 接口中，统计账号为 wangwu123 的一小时访问量（累加指标）。 在 search 接口中，统计 ip=192.0.0.1 且账号为空 的一小时请求量 与 统计 ip=192.0.0.1 的一小时请求量的比值（占比指标）。 这类需求的计算形式通常是 “ 简单Counter + 少量组合”，在在线链路中最关注“低延迟可用”，而不是复杂流式语义。