高并发场景下如何优雅实现分布式限流？架构师实战经验分享

在高并发系统中，分布式限流是一项至关重要的技术，用于防止系统被突发的流量冲击而崩溃。想象一下，秒杀活动期间，大量用户涌入，如果不对流量进行控制，数据库可能直接宕机，导致整个服务不可用。这就是我们需要分布式限流的根本原因。

问题场景重现：秒杀活动流量洪峰

假设我们正在构建一个电商系统的秒杀功能。在秒杀开始前，我们预估会有百万级的用户同时涌入。如果没有合适的限流策略，将会出现以下问题：

• 数据库连接耗尽：大量请求直接打到数据库，导致数据库连接池耗尽，服务响应缓慢甚至无法响应。
• 服务器 CPU 飙升：服务器需要处理大量的请求，CPU 占用率迅速上升，影响其他服务的正常运行。
• 服务雪崩：一个服务的崩溃会引起依赖服务的崩溃，最终导致整个系统雪崩。

底层原理深度剖析：常见的限流算法

为了解决上述问题，我们需要了解一些常见的限流算法：

1. 令牌桶算法 (Token Bucket)

令牌桶算法以恒定的速率向桶中放入令牌，每个请求需要从桶中获取一个令牌，如果桶中没有令牌，则拒绝请求。该算法允许一定程度的突发流量。

2. 漏桶算法 (Leaky Bucket)

漏桶算法以恒定的速率从桶中漏出请求，流入的请求首先进入桶中，如果桶满了，则丢弃请求。该算法可以平滑流量，防止突发流量。

3. 滑动窗口算法 (Sliding Window)

滑动窗口算法将时间划分为多个窗口，统计每个窗口内的请求数量，如果请求数量超过阈值，则拒绝请求。该算法可以精确地控制每个时间窗口内的请求数量。

分布式限流方案选型

在分布式环境中，我们需要选择合适的限流方案。常见的方案包括：

• Redis + Lua 脚本：利用 Redis 的高性能和 Lua 脚本的原子性实现分布式限流。这种方案适用于对性能要求较高的场景。
• Guava RateLimiter：Google Guava 提供的 RateLimiter 可以方便地实现单机限流，但需要结合 Redis 等分布式缓存实现分布式限流。适用于简单的限流场景。
• Sentinel/Hystrix：阿里巴巴开源的 Sentinel 和 Netflix 开源的 Hystrix 提供了熔断、降级、限流等功能，可以作为分布式系统的流量控制解决方案。适用于复杂的微服务架构。

代码/配置解决方案：Redis + Lua 实现分布式限流

这里我们以 Redis + Lua 脚本为例，演示如何实现一个简单的分布式限流器。

-- KEYS[1]: 令牌桶的 key
-- ARGV[1]: 令牌桶的容量
-- ARGV[2]: 请求的令牌数量 (通常为 1)
local bucket = redis.call('get', KEYS[1])
if bucket == false then
  bucket = ARGV[1]
end

local tokens = tonumber(ARGV[2])
local remaining = tonumber(bucket)

if remaining < tokens then
  return 0 -- 拒绝请求
end

remaining = remaining - tokens
redis.call('set', KEYS[1], remaining)
return 1 -- 允许请求

// Java 代码示例
String luaScript = "-- KEYS[1]: 令牌桶的 key\n" +
                "-- ARGV[1]: 令牌桶的容量\n" +
                "-- ARGV[2]: 请求的令牌数量 (通常为 1)\n" +
                "local bucket = redis.call('get', KEYS[1])\n" +
                "if bucket == false then\n" +
                "  bucket = ARGV[1]\n" +
                "end\n" +
                "local tokens = tonumber(ARGV[2])\n" +
                "local remaining = tonumber(bucket)\n" +
                "if remaining < tokens then\n" +
                "  return 0 -- 拒绝请求\n" +
                "end\n" +
                "remaining = remaining - tokens\n" +
                "redis.call('set', KEYS[1], remaining)\n" +
                "return 1 -- 允许请求\n";

// 使用 Jedis 或 Lettuce 执行 Lua 脚本
Jedis jedis = new Jedis("localhost", 6379);
Object result = jedis.eval(luaScript, 1, "rate_limit_key", "100", "1"); // 令牌桶容量为 100，每次请求消耗 1 个令牌
jedis.close();

if (result != null && result.equals(1L)) {
  // 允许请求
  System.out.println("Request allowed");
} else {
  // 拒绝请求
  System.out.println("Request rejected");
}

实战避坑经验总结

• 精确评估流量：在实施限流策略之前，一定要对系统的流量进行精确评估，包括 QPS、TPS 等指标。可以使用压测工具如 Jmeter 进行测试，并结合实际业务情况进行调整。
• 监控与告警：对限流器的运行状态进行监控，包括限流次数、拒绝请求数等指标，并设置合理的告警阈值，及时发现并处理问题。
• 动态调整限流阈值：根据系统的实际运行情况，动态调整限流阈值。例如，在秒杀活动开始前，可以适当提高限流阈值，活动结束后再恢复正常。
• 考虑用户体验：在拒绝请求时，要友好地提示用户，例如“当前访问人数过多，请稍后再试”。避免直接返回错误页面，影响用户体验。
• Nginx 层面的限流：除了应用层面的限流，还可以在 Nginx 层面上进行限流，例如使用 limit_req_zone 和 limit_req 指令限制单个 IP 的请求频率。宝塔面板可以方便地配置 Nginx 的反向代理和负载均衡，同时也可以进行简单的限流配置，但更复杂的限流逻辑还是需要在应用层面实现。同时需要注意 Nginx 的并发连接数配置，确保 Nginx 本身不会成为瓶颈。

总结：

分布式限流是保障高并发系统稳定运行的关键技术之一。通过选择合适的限流算法和方案，并结合实战经验，可以有效地防止系统被流量冲击，提升系统的可用性和稳定性。