作为互联网软件开发人员，你是不是也遇到过这种面试场景：

“如果你的接口被恶意狂刷，导致服务响应变慢、数据库崩溃，甚至产生巨额账单，你会怎么解决？”

许多人第一反应就是 “限流啊！”，但往往话没说完就被面试官追问：“只限流够吗？分布式场景下怎么防绕过？刷量行为怎么精准识别？”

实则，接口防恶意狂刷是后端面试的高频核心题，考察的不只是基础方案，更是你对 “全链路防御” 的理解和实战落地能力。今天咱们就从面试考点出发，把这个问题讲透，不管是面试答题还是项目落地，都能直接用！

接口被狂刷的危害，比你想象的更严重！

在实际开发中，接口被恶意狂刷的场景屡见不鲜：黑产批量注册账号、黄牛抢购商品、刷接口套取补贴、恶意攻击导致服务雪崩…… 这些行为带来的后果远超想象：

1. 资源耗尽：服务器 CPU、内存占用飙升，数据库连接池被占满，正常用户无法访问；
2. 成本暴增：短信接口被刷、云服务带宽超额，可能一天就产生数万甚至数十万的额外费用；
3. 数据污染：恶意提交的垃圾数据占用存储，影响业务数据分析和决策；
4. 用户体验崩塌：服务响应超时、订单提交失败，导致正常用户流失，品牌口碑受损。

而面试官之所以反复考察这个问题，正是由于它直接关系到系统的稳定性、安全性和成本控制，是后端开发的必备核心技能。

面试必背的 5 层防御体系，附实战代码！

要全面回答这个问题，不能只靠单一方案，必须搭建 “检测 – 防御 – 监控 – 复盘” 的全链路体系。以下 5 个核心方案，从基础到进阶，覆盖面试所有考点：

1. 基础防御：接口限流（面试必答，先拿基础分）

限流是防刷的第一道防线，核心思路是 “限制单位时间内的请求次数”。常用的限流算法有 3 种，面试时要说明每种算法的适用场景：

固定窗口限流：简单易实现，适合单机场景（如每分钟允许 100 次请求）；

// 单机固定窗口限流示例（Spring Boot）
@Component
public class FixedWindowRateLimiter {
    // 窗口大小（1分钟）
    private static final long WINDOW_SIZE = 60 * 1000;
    // 窗口内最大请求数
    private static final int MAX_REQUESTS = 100;
    // 记录每个IP的请求时间戳
    private Map<String, List<Long>> ipRequestMap = new ConcurrentHashMap<>();

    public boolean allowRequest(String ip) {
        long now = System.currentTimeMillis();
        ipRequestMap.computeIfAbsent(ip, k -> new ArrayList<>())
                .removeIf(time -> time < now - WINDOW_SIZE); // 清理过期请求
        List<Long> requests = ipRequestMap.get(ip);
        if (requests.size() < MAX_REQUESTS) {
            requests.add(now);
            return true;
        }
        return false;
    }
}

滑动窗口限流：解决固定窗口的 “临界问题”，适合对精度要求高的场景；

令牌桶限流：支持突发流量，适合接口峰值波动大的场景（如秒杀接口）。

2. 进阶防御：IP + 用户维度黑白名单（拦截恶意来源）

只限流不够，还要精准识别恶意来源。通过 IP 和用户 ID 双维度管控，拦截已知的恶意请求：

• 黑名单：收集恶意 IP（如频繁触发限流的 IP）、违规用户 ID，直接拒绝请求；
• 白名单：核心接口只允许内部服务、可信 IP 访问（如支付接口、管理接口）；
• 动态更新：结合监控系统，实时更新黑白名单，避免被绕过。

3. 核心防御：验证码 + 签名机制（防机器刷量）

对于注册、登录、短信发送等敏感接口，必须加入 “人机验证” 和 “请求合法性校验”：

• 验证码：图形验证码、短信验证码、滑动验证，拦截纯机器刷量；
• 请求签名：客户端请求时携带时间戳 + AppSecret + 签名，服务端验证签名有效性，防止请求被篡改或重复提交：

// 签名验证示例
public boolean verifySign(String timestamp, String appSecret, String sign, String params) {
    // 1. 校验时间戳（防止过期请求）
    long now = System.currentTimeMillis() / 1000;
    if (Math.abs(now - Long.parseLong(timestamp)) > 60) {
        return false;
    }
    // 2. 拼接参数+时间戳+AppSecret，生成签名
    String origin = params + timestamp + appSecret;
    String generateSign = DigestUtils.md5DigestAsHex(origin.getBytes());
    // 3. 对比签名
    return generateSign.equals(sign);
}

4. 分布式防御：Redis 集群限流（解决分布式部署问题）

单机限流在集群部署下会失效（恶意请求分散到不同机器），必须用 Redis 实现分布式限流：

• 利用 Redis 的INCR+EXPIRE实现原子性限流；
• 结合 Redis Cluster，支持高并发场景；

// Redis分布式限流示例（Spring Data Redis）
@Component
public class RedisRateLimiter {
    @Autowired
    private StringRedisTemplate redisTemplate;

    public boolean allowRequest(String ip, String interfaceKey, int maxRequests, long windowSeconds) {
        String key = "rate_limit:" + interfaceKey + ":" + ip;
        Long count = redisTemplate.opsForValue().increment(key, 1);
        if (count == 1) {
            redisTemplate.expire(key, windowSeconds, TimeUnit.SECONDS); // 第一次请求设置过期时间
        }
        return count <= maxRequests;
    }
}

5. 监控与复盘：日志 + 告警（及时发现并优化）

防刷不是一劳永逸的，必须有监控和复盘机制：

• 日志记录：记录所有限流、拦截请求的详细信息（IP、时间、接口、请求参数）；
• 实时告警：当接口请求量突增、限流次数超标时，通过短信、钉钉告警；
• 定期复盘：分析恶意请求的特征，优化限流规则、黑白名单和验证机制。

总结：面试答题模板 + 实战提议

面试答题模板（直接套用）：

“面对接口恶意狂刷，我会采用‘5 层全链路防御体系’：

1. 基础限流：用令牌桶算法控制接口 QPS，避免资源耗尽；
2. 来源管控：通过 IP + 用户黑白名单，拦截已知恶意来源；
3. 人机验证：敏感接口加入验证码 + 请求签名，防机器刷量；
4. 分布式适配：用 Redis 实现集群限流，解决分布式部署问题；
5. 监控复盘：记录日志 + 实时告警，定期优化防御规则。

同时，会根据接口类型（如公开接口、内部接口）调整防御策略，平衡安全性和用户体验。”

实战提议：

1. 不要过度设计：非核心接口用单机限流即可，核心接口再上全链路防御；
2. 避免性能瓶颈：限流和签名验证要尽量轻量化，Redis 集群要做好分片；
3. 预留应急方案：当遇到大规模攻击时，可临时关闭非核心接口，优先保障核心服务。

作为软件开发人员，系统稳定性是我们的核心职责，而接口防刷正是其中的关键一环。这篇文章的方案既覆盖了面试考点，也能直接落地到项目中，提议大家收藏转发，下次面试遇到类似问题，直接自信应答！

如果你的项目中遇到过特殊的接口防刷场景，或者有更好的方案，欢迎在评论区留言交流，咱们一起精进技术！