一次rabbitmq引起的系统雪崩
来源:互联网 发布:js更改文本框颜色 编辑:程序博客网 时间:2024/06/04 23:48
上个月,给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.2G;在消息量很大的时候,就会把在rabbitmq的试用慢.我们的广播试用的faout类型的交换做的,大概有100台实例需要试用本地cache,也就是发3M就慢了,万一消费来不了,就堵了.在这篇文章(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因为查询而添加时候,不广播了;只广播因数据修改的消息
阅读全文
0 0
- 一次rabbitmq引起的系统雪崩
- 一次由系统mail引起的宕机事故
- 记一次触摸屏引起的系统卡断
- 一次memcpy引起的bug
- 一次OOM引起的优化
- rabbitMq设置引起的生产问题
- 分布式系统 缓存穿透与失效时的雪崩效应
- 没有超时和隔离差点引发的系统雪崩
- 一次老板发话引起的思考
- 一次HashMap多线程安全引起的事故
- 一次HashMap多线程安全引起的事故
- 记一次加班所引起的深思
- 一次HashMap多线程安全引起的事故
- 一次HashMap多线程安全引起的事故
- 一次DDOS攻击引起的安全漫谈
- 一次HashMap多线程安全引起的事故
- 一次重定向引起的异步IO
- 一次HashMap多线程安全引起的事故
- Java多线程
- Android “hook”ContentView
- MVP的认识
- Highcharts 的画图使用
- Java中的注解基础
- 一次rabbitmq引起的系统雪崩
- 二叉树中和为某一值的路径
- 个人学习(九)
- 五、顺序栈
- ToolBar简单实用
- ECMAScript6入门
- summit 6.0 + redhat6.5 + oracle11.2g 安装(1)
- imx6q芯片linux内核版本操作系统,将显示颜色顺序从bgr修改为rgb
- 史上最简单的 SpringCloud 教程 | 第一篇: 服务的注册与发现(Eureka)