引言

接口防刷是生產(chǎn)項(xiàng)目落地必須解決的問題，這篇文章會(huì)從架構(gòu)的角度，分層次的講講如何解決這個(gè)問題。

接口防刷（Rate Limiting / Anti-scraping）的核心在于“識(shí)別請(qǐng)求”和“限制頻率”

第一層：客戶端/前端層 (Client Side)

在client層我們并不能阻止真正的攻擊者，屬于“防君子不防小人”，主要目的是增加作弊成本，而不是徹底阻斷。

下面是在這一層常見的措施。

• UI 交互限制

  • 按鈕置灰：點(diǎn)擊發(fā)送后，按鈕強(qiáng)制置灰?guī)酌腌姡ǚ乐褂脩羰侄吨貜?fù)提交）。

• 圖形/行為驗(yàn)證碼 (CAPTCHA)

  • 在敏感接口（注冊(cè)、登錄、領(lǐng)券）引入滑塊、點(diǎn)擊選字或 Google ReCaptcha。
  • 邏輯：只有驗(yàn)證碼校驗(yàn)通過，才頒發(fā)一個(gè)臨時(shí)的 Token，后端接口校驗(yàn)該 Token。

• 參數(shù)簽名 (Signature) & 防重放

  • 機(jī)制：客戶端使用 AK/SK 對(duì)請(qǐng)求參數(shù) + 時(shí)間戳 + 隨機(jī)數(shù) (Nonce) 進(jìn)行簽名。
  • 作用：防止抓包篡改參數(shù)。
  • 防重放：后端校驗(yàn)時(shí)間戳（例如只允許 60s 內(nèi)的請(qǐng)求），并緩存 Nonce（60s 內(nèi)不能重復(fù)）。

第二層：網(wǎng)絡(luò)/網(wǎng)關(guān)接入層 (Network / Gateway)

在這一層我們一定要擋住絕大部分的異常流量，保護(hù)后端服務(wù)不被壓垮。

1. WAF (Web Application Firewall)

• 如果公司有預(yù)算，直接上對(duì)應(yīng)云服務(wù)廠商(比如阿里云/AWS) 的 WAF 或者 Cloudflare。它們能基于指紋庫識(shí)別惡意爬蟲、Bot 流量，直接在邊緣節(jié)點(diǎn)阻斷。

2.Nginx 反向代理層

• IP 限流 (limit_req_zone) ：這是最基礎(chǔ)的。

  # 定義限流空間，以 IP 為 key，限制每秒 10 個(gè)請(qǐng)求
  limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
  
  server {
      location /api/ {
          # 應(yīng)用限流，burst=5 允許瞬間突發(fā) 5 個(gè)，nodelay 立即處理
          limit_req zone=api_limit burst=5 nodelay;
      }
  }
  

• 黑名單機(jī)制：Nginx 可以直接 deny 某些惡意 IP 段。

3. API 網(wǎng)關(guān) (Gateway)

• 技術(shù)棧：Spring Cloud Gateway/Zuul，Kong, APISIX, Tyk，Higress。

• 策略：

  • 身份鑒權(quán)：在網(wǎng)關(guān)層校驗(yàn) Token (JWT)，無效請(qǐng)求直接丟棄，不透傳給后端。
  • 全局流控：基于令牌桶（Token Bucket）或漏桶（Leaky Bucket）算法，限制整個(gè)服務(wù)的 QPS 上限。

第三層：應(yīng)用/服務(wù)層 (Application / Middleware)

這里就是業(yè)務(wù)層來阻斷的地方了，可以針對(duì)某個(gè)業(yè)務(wù)進(jìn)行更加精細(xì)的限流操作。

1. 業(yè)務(wù)維度的限流 (Redis + Lua)

• 場景：限制某個(gè)用戶 (User_ID) 在特定時(shí)間窗口內(nèi)只能調(diào)用 N 次。

• 為什么用 Lua？ 保證 Redis 操作（讀+寫）的原子性。

• 滑動(dòng)窗口算法：比固定窗口更平滑，防止“臨界點(diǎn)突發(fā)”問題。

  • 示例邏輯：使用 Redis ZSET。Key 是 User_ID:Action，Score 是時(shí)間戳。每次請(qǐng)求移除窗口外的數(shù)據(jù)，統(tǒng)計(jì)窗口內(nèi)的數(shù)量。

2. 單機(jī)/集群限流組件

• Java 生態(tài)：

  • Guava RateLimiter：單機(jī)限流，基于令牌桶，適合非集群環(huán)境。
  • Alibaba Sentinel：神器。支持單機(jī)、集群、熱點(diǎn)參數(shù)限流（例如：防止某個(gè)熱點(diǎn)商品 ID 被刷），支持降級(jí)熔斷。

• Go 生態(tài)：

  • golang.org/x/time/rate：官方標(biāo)準(zhǔn)庫，基于令牌桶。
  • Uber-go/ratelimit：基于漏桶模型，更注重請(qǐng)求的均勻性。

3. 冪等性設(shè)計(jì) (Idempotency)

• 防止因?yàn)榫W(wǎng)絡(luò)抖動(dòng)或腳本重試導(dǎo)致的重復(fù)操作。
• 實(shí)現(xiàn)：客戶端生成唯一的 Request-ID，后端在攔截器和Redis中檢查該 ID 是否已處理過。

如果面對(duì)腳本，我們?cè)谶@一層一般有什么解決方法呢？

• 動(dòng)態(tài)風(fēng)控/黑名單

  • 分析用戶行為模型。如果一個(gè)用戶 24 小時(shí)都在請(qǐng)求接口，或者只搶紅包不看頁面，標(biāo)記為灰名單/黑名單。
  • Java/Go 處理：在 Filter/Middleware 中，檢查用戶 ID 是否在 Redis 的黑名單 Set 中，如果在，直接返回 403。

• 人機(jī)驗(yàn)證升級(jí)

  • 當(dāng)系統(tǒng)檢測到某用戶頻率稍高但不確定是否為攻擊時(shí)，不直接封禁，而是彈出驗(yàn)證碼。
  • 只有通過驗(yàn)證碼，才允許繼續(xù)操作。

第四層：數(shù)據(jù)持久層 (Database)

最后的兜底，防止數(shù)據(jù)錯(cuò)亂。

1. 數(shù)據(jù)庫唯一索引 (Unique Index)

   • 例如：防止用戶重復(fù)領(lǐng)取優(yōu)惠券，在 coupon_record 表對(duì) user_id + campaign_id 建唯一索引。

2. 悲觀鎖/樂觀鎖

   • 樂觀鎖：UPDATE account SET balance = balance - 100, version = version + 1 WHERE id = 1 AND version = old_version。防止并發(fā)扣減刷成負(fù)數(shù)。

總結(jié)

到此這篇關(guān)于一站式了解接口防刷(限流)的基本操作的文章就介紹到這了,更多相關(guān)接口防刷內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論