1.问题排查
某服务端应用性能测试,时刻A后陷入假死状态,不对外提供服务。体现为:
-
A时刻后，系统资源消耗下跌：
1.1 CPU占用率下降。
1.2 磁盘与网络IO下降。
1.3 内存占用率下降。 - Dump应用JVM,业务线程均被RabbitMQ客户端阻塞。
- RabbitMQ服务器消息堆积,队列状态为Block。
根据以上特征，初步推测RabbitMQ服务端出于某种策略，阻塞了RabbitMQ客户端继续写入消息，进而阻塞了同步调用RabbitMQ客户端的应用线程。
当服务器（TOMCAT）线程池完全阻塞后，应用体现为不对外服务且系统资源消耗骤降。
2.什么是RabbitMQ-Connection-Blocked，如何在应用程序中处理该场景?
Blocked Connection Notifications
3.思考
延伸来看，作为开发者，选择中间件时，不仅要观察它能解决什么问题，还要考虑引入它带来的代价与风险。例如本文所遭遇的场景，高压环境下，RabbitMQ出于自身保护策略，通过阻塞方式限制写入，导致了生产者应用“假死”，不对外服务。在未深入理解此类问题，并开发代码进行降级保护前，就有可能引发线上事故，影响到用户实际体验，造成不可挽回的损失。
