本文讲述了由于MQ中间件故障触发的降级机制设计不当，导致线上系统在高峰期瞬间崩溃。系统使用内存双缓冲+批量刷磁盘的方式应对MQ故障，但在高并发下，由于当前缓冲区满后所有线程无限等待，导致系统卡死。通过分析JVM快照发现问题在于缓冲区大小不足，扩容后解决了问题。这个案例强调了系统设计需能承受最大流量压力测试的重要性。
V-xin：ruyuanhadeng获得600+页原创精品文章汇总PDF
背景介绍
背景情况是这样：线上一个系统，在某次高峰期间MQ中间件故障的情况下，触发了降级机制，结果降级机制触发之后运行了一小会儿，突然系统就完全卡死，无法响应任何请求。
给大家简单介绍一下这个系统的整体架构，这个系统简单来说就是有一个非常核心的行为，就是往MQ里写入数据，但是这个往MQ里写入的数据是非常核心及关键的，绝对不容许有丢失。
所以最初就设计了一个降级机制，如果一旦MQ中间件故障，那么这个系统立马就会把核心数据写入本地磁盘文件。
但是如果说在高峰期并发量比较高的情况下，接收到一条数据立马同步写本地磁盘文件，这个性能绝对是极其差的，会导致系统自身的吞吐量瞬间大幅度下降，这个降级机制是绝对无法在生产环境运行的，因为自己就会被高并发请求压垮。
因此当时设计的时候，对降级机制进行了一番精心的设计。
我们的核心思路是一旦MQ中间件故障，触发降级机制之后，系统接收到一条请求不是立马写本地磁盘，而是采用内存双缓冲 + 批量刷磁盘的机制。
简单来说，系统接收到一条消息就会立马写内存缓冲，然后开启一个后台线程把内存缓冲的数据刷新到磁盘上去。
整个过程，大家看看下面的图，就知道了。
这个内存缓冲实际在设计的时候&
最低0.47元/天 解锁文章
715
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
