redis慢查询导致的线上事故

背景

接入流量涨了将近一倍时，用户就反馈系统的反应很慢，发起一个请求后，要很久才能实际看到响应的结果。

排查和分析过程

1.因为用户是在浏览器页面上操作的，所以做的第一件事就是打开网页和开发者工具，然后模拟用户操作发起请求。发现这个过程有些操作的响应是很快的，而有些不是，初步排除是服务出了问题（内存溢出，死循环等），然后根据请求的响应时间确定出现延时的接口。
2.确定了接口后，查看接口的实现，发现全部都是基于redis的读操作。初步判断是redis出了问题。马上登上redis服务器，查看redis进程的各项指标（cpu使用率，内存使用率等情况），发现基本基本上都是正常水平，查看redis的异常日志，发现没有什么异常信息。
3.经过对一系列常见的监控指标排查后没有得到异常信息，于是怀疑是否连接数已满。用netstat指令统计客户端连接，发现客户端连接服务器的连接数并没有满。
4.经过一番排查没有头绪的时候，DBA告知redis有很多慢查询，而且查询时间基本上都超过了一秒。结合redis单线程的特性分析，极大可能是这个原因，于是马上修改代码逻辑，将慢查询语句逐个消除。修改完毕后上线观察，用户那边果然没有再反馈反应慢的问题了，问题解决。

思考与总结

redis作为单线程组件的代表之一，在使用时一定要紧密结合它的指令执行单线程的特性，避免在生产上使用一些耗时高的慢查询和一些大value，否则redis的查询操作很有可能就会成为整个系统的瓶颈，那就是基于内存操作的redis的响应竟然会很慢很慢很慢~