背景问题：
线上系统自某一天，业务慢慢到高峰，首页会逐步卡顿，高峰时甚至异常白屏，且蔓延到其它界面。
原因：
经过焦灼的排查，定位到：
原因是app客户端首页有一个业务组件是基于redis的单点list结构设计的功能，代码逻辑是lrange 0 -1，即拿出list所有数据到应用层，
然后在应用层随机取4个返回客户端展示。 这个组件刚上的时候list里只有几个对象，lrange 0 -1，因为对象少，虽是单点也没啥大问题。
但是这个组件很久未运营配置，年底时运营上了这个组件，此时redis的list里有1000多个对象，这个组件又放在首页qps很大；业务层又会用pipeline，
然后就出了问题。
原因一句话总结：redis单点大热key叠加pipeline命令，导致redis不可用进一步引起服务逐步雪崩。
具体过程梳理如下：
1.运营将这个很久不用的组件配置在首页，此时这个组件依赖的redis单点list数据结构中有1000多个对象，list空间大小>1M.
2.依赖的redis的数据结构是个单点key, redis是redis-cluster HA模式。
3.这个组件在首页，访问量很大，峰值>1万QPS, 是个热key.
4.异常时，可以观察到：redis-cluster这个节点内存占用很高，线上报大量io-closeWait异常，网络链接大量超时及重连；原因是因为每次要lrange 0 -1全部数据到应用层，
即每次请求要请求1M数据，然后又是单点热key, 导致了redis响应缓冲区溢出；这个redis节点不可用。
用户侧的感知就是，业务谷点首页还能展示，随着到了业务高峰，会感觉逐步卡顿，到后面蔓延到有依赖redis的所有功能都不可用。
5.之所以会蔓延到其它依赖redis的功能，主要是因为我们业务侧有使用较多的redis pipeline命令，当集群中某个机器发起pipeline命令，
然后这个命令中若有一个key也落在了这个异常的redis单点中，会导致这个pipeline命令也阻塞，那么后续其它命令也会跟着阻塞，即蔓延到了其它依赖redis的功能。
6.最终的表象就是：在业务高点，用户进app基本不可用，其它功能极其卡顿也基本不可用。
解决方式：
影响：
造成了实际的资金损失，影响严重，最终被定级为S0故障，流下了痛苦的眼泪。。。