Jedis 参数异常引发服务雪崩案例分析

一、背景介绍

Redis作为互联网业务首选的远程缓存工具而被被大家熟知和使用，在客户端方面涌现了Jedis、Redisson、Lettuce等，而Jedis属于其中的佼佼者。

目前笔者的项目采用Redis的3.x版本部署的集群模式（多节点且每个节点存在主从节点），使用Jedis作为Redis的访问客户端。

日前Redis集群中的某节点因为宿主物理机故障导致发生主从切换，在主从切换过程中触发了Jedis的重试机制进而引发了服务的雪崩。

本文旨在剖析Redis集群模式下节点发生主从切换进而引起服务雪崩的整个过程，希望能够帮助读者规避此类问题。

二、故障现场记录

消息堆积告警

【MQ-消息堆积告警】

• 告警时间：2022-11-29 23:50:21
• 检测规则: 消息堆积阈值:-》异常( 100000)
• 告警服务：xxx-anti-addiction
• 告警集群：北京公共
• 告警对象：xxx-login-event-exchange
  /xxx-login-event-queue
• 异常对象(当前值):159412

说明：

• 2022-11-29 23:50:21收到一条RMQ消息堆积的告警，正常情况下服务是不会有这类异常告警，出于警觉性开始进入系统排查过程。
• 排查的思路基本围绕系统相关的指标：系统的请求量，响应时间，下游服务的响应时间，线程数等指标。

说明：

排查系统监控之后发现在故障发生时段服务整体的请求量有大幅下跌，响应的接口的平均耗时接近1分钟。

服务整体出于雪崩状态，请求耗时暴涨导致服务不可用，进而导致请求量下跌。

说明：

排查服务的下游应用发现故障期间Redis的访问量大幅下跌，已趋近于0。

项目中较长用的Redis的响应耗时基本上在2s。

说明：

排查系统对应的线程数，发现在故障期间处于wait的线程数大量增加。

说明：

事后运维同学反馈在故障时间点Redis集群发生了主从切换，整体时间和故障时间较吻合。

综合各方面的指标信息，判定此次服务的雪崩主要原因应该是Redis主从切换导致，但是引发服务雪崩原因需要进一步的分析。

三、故障过程分析

在进行故障的过程分析之前，首先需要对目前的现象进行分析，需要回答下面几个问题：

• 接口响应耗时增加为何会引起请求量的陡增？