记录Redis事故影响API性能-上篇

背景

• 线上服务报大量的Redis，相关依赖这个服务的其他产品线服务也报出同样的日志。

         "Could not get a resource from the pool  org.springframework.data.redis.RedisConnectionFailureException: Cannot get Jedis connection; nested exception is redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool" 和 "Connect timed out” 

• 截图线上日志

解决方法：

• 没有上线/相关请求的服务的流量和QPS都没有增加，故认为是redis 服务的问题，联系我们运维查相关服务是否有异常。进过排查重启了一台哨兵服务节点，但不影响服务。
• 坚决认为是服务有问题并认为是某个节点的问题，尝试修改配置中redis 哨兵节点数来校验是不是redis 哨兵有问题，在我们内部云平台中操作 修改配置并重启服务，还因为这个操作导致了商城一次15分钟的商城故障【得不偿失】。
• 经过两天 从查看代码，分析相关日志，咨询运维redis监控服务是否有相关问题，最后从redis 的慢查询监控有大量的keys 慢查询，最终确定是keys 导致的，修改代码并在假日紧急上线，问题修复。

分析

为什么redis 的keys 会导致服务拿不到资源，并且我们有链接池，我们带着这样的问题，我们来剖析一下

• redis是单进程单线程实现的，如果你没有特殊的配置，redis内部默认是FIFO排队，即你对redis的访问都是要在redis进行排队，先入先出的串行执行。

• 通过分析 Jedis 内部的pom 来得知 jedis 的链接池的实现是基于common-pool2的链接池来实现的

从Jedis 中jar 包查看有三种链接池, 选择哪个链接池取决于你的Redis的环境

• JedisPool-单节点模式
• JedisSentinelPool - 哨兵模式
• ShardedJedisPool-集群共享模式

我们的服务用的哨兵模式，对于这几种的redis 链接池的实现方式 请下载源码自行查看，这块不是这篇文章的重点

• 我们通过下面的图来看一下链接池的创建基本流程

  看这个图之前请先了解 common-pool2 实现池的概念和相关参数的解释【下次有时间我在讲解一下这块的源码】

  

• 先展示一下我们系统的相关配置 和 这些配置对应的解释

  

找根因

​ 由于 redis单进程单线程的模式，当我们使用keys 的时候查询很慢的时候，势必会阻塞后面client连接从而报获取不到资源, 这里面的前提条件是经过核实 redis 的连接数是没有达到我们设置的连接池的最大数的

​ 这里面有个最大的疑问是，我都已经有连接池并且没有达到你设置的最大的连接池数量，为什么报拿不到连接池的资源或则是连接超时呢，其实这里面最关键的配置是 max-idle和max-wait，so way， 其实通过上面的铺垫的知识就可以得出 redis 是单进程单线程 并且默认是FIFO排队机制，当我的最大空闲资源耗尽的时候需要通过TCP 方式 和 Redis Server 建立连接，同时由于keys 操作很耗时 所以这个创建在阻塞的并且当达到我们max-wait 就会返回 获取不到连接池的资源或则是连接超时。

扩展

1. 通过上面的结论 我们是否可以认为 调整 max-idle 和 max-wait 的设置 就可以解决这个问题，这个答案是否定的，只有解决性能问题才是最终解决方案。

2. Redis 这种特性用不用连接池都一样？

   虽然基于内存的Redis数据库有着超高的性能，但是底层的网络通信却占用了一次数据请求的大量时间，因为每次数据交互都需要先建立连接，假设一次数据交互总共用时30ms，超高性能的Redis数据库处理数据所花的时间可能不到1ms，也即是说前期的连接占用了29ms，jedis直连方式，也就是每次new jedis都会新建tcp连接，使用后再断开连接，这对于频繁访问redis的场景显然不是高效的使用方式。连接池则可以实现在客户端建立多个链接并且不释放，当需要使用连接的时候通过一定的算法获取已经建立的连接，使用完了以后则还给连接池，这就免去了数据库连接所占用的时间。因此，通常会使用连接池的方式对Jedis连接进行管理，所有jedis对象会预先放在池子中（JedisPool），每次要连接redis，只需要在池子中借，用完了再归还给池子。客户端连接Redis使用的是TCP协议，直连的方式每次需要建立TCP连接，而连接池的方式是可以预先初始化好jedis连接，每次只需要从jedis连接池借用即可，借用和归还操作是在本地进行的，只有少量的并发同步开销，远远小于新建tcp连接的开销。此外，连接池的方式可以有效保护和控制资源的使用，而直连的方式无法限制jedis对象的个数，并且可能存在连接泄漏的情况。

3. 对于我们连接哨兵模式 如果某一个节点挂掉了会不会出现 获取不到连接池和超时呢？且听下回分解

关联文章

​《记录Redis事故影响API性能-下篇》

作者：易企秀工程师 henry_chen