Redis 连接数耗尽导致服务不可用故障处理记录

Redis 连接数耗尽导致服务不可用故障处理记录

故障概述

时间:2026-02-20 06:34 ~ 09:18
影响范围:10.194.106.240 跨境 Redis 服务
故障现象
– 内存使用率达到 100%
– 连接数高达 20000+,触发 maxclients 限制
– Redis 服务拒绝新连接,应用服务不可用

根本原因:应用服务连接未正常释放,产生大量僵尸连接,最终耗尽 Redis 连接池

告警信息

告警 1:Maxmemory 不足

告警级别: warning
开始时间: 2026-02-20 06:43:55
结束时间: 2026-02-20 09:18:25
主机: 10.194.106.240
详情: 超出设置最大内存(> 80%),当前值 = 80.01%

告警 2:Redis 应用不可用

告警级别: critical
开始时间: 2026-02-20 06:39:25
结束时间: 2026-02-20 06:41:55
主机: 10.194.106.240
详情: Redis 应用不可达,当前值 = 0

告警 3:拒绝连接数异常

告警级别: critical
开始时间: 2026-02-20 06:34:25
结束时间: 2026-02-20 06:36:25
主机: 10.194.106.240
详情: Redis 拒绝连接,连接数配置已达上限,当前值 = 4489

故障排查过程

1. 连接状态分析

通过 client list 命令查看连接详情,发现存在大量僵尸连接:

# 查看所有客户端连接的空闲时间
redis-cli -a redispasswd client list | grep idle= | more

image-20260306113607683

问题定位:应用服务端连接未正常释放,持续占用连接资源,最终达到 maxclients 上限

img

2. 临时处理措施

操作:对 3 台跨境 Redis 设置连接超时参数

# 设置空闲连接超时时间为 600 秒(10 分钟)
CONFIG SET timeout 600

3. 应用服务重启

协调技术团队重启应用服务后,连接数恢复正常,Redis 服务恢复可用状态:

重启前连接状态

image-20260306114432525

重启后连接恢复正常

image-20260306113530153

优化方案

常用运维命令

# 连接 Redis
redis-cli -a redispasswd 

# 查看当前最大连接数配置
CONFIG GET maxclients

# 动态调整最大连接数(临时生效)
CONFIG SET maxclients 20000

# 查看连接超时配置
CONFIG GET timeout

# 设置连接超时时间(单位:秒,0 表示永不超时)
CONFIG SET timeout 1800

# 查看所有客户端连接列表
client list

# 查看空闲连接详情(分页查看)
./redis-cli -a redispasswd  client list | grep idle= | more

短期优化措施

与技术同事沟通后,针对当前架构进行以下优化:

1. 连接数扩容

根据业务增长情况,逐步调整最大连接数配置:

时间节点 maxclients 配置 说明
节前 10000 初始配置
第一次调整 20000 连接数告警后扩容
当前配置 30000 应对业务高峰
# 动态调整最大连接数(重启后失效,需写入配置文件持久化)
CONFIG SET maxclients 30000

2. 连接超时机制优化

配置项 原配置 优化后 最终调整
timeout 0(永不超时) 600 秒(10 分钟) 1800 秒(30 分钟)
# 设置连接空闲超时时间
CONFIG SET timeout 1800

优化说明
– timeout = 0 会导致僵尸连接永久占用资源
– timeout = 600 可能对某些长时间空闲的正常连接造成影响
– timeout = 1800 在清理僵尸连接和保证正常业务之间取得平衡

优化效果

设置超时后,现有僵尸连接被自动清理,连接数回落到正常水平:

image-20260306115126196

image-20260306115102750

image-20260306115043798

长期解决方案

架构调整计划(已与技术团队确认):

  1. 消息队列迁移
    • 跨境服务不再使用 Redis 作为消息队列
    • 迁移至 Kafka + OSS 存储方案
    • 提升消息处理能力和数据持久化可靠性
  2. 架构问题解决
    • 解决当前单机 Redis 无法负载均衡的问题
    • 解决无法动态切换的高可用性问题
    • 降低单点故障风险

架构对比

image-20260306114232564

问题总结

根因分析

  1. 应用层问题:应用服务连接池管理不当,连接未正常释放
  2. 配置问题:Redis timeout 设置为 0,无法自动清理空闲连接
  3. 架构问题:3 台 Redis 均为单机模式,无法实现负载均衡和高可用

经验教训

  1. 监控告警优化
    • Redis 连接数监控应设置合理阈值告警(建议 70% 即告警)
  2. 配置规范
    • 必须配置 timeout 参数,避免僵尸连接累积
    • timeout 值需根据业务特点合理设置(建议 1800-3600 秒)
    • 重要配置变更需持久化到配置文件,避免重启后失效
  3. 应用层优化
    • 应用服务应正确使用连接池,确保连接及时释放
    • 实现连接池监控,及时发现连接泄漏问题
    • 增加连接异常重试和降级机制
  4. 架构改进
    • 生产环境 Redis 应采用集群或哨兵模式,提高可用性
    • 避免将 Redis 用于不适合的场景(如大量消息队列)
    • 建立容量规划机制,提前预估资源需求
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇