在 Debian 上处理高并发的 RabbitMQ 实践
一 系统与环境准备
- 提升文件描述符与内核资源：在 /etc/security/limits.conf 为运行用户（如 rabbitmq）设置 nofile 65536，并在 /etc/rabbitmq/rabbitmq-env.conf 中导出 RABBITMQ_OPEN_FILES_LIMIT=65536，避免连接/通道耗尽；必要时在 systemd 服务单元中设置 LimitNOFILE=65536。同时优化内核网络与文件参数（如 somaxconn、tcp_tw_reuse）以减少连接排队与 TIME_WAIT 占用。
- 选择高性能存储与网络：持久化与页面缓存对 磁盘 I/O 敏感，优先使用 SSD/NVMe；客户端与 Broker 建议部署在同一局域网以降低网络时延与丢包。
- 基础组件与监控：安装并启用 rabbitmq_management 插件（默认监听 15672），便于实时查看队列、连接、通道与速率等指标；后续可对接 Prometheus + Grafana 做长期可视化监控与告警。
二 Broker 与队列架构优化
- 内存与磁盘水位：在 rabbitmq.conf 中设置相对内存水位（如 vm_memory_high_watermark.relative=0.7）与磁盘水位（如 disk_free_limit=2GB），既避免 OOM，又减少频繁触发流控导致的生产者阻塞。
- 队列模型与高可用：按业务拆分队列避免“单队列瓶颈”，必要时进行队列分片提升并发；关键业务优先使用 Quorum Queue（Raft 一致性、持久化），海量日志/事件流考虑 Stream Queue（高吞吐、批量消费）；非关键场景谨慎使用镜像队列（同步复制带来网络与磁盘开销）。
- 惰性队列：对于大量持久化消息且消费较慢的场景，启用 Lazy Queue 将消息主要存放在磁盘，降低内存压力与页面换入/换出。
- 连接与通道：适度提高 max_connections 与 max_channels_per_connection（如 65536 / 1024），并禁用不必要插件以减少资源占用。
三 客户端并发与可靠性配置
- 连接与通道复用：复用 Connection，每个线程/任务使用独立 Channel；高并发使用连接池/Channel 缓存（如 Spring 的 CachingConnectionFactory），避免频繁建连带来的握手与 GC 开销。
- 生产者侧：开启 Publisher Confirms，采用异步或批量确认降低往返时延；结合批量发送（数量阈值或时间阈值）提升吞吐；失败重试使用指数退避并设定上限，避免雪崩。
- 消费者侧：启用手动 ACK 与合理 prefetchCount（如 10–100 起步，I/O 密集可更高），在保证公平分发的同时避免 unacked 堆积；将耗时操作异步化或批量写库，异常消息转入 DLX（死信队列） 后继续处理正常消息，防止单条失败拖垮整个消费者。
四 监控 压测 与容量规划
- 监控要点：在管理界面或 /api/ 端点持续观测 队列长度、消息速率（publish/consume）、确认延迟、内存/磁盘使用、连接/通道数 等关键指标；对接 Prometheus + Grafana 建立面板与阈值告警（如队列持续增长、ACK 延迟升高、内存逼近水位）。
- 压测方法：使用官方 perf-test 工具在不同消息大小、QoS、队列类型下做基线压测，观察吞吐、P95/P99 延迟与资源利用率，据此迭代 prefetch、并发度与队列模型。
- 容量与扩展：当单机达到瓶颈时，优先通过队列拆分/分片 + 多消费者并发横向扩展；对关键业务引入 集群/镜像或仲裁队列 提升可用性与吞吐；结合业务 SLA 设置磁盘/内存水位告警与消费者扩缩容策略。
