IIS托管WebAPI停止处理RabbitMQ队列消息排查求助

验证IIS应用池是否休眠的方法 #

• 检查应用池闲置超时设置：打开IIS管理器，找到对应应用池右键进入「高级设置」，查看「闲置超时(分钟)」（默认20分钟）。临时将其设为0（禁用闲置超时），观察是否还出现停收消息的情况——如果恢复正常，说明就是闲置休眠导致的。
• 查看应用池回收日志：在应用池高级设置里开启「生成回收事件日志」，然后到事件查看器→Windows日志→应用程序里找WAS（Windows Process Activation Service）的日志记录。如果回收时间和停收消息的时间吻合，即可确认是IIS回收引发的问题。
• 加心跳防闲置：在WebAPI里写个简单的GET接口（比如/api/heartbeat），用Windows任务计划定时调用curl访问这个接口，强制不让应用池进入闲置状态。如果这样操作后问题消失，也能佐证是闲置休眠的原因。

排查RabbitMQ相关问题（排除非IIS因素） #

• 监控连接/通道状态：在代码里给RabbitMQ连接添加ConnectionShutdown事件监听，给通道添加CallbackException事件监听，记录断开、异常的具体原因。如果日志里有连接中断记录，大概率是网络波动、RabbitMQ服务器重启或连接超时导致的，和IIS无关。
• 检查消息确认机制：如果用了AutoAck=true（自动确认），但消息处理时间过长，RabbitMQ可能会判定消费者异常并关闭通道。改成AutoAck=false（手动确认），处理完消息再调用BasicAck，同时查看是否有未确认消息堆积。
• 排查线程阻塞：检查消息处理逻辑里有没有长时间同步调用、死锁等情况——这类问题会卡住监听线程，导致无法继续取消息。可以在代码里加线程状态日志，或者用Visual Studio附加进程查看线程调用栈。
• 查看RabbitMQ后台状态：登录RabbitMQ管理后台，看对应队列的消费者数量、消息堆积情况。如果消费者数量变为0，说明客户端连接断开；如果有消息堆积但消费者存在，大概率是客户端线程被卡住了。

针对性解决建议 #

• 若确认是IIS问题：
  • 直接禁用应用池闲置超时（高级设置里把闲置超时设为0）
  • 将应用池定期回收时间调整到业务低峰期，同时写预热脚本在回收后自动触发接口请求，保证服务快速恢复
  • 考虑改用Windows服务：WebAPI是请求驱动的架构，天生不适合长期监听队列的场景，Windows服务是后台常驻进程，更适配这种持续消费的任务。
• 若排除IIS问题：
  • 优化连接逻辑：用连接池管理RabbitMQ连接，在连接断开时自动重连（比如在ConnectionShutdown事件里重新初始化连接和消费者）
  • 异步处理消息：把耗时的消息处理逻辑放到异步线程里，保证监听线程不被阻塞，持续拉取消息
  • 加监控告警：对RabbitMQ连接状态、消费者数量、消息处理耗时做监控，异常时及时告警

内容的提问来源于stack exchange，提问作者Flea