背景问题:
线上系统自某一天,业务慢慢到高峰,首页会逐步卡顿,高峰时甚至异常白屏,且蔓延到其它界面。
原因:
经过焦灼的排查,定位到:
原因是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故障,流下了痛苦的眼泪。。。