redis引发的一系列生产问题

描述背景：

账务系统，峰值时每秒大概处理200笔请求（收单，转账，退款等等）。

某其他业务线上线新功能，有BUG，瞬间往redis中写入7G数据，redis系统瘫痪。

redis系统重启。

账务系统开始报无法从redis连接池中获取连接。账务系统内有大量的redis锁，用来做并发控制。

问题解决过程：

发现redis连接池占满。

公司有定时系统，各系统都通过定时系统来驱动自己的业务系统做补偿，与定时系统同机房的直接请求极高。与定时系统不同机房的机器请求数量不高。

找领导，把公司的定时系统停掉，把redis的连接池数量翻倍，数据不再积压，开始缓慢下降。

总结：

核心系统要有自己的组件，比如一个独立的redis。

不要信任上游系统，要有一定的限流机制，不然它可能会一秒发过来N个请求。

自己的系统的队列系统要可以关闭开启，还要可以控制处理速度，这样可以暂时的撇开已经积压的数据，让新进来的交易可以正常进行。

当一笔请求失败，如果有补偿，那么它可能会造成N个补偿，让请求量剧增。问题就出在这个其他系统的补偿上。

为什么平时没事情，一旦出现波动，系统就全面瘫痪？想到一个词，雪崩效应和竞争。

系统要有全面的监控，监控这种池，各种内存，CPU，当资源几乎满状态下，一个波动就可能造成崩溃。

重要关键系统要有容灾预案。