redis(6)-阻塞查询

Redis是典型的单线程架构， 所有的读写操作都是在一条主线程中完成的。 当Redis用于高并发场景时， 这条线程就变成了它的生命线。 如果出现阻塞， 哪怕是很短时间， 对于我们的应用来说都是噩梦。 导致阻塞问题的场景大致分为内在原因和外在原因：
·内在原因包括： 不合理地使用API或数据结构、 CPU饱和、 持久化阻塞等。
·外在原因包括： CPU竞争、 内存交换、 网络问题等。
发现阻塞
当Redis阻塞时， 线上应用服务应该最先感知到， 这时应用方会收到大量Redis超时异常， 比如Jedis客户端会抛出JedisConnectionException异常。 常见的做法是在应用方加入异常统计并通过邮件/短信/微信报警， 以便及时发现通知问题。
可以借助于日志系统，如Java语言可以使用logback或log4j。 当异常发生时， 异常信息最终会被日志系统收集到Appender（输出目的地） ， 默认的Appender一般是具体的日志文件， 开发人员可以自定义一个Appender， 用于专门统计异常和触发报警逻辑。
如果应用操作的是多个Redis节点（比如使用Redis集群），那么我们就需要找到对应报错的redis节点。但绝大多数的客户端类库并没有在异常信息中打印ip和port信息， 导致无法快速定位是哪个Redis节点超时。不过修改Redis客户端成本很低， 比如Jedis只需要修改Connection类下的
connect、 sendCommand、 readProtocolWithCheckingBroken方法专门捕获连接， 发送命令， 协议读取事件的异常。
也可以选择redis监控系统来发现阻塞问题，可以机子公司开发或者是借助开源的监控系统，例如C