TroubleShooting-排障是DBA一项重要技能，通过故障表现的症状，先让业务快速恢复止损，同时分析故障的根因(rootCause),给出解决方案并从根本上修复故障，最后总结从产品或流程上怎么规避同类型故障再次发生。
DBA排障很像医生治病、刑警破案。
医生通过了解病人病情症状(故障症状），先让病人病情缓解(服务止损）类似止痛，同时分析病灶（故障根因），给出可行的治疗方案（故障解决方案），病人完全恢复；最后给出医疗建议如何预防病情或避免恶化(故障规避）；当然还有现多的类似急救(紧急故障-7位数级损失）、会诊、不治、AI医疗(AI故障根因分析）、医疗事故(背锅)；其实很多相通之处。
刑警通过真凶（故障根因）留下的犯罪现场(故障症状），根据罗卡定律，各种技术分析和寻找证据，最终找出真凶和证据。（段子很多，先回到主题）
在Redis早期的运维过程中，也遇过不少Redis故障，现总结其中几个有意思的案例，希望对刚开始用Redis的DBA同学有所帮助。故障因与业务、故障场景结合较密切(脱敏)，笔者尽量提炼成技术和还原现场；故障系列文章包括以下几部分：
故障背景：主要交待技术和故障背景[可选]；
故障描述：故障的简单描述、根本原因和影响；
故障监控告警：故障相关的监控告警信息；
故障分析：文章核心 提供类似故障的分析思路、和技术点；
故障阶段性总结：文章核心 总结类似故障的通用性预防；
本文是Redis故障案例(一)关于一次Redis特定key丢失排查分析。
1 故障背景
A业务有一个3分片的Redis Cluster缓存集群,会定期生成数据写入Redis;某一天，A业务的研发工程师(下文简称RD)突然找到DBA,很激动地说：“我们Redis集群突然掉很多key…” ,然后故事就开始了….
RD: “我们Redis集群中，以“t_list:”前缀的90000多key今早发现都掉了，其他key还在，是不是DBA有清理操作啊？”
DBA: “没有维护性操作(一脸懵B和无辜),先止损，把Key从Primary store中导入Redis；”
RD: “已经从MySQL把key导入到Redis，现在业务功能恢复，影响很小。但请帮忙追查原因。“
DBA: “这部分key确认最近一次还在是什么时候? 然后最早发现丢失是在什么时候？” 备注:DBA开始和当事人了解案发时间，为排查问题提供依据。
RD: “昨晚20:30前key肯定还在，最早发现key不见是今早9:20同事发现新测试功能有异常” 备注：灰度功能
DBA: ”好的，我先分析一下原因，有结果了通知你；定位问题前，你也关注一下服务，避免问题二次发生”。
然后RD就下楼了，DBA扣上他的几十元买来的boss耳机，开始自言自语Troubleshooting.
2 故障描述
因RD1同学为重写t_list的90000多个KEY, 通过keys t_list*命令获取并删除，但未及时把key新内容重到redis中；使得RD2同学以为数据灵异丢失。但因为是灰度功能使用数据，服务影响范围较小。我有几张阿里云幸运券分享给你，用券购买或者升级阿里云相应产品会有特惠惊喜哦！把想要买的产品的幸运券都领走吧！快下手，马上就要抢光了。
3 故障告警
1 业务告警缺失；见故障总结
2 Redis侧无法监控此类告警
4 故障分析
通过RD提供的线索：
特定t_list:前缀90000个List元素丢失；
数据丢失时间范围前日20：30~9:20之间（案发时间段，分析各种监控范围）。
通过故障症状初步分析，故障可能的根因：
执行了flushall/flushdb命令删除所有key,其他key是后来写入的，造成了只丢失t_list的假象
这90000个List元素因执行LPOP/RPOP，导致key被删除的现象;(List中元素被全部pop完后，list相当于被删除了）
这部分key因设置了TTL，在此期间内全部过期，被redis自动删除;
这部分key因LRU淘汰，被redis全部驱逐淘汰；
程序BUG或人为删除导致；
每个可能故障根因排查分析：
点击链接阅读全文：yq.aliyun.com/articles/259109
