【Redis故障排查】「连接失败问题排查和解决」带你总体分析和整理Redis的问题故障实战开发指南及方案

Redis连接失败问题排查和解决

当你的应用服务在连接Redis时出现了拒绝连接的场景，首先你可以根据调整Redis实例参数maxclients的配置。maxclients代表着最大同时连接的客户端个数，Proxy集群实例不支持该参数，取值范围1,000～50,000，默认值：10,000，可以调整的再大一些。

客户端拒接连接问题

如果你使用的是集群模式，而使用客户端连接进行连接Cluster集群时，连接失败出现Read timed out或Could not get a resource from the pool。

分析排查方向

• 排查是否使用了keys命令，keys命令会消耗大量资源，造成Redis阻塞。建议使用scan命令替代，且避免频繁执行。
• 当Redis数据持久化即AOF时，会触发偶现的磁盘性能问题，导致连接异常，可更换Redis所在磁盘升级为ssd盘，磁盘性能更高，或若不需要持久化可关闭AOF。

unexpected end of stream错误，导致业务异常。

分析排查方向

Jedis连接池调优，建议参考Jedis参数配置建议进行配置连接池参数。

Jedis连接池参数配置建议

Jedis连接池优势

Lettuce客户端及Jedis客户端比较如下：

• Lettuce：
  • Lettuce客户端没有连接保活探测，错误连接存在连接池中会造成请求超时报错。
  • Lettuce客户端未实现testOnBorrow等连接池检测方法，无法在使用连接之前进行连接校验。
• Jedis：
  • Jedis客户端实现了testOnBorrow、testWhileIdle、testOnReturn等连接池校验配置。
  • 开启testOnBorrow在每次借用连接前都会进行连接校验，可靠性最高，但是会影响性能（每次Redis请求前会进行探测）。
  • testWhileIdle可以在连接空闲时进行连接检测，合理配置阈值可以及时剔除连接池中的异常连接，防止使用异常连接造成业务报错。
  • 在空闲连接检测之前，连接出现问题，可能会造成使用该连接的业务报错，此处可以通过参数控制检测间隔（timeBetweenEvictionRunsMillis）。

因此，Jedis客户端在面对连接异常，网络抖动等场景下的异常处理和检测能力明显强于Lettuce，可靠性更强。

maxTotal（最大连接）

根据Web容器的Http线程数来进行配置，估算单个Http请求中可能会并行进行的Redis调用次数，例如：Tomcat中的Connector内的maxConnections配置为150，每个Http请求可能会并行执行2个Redis请求，在此之上进行部分预留，则建议配置至少为：150 x 2 + 100= 400。

限制条件

单个Redis实例的最大连接数。maxTotal和客户端节点数（CCE容器或业务VM数量）数值的乘积要小于单个Redis实例的最大连接数。

例如：Redis主备实例配置maxClients为10000，单个客户端maxTotal配置为500，则最大客户端节点数量为20个。

maxIdle（最大空闲连接）

建议配置为maxTotal一致。

minIdle（最小空闲连接）

一般来说建议配置为maxTotal的几分之一。

例如，此处常规配置建议为：100。对于性能敏感的场景，防止经常连接数量抖动造成影响，也可以配置为与maxIdle一致，例如：400。

maxWaitMillis（最大获取连接等待时间）

单位：毫秒

获取连接时最大的连接池等待时间，根据单次业务最长容忍的失败时间减去执行命令的超时时间得到建议值。

例如：Http最大容忍超时时间为15s，Redis请求的timeout设置为10s，则此处可以配置为5s。

timeout（命令执行超时时间）

单位：毫秒

单次执行Redis命令最大可容忍的超时时间，根据业务程序的逻辑进行选择，一般来说处于对网络容错等考虑至少建议配置为210ms以上。特殊的探测逻辑或者环境异常检测等，可以适当调整达到秒级。

minEvictableIdleTimeMillis（空闲连接逐出时间）

大于该值的空闲连接一直未被使用则会被释放，单位：毫秒

如果希望系统不会经常对连接进行断链重建，此处可以配置一个较大值（xx分钟），或者此处配置为-1，并且搭配空闲连接检测进行定期检测。

timeBetweenEvictionRunsMillis（空闲连接探测时间间隔）

单位：毫秒

根据系统的空闲连接数量进行估算，例如，系统的空闲连接探测时间配置为30s，则代表每隔30s会对连接进行探测，如果30s内发生异常的连接，经过探测后会进行连接排除。

根据连接数的多少进行配置，如果连接数太大，配置时间太短，会造成请求资源浪费。对于几百级别的连接，常规来说建议配置为30s，可以根据系统需要进行动态调整。

testOnBorrow（进行获取连接检测）

向资源池借用连接时是否做连接有效性检测（ping），检测到的无效连接将会被移除。

对于业务连接极端敏感的，并且性能可以接受的情况下，可以配置为True，一般来说建议配置为False，启用连接空闲检测。

testWhileIdle

是否在空闲资源监测时通过ping命令监测连接有效性，无效连接将被销毁。一般设置为True。

testOnReturn

向资源池归还连接时是否做连接有效性检测（ping），检测到无效连接将会被移除。一般设置为False。

maxAttempts

在JedisCluster模式下，您可以配置maxAttempts参数来定义失败时的重试次数。建议配置3-5之间，默认配置为5。

根据业务接口最大超时时间和单次请求的timeout综合配置，最大配置不建议超过10，否则会造成单次请求处理时间过长，接口请求阻塞。

排查是否大key较多，建议根据优化大key排查优化。

• string类型控制在10KB以内，hash、list、set、zset元素尽量不超过5000。
• Key的命名前缀为业务缩写，禁止包含特殊字符(比如空格、换行、单双引号以及其他转义字符)。
• Redis事务功能较弱，不建议过多使用。
• 短连接性能差，推荐使用带有连接池的客户端。
• 如果只是用于数据缓存，容忍数据丢失，建议关闭持久化。

Key/热Key的优化方法

什么是大Key，大Key可以分为两种情况？

• Key的Value较大，例如一个String类型的Key大小达到10MB，或者一个集合类型（Hash，List，Set等）的元素总大小达到了100MB。一般我们定义单个String类型的Key大小达到10KB，或者集合类型的Key总大小达到50MB，则定义其为大Key。

• Key的元素较多，例如一个Hash类型的Key，其元素数量达到了10000。一般我们定义集合类型的Key中元素超过5000个，则认为其为大Key。

热Key

通常以一个Key被操作的频率和占用的资源来判定其是否为热Key，例如：

• 某个集群实例一个分片每秒处理10000次请求，其中有3000次都是操作同一个Key。

• 某个集群实例一个分片的总带宽使用（入带宽+出带宽）为100Mbits/s，其中80Mbits是由于对某个Hash类型的Key执行HGETALL所占用。

进行大Key拆分，分为以下几种场景：

1. 该对象为String类型的大Key：可以尝试将对象分拆成几个Key-Value， 使用MGET或者多个GET组成的pipeline获取值，分拆单次操作的压力，对于集群来说可以将操作压力平摊到多个分片上，降低对单个分片的影响。

   • 该对象为集合类型的大Key，并且需要整存整取：在设计上严格禁止这种场景的出现，因为无法拆分。有效的方法是将该大Key从Redis去除，单独放到其余存储介质上。

2. 该对象为集合类型的大Key，每次只需操作部分元素：将集合类型中的元素分拆。以Hash类型为例，可以在客户端定义一个分拆Key的数量N，每次对HGET和HSET操作的field计算哈希值并取模N，确定该field落在哪个Key上，实现上类似于Redis Cluster的计算slot的算法。

   • 无法拆分的大Key建议使用此方法，将不适用Redis能力的数据存至其它存储介质，如SFS或者其余NoSQL数据库，并在Redis中删除该大Key。

注意：

• 禁止使用DEL直接删除大Key，可能会造成Redis阻塞，甚至主备倒换。高版本4.0以上，可以使用unlink。

• 合理设置过期时间并对过期数据定期清理。

• 合理设置过期时间，避免历史数据在Redis中大量堆积。由于Redis的惰性删除策略，过期数据可能并不能及时清理，如果发现Redis过期Key清理较慢，可以手动使用scan进行扫描删除。

热Key,如何处理控制

• 使用读写分离。

如果热Key主要是读流量较大，则可以实现读写分离架构，降低对主节点的影响。还可以增加多个副本以满足读需求，但是备机较多也有相应的影响，即所有的备节点都直接和主节点保持同步，这样能保证备节点之间相互独立，且复制延迟较小。缺点是在备节点数量较多的情况下，主节点的CPU和网络负载会较高。

• 使用客户端缓存/本地缓存。

该方案需要提前了解业务的热点Key有哪些，设计客户端/本地和远端Redis的两级缓存架构，热点数据优先从本地缓存获取，写入时同时更新，这样能够分担热点数据的大部分读压力。缺点是需要修改客户端架构和代码，改造成本较高。

• 设计熔断/降级机制。

热Key极易造成缓存击穿，高峰期请求都直接透传到后端数据库上，从而导致业务雪崩。因此热Key的优化一定需要设计系统的熔断/降级机制，在发生击穿的场景下进行限流和服务降级，保护系统的可用性。