描述背景：
账务系统，峰值时每秒大概处理200笔请求（收单，转账，退款等等）。
某其他业务线上线新功能，有BUG，瞬间往redis中写入7G数据，redis系统瘫痪。
redis系统重启。
账务系统开始报无法从redis连接池中获取连接。账务系统内有大量的redis锁，用来做并发控制。
问题解决过程：
发现redis连接池占满。
公司有定时系统，各系统都通过定时系统来驱动自己的业务系统做补偿，与定时系统同机房的直接请求极高。与定时系统不同机房的机器请求数量不高。
找领导，把公司的定时系统停掉，把redis的连接池数量翻倍，数据不再积压，开始缓慢下降。
总结：
核心系统要有自己的组件，比如一个独立的redis。
不要信任上游系统，要有一定的限流机制，不然它可能会一秒发过来N个请求。
自己的系统的队列系统要可以关闭开启，还要可以控制处理速度，这样可以暂时的撇开已经积压的数据，让新进来的交易可以正常进行。
当一笔请求失败，如果有补偿，那么它可能会造成N个补偿，让请求量剧增。问题就出在这个其他系统的补偿上。
为什么平时没事情，一旦出现波动，系统就全面瘫痪？想到一个词，雪崩效应和竞争。
系统要有全面的监控，监控这种池，各种内存，CPU，当资源几乎满状态下，一个波动就可能造成崩溃。
重要关键系统要有容灾预案。