防刷策略怎么优化不影响性能？

本文目录导读：

1. 核心原则：将昂贵的计算尽量后移
2. 具体优化策略（按推荐优先级排列）
3. 关键性能杀手与避坑指南
4. 一个高性能防刷架构示例

这是一个非常经典且具有挑战性的问题。防刷的本质是增加攻击者的成本，而性能优化的本质是降低服务器的计算和I/O开销，两者天然存在矛盾，优化的核心思路是：分层过滤、前置阻断、异步处理、利用本地缓存和硬件能力。

下面从架构层级出发，给出具体可落地的优化方案，确保在准确拦截的同时,将性能损耗降到最低。

核心原则：将昂贵的计算尽量后移

1. 第一层（最便宜）：客户端与网络层—— 成本极低,拦截大部分低端攻击。
2. 第二层（较便宜）：反向代理与本地缓存层（如 Nginx + Lua/OpenResty）—— 高性能,无业务逻辑侵入。
3. 第三层（中等成本）：应用服务层（内存缓存 + 异步）—— 精细控制,但需优化。
4. 第四层（昂贵）：数据库/分布式锁—— 严格控制,但应作为最后防线。

具体优化策略（按推荐优先级排列）

第一层：客户端验证与CDN（几乎零性能开销）

在请求到达服务器之前就解决大部分问题。

• 前端人机验证（点选、滑块）：对高频刷接口（登录、下单）强制使用，服务器只需验证一个轻量级的Token,无需实时计算。
• 繁/简切换验证：对敏感操作要求输入图形验证码/短信验证码，成本在于第三方服务,而非自身服务器。
• CDN/WAF层防护：直接配置速率限制（如单IP每秒5次），拦截恶意IP、特征UA、空Referer等。
  • 优化点：CDN本身具备分布式抗压能力，请求会被CDN边缘节点拦截,根本不回源到你的服务器。

第二层：反向代理层本地计算（Nginx + Lua）

这是性能与防刷的最佳结合点，Nginx是事件驱动、异步非阻塞的,处理能力极高。

• 方案：使用OpenResty（集成Lua）在Nginx层面执行限流逻辑。
  • 本地计数器（单机版）：使用lua-resty-limit-traffic模块，利用共享内存字典（lua_shared_dict）做计数器，完全在内存中完成，没有网络I/O,适用于单机部署或LVS分发场景。
  • 滑动窗口+令牌桶：同样在Nginx层用Lua实现，对性能的影响通常小于1%。
• 优势：比应用层（Tomcat/Java Worker）处理快1-2个数量级,且不占用后端应用连接池。

第三层：应用层内存缓存与精细化逻辑

如果必须在应用层（如Java/Go）做判断，必须避免每次请求都访问Redis/DB。

• 布隆过滤器（Bloom Filter）：用于判断“是否是新用户/IP”。
  • 场景：一亿个黑名单IP，用HashSet存内存要几百MB，用布隆过滤器只需几十MB，且查询复杂度O(1)。
  • 代价：有误判率（会把好人当成坏人，但效率极高）。配合错判白名单使用即可。
• 本地缓存（Caffeine/Guava Cache） + 异步写回Redis：
  • 不能：每个请求都 incr Redis key，Redis QPS会爆炸。
  • 应该：在应用实例的内存中维护一个滑动时间窗口计数器（例如1秒内同一用户的请求次数），先判本地，超过阈值直接拦截，未超过则异步（如每秒批量刷一次）更新Redis集群的全局计数。
  • 优化点：大部分请求直接命中本地内存，性能损耗接近于0,只有极少数需要全局协调的请求才读Redis。
• 请求特征指纹（轻量级）：
  • 不要用复杂的用户画像、行为序列，用内存中的哈希表存储 {IP + UserAgent + 请求路径} 的MD5作为key,计数器过期后自动删除。

第四层：数据库端（最后防线）

数据库承担防刷的核心逻辑是最坏情况。

• 异步写：防刷判定通过后，结果异步写入数据库（使用消息队列）,不要把数据库写入放在请求链路上。
• 使用Redis集群：替代DB作为计数器底座，Redis单机QPS可达10万+，且支持Lua脚本保证原子性（EVAL命令）。
• 避免分布式锁：千万不要用 SETNX 做分布式锁来限制并发，这会瞬间拖垮Redis，用 Lua脚本实现原子递增+过期 即可（如 INCR key; EXPIRE key 60）。

关键性能杀手与避坑指南

一个高性能防刷架构示例

用户请求 -> 1. CDN/WAF层 (按IP限流) [几乎0成本]
    -> 拦截 99% 低端攻击
    |
    -> 2. OpenResty反向代理层 (本地内存计数器+令牌桶) [微秒级]
    |    - 用 lua_shared_dict 存 counter
    |    - 超过100次/秒直接返回503/429
    |    - 正常: 放行
    |
    -> 3. 应用服务层 (Caffeine本地缓存 + 业务逻辑 + 异步Redis)
    |    - 本地计数: 先查本地Map, 忽略或放行
    |    - 异步写回: 正常请求放行后, 异步更新Redis
    |    - Redis < 5000 QPS 时, 几乎无感
    |
    -> 4. 数据库 (控制写操作, 如限制同一用户每分钟订单数) [毫秒级]
         - 通过Redis透传, 最终写DB

最终结论： 防刷优化性能，不是“砍掉防刷”，而是“用最便宜的资源（Nginx内存、本地缓存）解决绝大部分问题，把昂贵的资源（Redis、DB）留给真正的业务流量”。 按照这个分层架构，你的防刷系统性能远高于业务系统自身,用户几乎感受不到其存在。

标签： 防刷策略