百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术教程 > 正文

Redis连接失败问题排查和解决(redis连接报错)

mhr18 2024-11-02 11:53 22 浏览 0 评论

当你的应用服务在连接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连接池优势

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获取值,分拆单次操作的压力,对于集群来说可以将操作压力平摊到多个分片上,降低对单个分片的影响。
  2. 该对象为集合类型的大Key,并且需要整存整取:在设计上严格禁止这种场景的出现,因为无法拆分。有效的方法是将该大Key从Redis去除,单独放到其余存储介质上。
  3. 该对象为集合类型的大Key,每次只需操作部分元素:将集合类型中的元素分拆。以Hash类型为例,可以在客户端定义一个分拆Key的数量N,每次对HGET和HSET操作的field计算哈希值并取模N,确定该field落在哪个Key上,实现上类似于Redis Cluster的计算slot的算法。
  4. 无法拆分的大Key建议使用此方法,将不适用Redis能力的数据存至其它存储介质,如SFS或者其余NoSQL数据库,并在Redis中删除该大Key。

注意:

  • 禁止使用DEL直接删除大Key,可能会造成Redis阻塞,甚至主备倒换。高版本4.0以上,可以使用unlink。
  • 合理设置过期时间并对过期数据定期清理。
  • 合理设置过期时间,避免历史数据在Redis中大量堆积。由于Redis的惰性删除策略,过期数据可能并不能及时清理,如果发现Redis过期Key清理较慢,可以手动使用scan进行扫描删除。

热Key,如何处理控制

  • 使用读写分离。

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

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

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

  • 设计熔断/降级机制。

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

作者:洛神灬殇
链接:https://juejin.cn/post/7199643079284179003
来源:稀土掘金

相关推荐

MySQL数据库中,数据量越来越大,有什么具体的优化方案么?

个人的观点,这种大表的优化,不一定上来就要分库分表,因为表一旦被拆分,开发、运维的复杂度会直线上升,而大多数公司和开发人员是欠缺这种能力的。所以MySQL中几百万甚至小几千万的表,先考虑做单表的优化。...

Redis的Bitmap(位图):签到打卡、用户在线状态,用它一目了然

你是不是每天打开APP,第一时间就是去“签到打卡”?或者在社交软件里,看到你的朋友头像旁边亮着“在线”的绿灯?这些看似简单的功能背后,都隐藏着一个有趣而高效的数据结构。如果让你来设计一个签到系统:用户...

想知道有多少人看了你的文章?Redis HyperLogLog几KB就搞定!

作为一名内容创作者,你每天最期待的,除了文章阅读量蹭蹭上涨,是不是还特别想知道,到底有多少个“独立用户”阅读了你的文章?这个数字,我们通常称为“UV”(UniqueVisitors),它比总阅读量更...

Redis的“HyperLogLog”:统计网站日活用户,省内存又高效的神器

你可能从未听过这个拗口的名字——“HyperLogLog”,它听起来就像是某个高深莫测的数学公式。但请相信我,理解它的核心思想并不难,而且一旦你掌握了它,你会发现它在处理大数据统计问题时,简直就是“救...

阿里云国际站:为什么我的云服务器运行缓慢?

本文由【云老大】TG@yunlaoda360撰写一、网络性能瓶颈带宽不足现象:上传/下载速度慢,远程连接卡顿。排查:通过阿里云控制台查看网络流量峰值是否接近带宽上限34。解决:升级带宽(如从1M提...

Java 近期新闻:Jakarta EE 11和Spring AI更新、WildFly 36.0 Beta、Infinispan

作者|MichaelRedlich译者|明知山策划|丁晓昀OpenJDKJEP503(移除32位x86移植版本)已从“ProposedtoTarget”状态进入到“T...

腾讯云国际站:怎样设置自动伸缩应对流量高峰?

云计算平台服务以阿里云为例:开通服务与创建伸缩组:登录阿里云控制台,找到弹性伸缩服务并开通。创建伸缩组时,选择地域与可用区,定义伸缩组内最小/最大实例数,绑定已有VPC虚拟交换机。实例模板需...

【案例分享】如何利用京东云建设高可用业务架构

本文以2022年一个实际项目为基础,来演示在京东云上构建高可用业务的整个过程。公有云及私有云客户可通过使用京东云的弹性IAAS、PAAS服务,创建高可用、高弹性、高可扩展、高安全的云上业务环境,提升业...

Spring Security在前后端分离项目中的使用

1文章导读SpringSecurity是Spring家族中的一个安全管理框架,可以和SpringBoot项目很方便的集成。SpringSecurity框架的两大核心功能:认证和授权认证:...

Redis与Java集成的最佳实践

Redis与Java集成的最佳实践在当今互联网飞速发展的时代,缓存技术的重要性毋庸置疑。Redis作为一款高性能的分布式缓存数据库,与Java语言的结合更是如虎添翼。今天,我们就来聊聊Redis与Ja...

Redis在Java项目中的应用与数据持久化

Redis在Java项目中的应用与数据持久化Redis简介:为什么我们需要它?在Java项目中,Redis就像一位不知疲倦的快跑选手,总能在关键时刻挺身而出。作为一个内存数据库,它在处理高并发请求时表...

Redis 集群最大节点个数是多少?

Redis集群最大节点个数取决于Redis的哈希槽数量,因为每个节点可以负责多个哈希槽。在Redis3.0之前,Redis集群最多支持16384个哈希槽,因此最大节点数为16384个。但是在Redi...

Java开发岗面试宝典:分布式相关问答详解

今天千锋广州Java小编就给大家分享一些就业面试宝典之分布式相关问题,一起来看看吧!1.Redis和Memcache的区别?1、存储方式Memecache把数据全部存在内存之中,断电后会挂掉,数据不...

当Redis内存不足时,除了加内存,还有哪些曲线救国的办法?

作为“速度之王”的Redis,其高性能的秘密武器之一就是将数据存储在内存中。然而,内存资源是有限且昂贵的。当你的Redis实例开始告警“内存不足”,或者写入请求被阻塞时,最直接的解决方案似乎就是“加内...

商品详情页那么多信息,Redis的“哈希”如何优雅存储?

你每天网购时,无论是打开淘宝、京东还是拼多多,看到的商品详情页都琳琅满目:商品名称、价格、库存、图片、描述、评价数量、销量。这些信息加起来,多的惊人。那么问题来了:这些海量的商品信息,程序是去哪里取出...

取消回复欢迎 发表评论: