Node.js 短信 2FA OTP 限流架构实战：以身份交接为核心的防刷与成本控制体系

导语：短信 OTP 是 2FA 体系中最昂贵、最容易被滥用、也最容易被误判的一环。多数团队把限流写成「每个 IP 每分钟 N 次」的简单中间件，却在真实攻击与用户重发之间同时失守。真正有效的控制单元不是单纯的 HTTP 请求，而是接收者（手机号）与登录会话（Session）构成的身份交接对。本文以资深架构师视角，拆解 Node.js 服务中 OTP 限流的底层机制、原子性设计、渐进式退避策略与生产级落地实践。

一、技术演进背景与核心痛点

在短信 2FA 的工程实践中，限流长期被当作「网关层的一个计数器」处理。但随着攻击链路复杂化（多端登录、邀请机制、测试账号、灰度流量），这种粗粒度模型暴露了三类结构性痛点：

• 控制单元错配 (Wrong Unit of Control)：以 HTTP 请求或 IP 为键，无法区分「同一手机号跨多个会话的分布式刷取」与「同一会话内用户焦虑点重新发送」。前者是攻击，后者是体验问题，却共享同一个计数器，导致误杀与漏杀并存。
• 副作用顺序倒置 (Side-Effect Ordering)：许多实现先调用 POST /v1/sms/otp 再记录计数，一旦下游超时或重试，短信已经发出、账单已产生，限流形同虚设。SMS 调用必须是决策之后的最终副作用，而非决策的一部分。
• 无效接收者放大 (Invalid Recipient Amplification)：失败邀请、过期测试账号、已注销号码会持续触发发送与退信（bounce），把一次配置错误转化为长期账单与客服工单。缺少抑制名单（suppression list）使系统对「已知无效」毫无记忆。

二、底层架构与核心机制深度剖析

核心机制可归纳为一句话：双主键计数 + 原子判定 + 渐进退避 + 抑制前置 + 副作用后置。下面给出 Node.js 下的参考实现，采用 Redis 的 Lua 脚本保证「读-判-写」的原子性，避免高并发下的计数竞态：

// rateLimiter.js —— 双主键 OTP 限流核心
import Redis from 'ioredis';
const redis = new Redis(process.env.REDIS_URL);

// KEYS[1] = phone:{normalizedPhone}  KEYS[2] = session:{sessionId}
// ARGV[1] = phoneLimit  ARGV[2] = sessionLimit  ARGV[3] = windowSec  ARGV[4] = nowMs
const LUA_SCRIPT = `
local phoneKey, sessionKey = KEYS[1], KEYS[2]
local phoneLimit, sessionLimit = tonumber(ARGV[1]), tonumber(ARGV[2])
local window, now = tonumber(ARGV[3]), tonumber(ARGV[4])

local function bump(key, limit)
    local cnt = redis.call('INCR', key)
    if cnt == 1 then redis.call('EXPIRE', key, window) end
    if cnt > limit then return 0 end
    return 1
end

if bump(phoneKey, phoneLimit) == 0 then return {0, 'ERR_PHONE_LIMIT'} end
if bump(sessionKey, sessionLimit) == 0 then return {0, 'ERR_SESSION_LIMIT'} end
return {1, 'OK'}
`;

export async function checkRateLimit(phone, sessionId) {
    const res = await redis.eval(LUA_SCRIPT, 2, `otp:p:`, `otp:s:`, 5, 3, 300, Date.now());
    return { allowed: res[0] === 1, reason: res[1] };
}

三、生产环境架构决策与避坑指南