Redis突然出问题了，文件读不进来，好像没法正常读取数据了

（来源：某运维工程师的紧急工作记录）

Redis突然出问题了，文件读不进来，好像没法正常读取数据了，这事儿发生得太突然了，一点预兆都没有，当时我正在处理别的事情，突然就收到了一大堆报警短信，手机嗡嗡嗡地响个不停，全是说业务系统报错，什么“缓存服务不可用”、“获取数据超时”之类的，我心里咯噔一下,第一反应就是Redis那边出幺蛾子了。

我赶紧打开电脑，连上服务器，想看看Redis到底是个什么状况，首先我就试着用命令行工具去连接Redis，想看看能不能连上，执行个简单的命令试试，结果这一连，就发现不对劲了，连接倒是能连上，没有说拒绝连接，但是只要一执行命令，比如最简单的ping命令，或者get一个key，命令行就卡在那里了，光标一直闪，半天没反应，最后报一个超时错误，这感觉就像是Redis虽然站在那里，但是灵魂出窍了,不理人。

然后我马上去看Redis的日志文件，这一看，更是吓了一跳，日志里密密麻麻地刷着好多错误信息，我仔细看了看，反复出现的关键词是“Loading dataset from persistence file”（从持久化文件加载数据集）和“Can‘t read the RDB file”（无法读取RDB文件），日志显示，Redis一直在尝试从硬盘上的一个文件里读取数据，但是好像读不出来，卡在那个步骤了，所以导致Redis自己也无法正常提供服务，它自己都还在努力“醒过来”,自然就没法响应我们外部的命令了。

（来源：同上,后续排查过程）

看到日志里的“RDB文件”报错，我大概猜到问题可能出在哪儿了，Redis为了不让数据丢失，会定期把内存里的数据拍个快照，存成一个叫RDB的文件放在硬盘上，每次Redis重启的时候，它就会去读这个文件，把数据再加载回内存里，这样服务就能恢复到重启前的状态，现在看起来，问题就出在这个RDB文件上，Redis想读它,但是读不动。

我赶紧去检查存放RDB文件的磁盘空间，是不是磁盘满了，导致写文件或者读文件出问题了？我用命令查了一下，磁盘空间是足够的，还剩很多，排除了这个可能性，那会不会是文件权限不对？Redis进程没有权限去读这个文件？我又检查了RDB文件的权限和所属用户，发现也是对的，就是由运行Redis的那个用户拥有的，读权限是开放的,这就奇怪了。

既然权限和空间都没问题，那是不是这个RDB文件本身坏掉了？就像一本书，如果中间有几页被撕掉了或者被墨水糊住了，那读起来肯定就卡壳了，我尝试着用系统自带的文件检查命令看了一下这个RDB文件的大小和基本信息，文件大小看起来是正常的，不是一个空文件或者特别小的文件，但是不是内部结构损坏了,从表面上看不出来。

（来源：与开发同事的沟通记录）

因为情况紧急，业务已经受到影响，我赶紧在群里喊了负责这块的开发同事，我把日志截图和我的排查情况一说，开发同事也觉得大概率是RDB文件损坏了，他告诉我，Redis确实提供了一个工具叫redis-check-rdb，可以用来检查和修复损坏的RDB文件，我像抓到救命稻草一样，立刻找到这个工具,对着那个出问题的RDB文件运行了检查命令。

工具运行后，输出了一堆信息，最后果然提示文件有损坏，发现了一些校验和不匹配或者格式错误的地方，它尝试进行了一些修复，但同时也警告说修复可能不完整，有些数据可能会丢失，看到这个提示，我心里挺忐忑的，数据丢失可是大事，虽然Redis只是缓存，丢了不至于让核心数据完蛋，但大量缓存瞬间失效，会导致所有请求都直接压到后端的数据库上，数据库很可能扛不住这么大的压力,最终整个网站还是可能瘫痪。

（来源：故障处理决策过程）

权衡再三，我们决定不能一直让Redis这样卡着，现在服务是完全不可用，修复RDB文件即使有数据丢失的风险，但至少能让Redis先跑起来，恢复大部分缓存功能，减轻数据库的压力，我们决定采用一个更稳妥的方案：先把这个损坏的RDB文件挪到备份目录，然后重新启动Redis服务，这样做的意思是告诉Redis：“那个启动文件我们不要了，你用一个空的数据集启动吧。”

果然，移走损坏的文件后，Redis很顺利地就启动起来了，启动后里面是空的，没有任何数据，服务暂时恢复了，至少新的请求可以正常写入和读取缓存了，虽然一开始缓存命中率是零，所有请求都去了数据库，数据库压力骤增，但总比完全卡死要好，我们赶紧盯着数据库的监控，幸好数据库还算坚挺,顶住了这波压力。

我们开始排查导致RDB文件损坏的根本原因，是上次Redis持久化的时候服务器突然断电了？还是磁盘有坏道？或者是Redis版本有bug？这件事给我们敲响了警钟，不能只依赖一种持久化方式，我们检查了配置，发现还开启了AOF（另一种日志式的持久化方式），但优先级比RDB低，我们决定后续要优化持久化策略，比如增加AOF的重写频率，或者考虑主从复制，用一台从库来做备份，避免单点故障，这次虽然是有惊无险，但整个过程真是让人头皮发麻，也提醒我们，对于这种核心组件,平时的备份和容灾演练真的太重要了。