上个月，给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打过来的请求了．
解决问题
- 换台大的内存的机器
- 发送消息时候线程池发送，同时使用试用固定大小的BlockingQueue
- 当本地cache因为查询而添加时候，不广播了；只广播因数据修改的消息
