10倍请求压力来的时候，你的系统会被拖垮吗

　　最近把了老系统改造成基于Spring Cloud Alibaba为基础的微服务框架，接着便进行线上压力测试。

　　结果如下：在请求压力的高峰期间并且MQ中间件故障的情况，触发了降级机制，结果降级机制触发了之后运行了一小会，突然系统就完全卡死，无法响应任何请求。

　　这个系统的整体架构如下：简单来说就是又一个非常核心的行为，就是往MQ里写数据，但是往这个MQ里写的数据非常核心并且关键的，绝不容许有任何丢失。

　　所以最初就设计了一个降级机制：如果MQ中间件一旦故障，那么这个系统就会立马把核心数据写入到本地的磁盘文件。

　　在高峰期并发量比较高的情况下，如果接收到一条数据就直接写磁盘，性能绝对是比较差的。

　　所以我们的设计是：一旦MQ中间件发生故障，不是直接写本地磁盘，而是采用内存缓冲+批量刷盘的机制。

　　在内存缓冲设计的时候，分为两个区域，一个是current区域用来提供系统写数据，另外一个是ready区域，用来提供给线程把数据刷到磁盘去。

　　每一块内存区域的缓冲大小都是512kb,系统接收到数据就会写缓冲区域，因此内存一定会写满。

　　在current区域写满了之后，就会交换current区域和ready区缓冲区，交换过后ready承载了之前current区的内容。

　　此时后台线程就可以将ready缓冲区的数据通过Java NIO的API，直接高性能的Append写入到本地磁盘文件。