视频看了几百小时还迷糊？关注我，几分钟让你秒懂！

在高并发场景中，生产者疯狂发消息是导致 RabbitMQ 崩溃的常见原因。即使你配置了消费端限流（prefetch），如果生产速度远超消费能力，队列仍会无限堆积，最终引发内存溢出、磁盘写满、Broker 宕机。

这时候，生产者限流就成了系统稳定的“第一道防线”！

本文将用真实场景 + Spring Boot 代码 + 4 种限流算法 + 反例避坑，教你用 Java 实现可靠的生产者限流。

一、为什么需要生产者限流？

🎯 真实场景：日志上报风暴

• 某服务每秒产生 5 万条日志；
• 日志通过 RabbitMQ 发送到分析系统；
• 但分析系统最多处理 2000 QPS；
• 结果：队列堆积 1000 万条，RabbitMQ 内存爆掉，整个消息集群瘫痪！

生产者限流的目标：

控制消息发送速率，使其不超过下游处理能力，避免“好心办坏事”。

二、Java 实现生产者限流的 4 种方式

✅推荐组合：Semaphore（防堆积） + RateLimiter（控速率）

三、Spring Boot 实战：4 种限流方案代码

✅ 前提：启用 Publisher Confirm

# application.yml spring: rabbitmq: publisher-confirm-type: correlated publisher-returns: true

方案 1：Semaphore —— 限制未确认消息数（最常用！）

@Service public class SemaphoreLimitedProducer { private final RabbitTemplate rabbitTemplate; // 最多允许 100 条未 ACK 消息 private final Semaphore semaphore = new Semaphore(100); public void send(String message) throws InterruptedException { // 获取许可（若已达上限，则阻塞等待） semaphore.acquire(); CorrelationData correlationData = new CorrelationData(); correlationData.getFuture().addCallback( result -> semaphore.release(), // 成功 → 释放 ex -> semaphore.release() // 失败 → 也释放 ); rabbitTemplate.convertAndSend("log.exchange", "log.key", message, correlationData); } }

✅优势：

• 与 RabbitMQ 的basic.ack机制完美配合；
• 自动适配消费速度：消费者越快，生产越快；
• 防止内存 OOM。

方案 2：Guava RateLimiter —— 控制每秒发送量

@Service public class RateLimiterProducer { private final RabbitTemplate rabbitTemplate; // 限制 1000 QPS private final RateLimiter rateLimiter = RateLimiter.create(1000.0); public void send(String message) { // 阻塞直到获取到令牌 rateLimiter.acquire(); rabbitTemplate.convertAndSend("log.exchange", "log.key", message); } }

⚠️ 注意：RateLimiter是单机限流，多实例需配合其他方案。

方案 3：组合使用（推荐！）

@Service public class CombinedProducer { private final RabbitTemplate rabbitTemplate; private final Semaphore semaphore = new Semaphore(200); // 防堆积 private final RateLimiter rateLimiter = RateLimiter.create(800.0); // 控速率 public void send(String message) throws InterruptedException { // 先控速率 rateLimiter.acquire(); // 再防堆积 semaphore.acquire(); CorrelationData cd = new CorrelationData(); cd.getFuture().addCallback(r -> semaphore.release(), e -> semaphore.release()); rabbitTemplate.convertAndSend("log.exchange", "log.key", message, cd); } }

✅效果：

• 每秒最多发 800 条；
• 同时未确认消息不超过 200 条；
• 双重保险，稳如泰山！

方案 4：Redis 分布式限流（集群场景）

@Service public class RedisRateLimiterProducer { @Autowired private StringRedisTemplate redisTemplate; private static final String RATE_LIMIT_KEY = "rabbitmq:producer:rate"; private static final int MAX_REQUESTS = 1000; // 每秒1000次 private static final int WINDOW_SECONDS = 1; public boolean trySend(String message) { String script = """ local count = redis.call('INCR', KEYS[1]) if count == 1 then redis.call('EXPIRE', KEYS[1], ARGV[1]) end return count <= tonumber(ARGV[2]) """; Boolean allowed = redisTemplate.execute( new DefaultRedisScript<>(script, Boolean.class), Collections.singletonList(RATE_LIMIT_KEY), String.valueOf(WINDOW_SECONDS), String.valueOf(MAX_REQUESTS) ); if (Boolean.TRUE.equals(allowed)) { rabbitTemplate.convertAndSend("log.exchange", "log.key", message); return true; } return false; // 超限，拒绝发送 } }

✅适用：微服务多实例部署，需全局限流。

❌ 反例：这些“限流”根本无效！

反例 1：只 sleep 不判断

// ❌ 错误！无法应对突发流量 public void send(String msg) { Thread.sleep(1); // 以为能控速 rabbitTemplate.send(...); }

问题：多线程下依然会超速！

反例 2：限流但不处理 Confirm 失败

semaphore.acquire(); rabbitTemplate.send(...); // 没有回调释放 semaphore

后果：一旦消息失败，semaphore永远少一个许可，最终所有线程阻塞！

⚠️ 关键注意事项

1. 必须处理 Confirm 回调
   无论成功/失败，都要release()，否则会死锁。

2. 不要用 synchronized 限流
   性能极差，且无法跨 JVM。

3. 监控限流指标

   • 被限流的请求数；
   • 未确认消息数；
   • RabbitMQ 队列长度。

4. 降级策略
   超限时可：

   • 丢弃非核心消息（如日志）；
   • 写入本地文件缓冲；
   • 返回“系统繁忙”给上游。

5. 测试要模拟高并发
   使用 JMeter 或 Gatling 压测，验证限流是否生效。

四、如何选择限流方案？

五、总结

RabbitMQ 生产者限流的核心思想是：

不让消息“洪水”冲垮系统，而是让它变成“可控溪流”。

记住三句话：

1. 用 Semaphore 防堆积（配合 Confirm）；
2. 用 RateLimiter 控速率；
3. 集群场景上 Redis。

只要做到这三点，你的消息系统就能在大促洪峰中稳如老狗！

视频看了几百小时还迷糊？关注我，几分钟让你秒懂！