引言

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

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

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

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

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

• UI 交互限制

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

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

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

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

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

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

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

1. WAF (Web Application Firewall)

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

2.Nginx 反向代理層

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

  # 定義限流空間，以 IP 為 key，限制每秒 10 個請求
  limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
  
  server {
      location /api/ {
          # 應(yīng)用限流，burst=5 允許瞬間突發(fā) 5 個，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)層校驗 Token (JWT)，無效請求直接丟棄，不透傳給后端。
  • 全局流控：基于令牌桶（Token Bucket）或漏桶（Leaky Bucket）算法，限制整個服務(wù)的 QPS 上限。

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

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

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

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

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

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

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

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

• Java 生態(tài)：

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

• Go 生態(tài)：

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

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

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

如果面對腳本，我們在這一層一般有什么解決方法呢？

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

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

• 人機(jī)驗證升級

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

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

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

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

   • 例如：防止用戶重復(fù)領(lǐng)取優(yōu)惠券，在 coupon_record 表對 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)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論