上个月，给app提供的app不能访问了，惊呆了，突然间不能访问了．上去看日志没有报错，机器load,内存,cpu都正常，日志也没有报错，真是遇见鬼了．最后发现是rabbitmq引起的．

项目的系统结构

项目是布的微服务，使用了dubbo做的rpc,使用的rabbitmq做的消息，mysql,redis等．对外提供的api,使用的netty(64个线程)，最重要的一点是：试用了rabbitmq做了分布式的本地cache.这次故障的原因：就是netty和rabbitmq的做分布式local cache.

原因

分布式local cache的设计是，当本地cache的有数据更新时候，就会广播到其他实例．而rabbitmq机器的内存是8G,默认试用内存为40%,也就是3.2Ｇ；在消息量很大的时候，就会把在rabbitmq的试用慢．我们的广播试用的faout类型的交换做的，大概有100台实例需要试用本地cache,也就是发３Ｍ就慢了，万一消费来不了，就堵了．在这篇文章（http://www.rabbitmq.com/memory.html）中介绍：

By default, when the RabbitMQ server uses above 40% of the installed RAM, it raises a memory alarm and blocks all connections that are publishing messages. >Once the memory alarm has cleared (e.g. due to the server paging messages to disk or delivering them to clients that　only consume) normal service resumes.

api的64个线程都堵住了，也就接不了app打过来的请求了．

解决问题

1. 换台大的内存的机器
2. 发送消息时候线程池发送，同时使用试用固定大小的BlockingQueue
3. 当本地cache因为查询而添加时候，不广播了；只广播因数据修改的消息