Sentinel vs Resilience4j vs Bucket4j：分布式限流方案对比与实战-EW帮帮网

Sentinel vs Resilience4j vs Bucket4j：分布式限流方案对比与实战

在高并发微服务架构中，合理的限流策略是保护系统稳定性与可用性的关键。本文将从问题背景入手，对 Sentinel、Resilience4j 和 Bucket4j 三种常见的分布式限流方案进行对比，并结合完整的 Spring Boot 代码示例进行实战演练，帮助读者在不同场景下做出最佳选型。

1. 问题背景介绍

随着业务量的增长，单体应用逐步拆分为微服务架构，多服务间调用频繁，突发流量会导致部分服务压力骤增，引发雪崩效应。常见的保护手段有：熔断、限流、降级等。其中，限流通过控制请求速率，从源头上抑制流量峰值，避免下游服务过载。本文聚焦于限流算法与实现，选取了业界主流的三大方案：

Sentinel：阿里开源的流量防护框架，核心特性包括多维度限流、熔断降级、监控与动态配置。
Resilience4j：Netflix Hystrix 的轻量级替代品，提供限流、熔断、重试、隔离等功能，纯 Java 实现，无外部依赖。
Bucket4j：基于令牌桶算法的 Java 库，可配合 Redis、Hazelcast 等分布式存储构建多节点限流。

2. 多种解决方案对比

2.1 Sentinel 限流原理与示例

Sentinel 的限流基于滑动窗口计数或排队等待，支持 QPS/线程数两种模式，并可结合热点参数限流。核心配置项：

# application.yml
spring:
  cloud:
    sentinel:
      transport:
        dashboard: 127.0.0.1:8818
      eager: true

sentinel:
  flow:
    enabled: true
    rules:
      - resource: "/api/orders"
        grade: 1            # 限流类型：1-QPS, 0-线程数
        count: 100          # 阈值
        controlBehavior: 0  # 0-直接拒绝;1-排队等待

在代码中，可使用注解简化：

@RestController
public class OrderController {
    @GetMapping("/api/orders")
    @SentinelResource(value = "/api/orders", blockHandler = "handleBlock")
    public String getOrders() {
        // 真实业务逻辑
        return "Orders List";
    }

    // 限流触发时调用
    public String handleBlock(BlockException ex) {
        return "系统繁忙，请稍后再试";
    }
}

2.2 Resilience4j 限流原理与示例

Resilience4j 的限流基于令牌桶算法实现，核心组件是 RateLimiter。通过 RateLimiterRegistry 管理限流器：

@Bean
public RateLimiterRegistry rateLimiterRegistry() {
    RateLimiterConfig config = RateLimiterConfig.custom()
            .limitForPeriod(50)                  // 每个周期发放令牌数
            .limitRefreshPeriod(Duration.ofSeconds(1))
            .timeoutDuration(Duration.ofMillis(200)) // 等待最长时间
            .build();
    return RateLimiterRegistry.of(config);
}

@Autowired
private RateLimiterRegistry registry;

@GetMapping("/api/pay")
public String pay() {
    RateLimiter limiter = registry.rateLimiter("payService");
    Supplier<String> decorated = RateLimiter.decorateSupplier(limiter, () -> {
        // 业务逻辑
        return "支付成功";
    });
    try {
        return decorated.get();
    } catch (RequestNotPermitted ex) {
        return "支付请求过于频繁，请稍后再试";
    }
}

2.3 Bucket4j 限流原理与示例

Bucket4j 采用漏桶/令牌桶算法，可将桶状态持久化到 Redis，以支持分布式场景：

@Bean
public Refill refill() {
    return Refill.greedy(100, Duration.ofSeconds(1));
}

@Bean
public Bandwidth limit() {
    return Bandwidth.classic(100, refill());
}

@Autowired
private RedisTemplate<String, byte[]> redisTemplate;

@GetMapping("/api/data")
public String getData() {
    String key = "api:data:bucket";
    Bucket bucket = Bucket4j.extension(RedisBucketBuilder.class)
            .builder()
            .addLimit(limit())
            .build(redisTemplate, key);

    if (bucket.tryConsume(1)) {
        return "获取数据成功";
    } else {
        return "请求过于频繁，请稍后访问";
    }
}

3. 各方案优缺点分析

| 特性 | Sentinel | Resilience4j | Bucket4j | | ---------- | ------------------------ | --------------------------- | --------------------------- | | 上手难度 | 中等（需部署 Dashboard） | 低（纯库无额外依赖） | 低（轻量级库） | | 分布式支持 | 内置集群通信与动态下发 | 需自行结合分布式存储 | 原生支持 Redis、Hazelcast 等 | | 限流精度 | 滑动窗口/排队等待 | 令牌桶 | 令牌桶 | | 功能丰富度 | 限流、熔断、降级、监控 | 限流、熔断、重试、隔离等 | 仅限流算法库 | | 运维成本 | 较高（需运维 Dashboard） | 低 | 低 |

4. 选型建议与适用场景

需要一体化流控和监控、具备动态图形化控制台：推荐 Sentinel。
业务场景轻量、只需限流+熔断或无外部依赖：推荐 Resilience4j。
已有 Redis/Hazelcast 等分布式存储，限流场景简单：可直接使用 Bucket4j。

5. 实际应用效果验证

5.1 压测场景

使用 Apache JMeter 对 /api/orders 接口进行压测，设定并发 200，持续 60s，观察各方案的吞吐与响应：

Sentinel QPS 模式下，接口稳定在 100 TPS，超出直接快速失败。
Resilience4j 限流后，接口稳定在 50 TPS，超出会排队等待或快速失败。
Bucket4j 基于 Redis 的分布式桶，吞吐与配置一致，同时支持跨实例共享。

5.2 结论

三种方案各有千秋，Sentinel 功能最为全面，适合阿里生态或需要可视化运维场景；Resilience4j 轻量、无外部依赖；Bucket4j 专注限流，可与多种分布式存储结合。实际选型应结合团队技术栈、运维成本与业务需求综合考量。

本文内容源码已上传至 GitHub：

https://github.com/your-repo/distributed-rate-limiter-demo

Sentinel vs Resilience4j vs Bucket4j：分布式限流方案对比与实战