Redis数据丢失，究竟是误删所致，亦或是被黑造成，通过三个步骤，十分钟便可查得清楚，得以明晰是什么缘由。
确认数据是否真被清空
首先，运用命令行工具去连接那台Redis服务器，接着输入KEYS 以此查看全部的键。在二零二五年三月份的时候，杭州有一家电商公司的运维人员，正是借助这条命令，发觉原本那五千多个缓存键居然全都没了。要是返回一个空列表或者(empty array)的话，先别忙着下结论，然后再去执行INFO keyspace，查看db0的keys统计项。有一个设于上海的金融科技公司，于去年碰到过误判方面的例子，在其执行KEYS 之际，刚好遇上Redis在进行快照操作，于是临时给出空的结果，然而实际的数据仍是存在的。
日志的翻动状况乃是用以确证清空时刻的关键绝对证据，默认的日志存放于/var/log/redis/redis-server.log之处，运用grep -i"flush"去实施过滤操作。身处北京的某个社交平台的运维团队，于2024年12进行故障排查工作期间，洞察到日志里面清清楚楚记录着timestamp:* DB flushed，其精度精确到了毫秒。倘若日志呈现 keys 数量由几万一下子剧降至 0，大体上能够确凿认定乃是被人为予以清空。要记得与此同时去查看系统日志/var/log/syslog，瞧瞧在那个时间段有没有 Redis 进程异常退出的相关记录。
检查配置找出自动清空开关
翻开redis.conf这个配置文件，着重去瞧一瞧maxmemory-policy此参数。在广州有一家从事游戏相关业务的公司，其曾由于设置成了volatile-lru这种情况，致使在内存压力之下自动将所有带有过期时间设定的key给删除掉了，进而该公司的业务出现宕机状况，持续长达两小时之后才得以恢复正常。要是这个参数是，`allkeys-lru`，或者，`allkeys-random`，那么，Redis呢，将会在内存不足之际呢，没有什么区别地删除数据，看上去的话，就好像是被清空了一样。
还有一个危险的参数，是那rename - command FLUSHALL以及rename - command FLUSHDB。在深圳地域的某家从事跨境电商业务的公司，于2025年年初的时候，被内部的员工，借助未进行改名操作的FLUSHALL命令，将整个数据库给清空了。要核查配置之中，是不是把存在高风险的命令，重新命名为很难去猜解出来的字符串，又或者是直接使用""将它们给禁用掉了。很多默认配置根本没改这两个命令，等于把大门钥匙挂在锁上。
系统日志里找黑手痕迹
在服务器上进行登录操作，之后执行 last -x 命令，以此查看近期的登录记录情况。南京地区某政务云在 2024 年 11 月遭受攻击之后，借助本条命令查看到在凌晨 3 点，有陌生的 IP 通过 SSH 成功实现了登录，随后 Redis 日志当中就出现了 FLUSHALL 的记录情况。要着重对 root 和 redis 运行用户的登录历史展开排查工作，并且结合 /var/log/auth.log 来查看在当时那个时间点有没有出现批量失败尝试之后突然成功的记录情况。
攻击者常常以扫描工具寻觅未获授权的Redis实例，去搜索位于/var/log/redis/redis-server.log里的Possible SECURITY ATTACK字样，这属于Redis内在的保护机制，一旦检测到高危命令便会记警告。成都有一家处于初创阶段的公司，在2025年的1月，出现了数据丢失 的情况，之后通过查看日志发现，里面存在大量由以104.28开头的IP所发起的CONFIG SET命令尝试，显而易见这属于自动化攻击脚本。
硬件故障导致的数据看起来丢失
磁盘被写满的情况下，会致使Redis没办法进行持久化操作，一旦重启，数据就会全部消失不见。通过使用df -h /var/lib/redis来查看磁盘占用情况，去年的时候，武汉有一家从事物流业务的公司，其Redis服务器正是由于日志文件将磁盘空间完全占据，导致AOF重写操作失败，在机器重启以后，整个数据库呈现出一片空白，什么数据都没有的状态。内存方面的问题更为隐蔽，去执行一下 dmesg | grep -i redis 来瞧一瞧内核日志。要是出现了 Out of memory: Kill process 这样的字样，那就表明 Redis 是被 OOM killer 给强制终止掉的，而那些还没有落盘的数据就全都丢失了。
CPU出现异常负载的情况，也存在着有可能会间接地致使数据出现丢失的状况。在西安有一家在线教育平台，在2025年2月的时候，Redis突然出现了丢失数据的情况，经过排查之后发现，处于同一物理机上的另外一个Java应用，疯狂地占用着CPU，进而使得Redis的响应变得缓慢，当客户端进行超时重试的时候，因为错误处理得不恰当，从而把缓存全部删除了。硬件方面的问题通常情况下不会直接去删除key，然而呈现出来的后果看起来却是完全一样的。
复制链路断裂酿成惨剧
实施INFO replication去查看主从状态，要是role属于slave，那就查看master_link_status是不是为up，苏州某银行在2024年末的时候开展灾备演练，期间从库错误地被提升为主库，然而数据却仍旧停留在三天之前的快照，上层应用过来写入数据致使大量key被覆盖，等到发现的时候主库已然被污染，检查复制偏移量，slave读取的偏移量跟master写入的偏移量相差过大，这表明同步处于严重滞后的状态。
存在一些团队，出于性能方面的考量，将主库持久化予以关闭，转而完全依赖从库的备份呢。于重庆的一家专门从事直播业务的公司，就在这一状况上遭遇挫折：当主库出现宕机情况并重新启动的时候，呈现为空的状态，相应地，从库自动同步了空的数据集，最终，两边的数据都彻底丧失。要进行核对，看配置之中是不是启动了奴从只读这一参数，要是该参数被设置为不同意，那么在从库方面也存在能够被写入的可能性，进而造成在数据方面出现分叉的现象，甚而相互涵盖替换。
日常预防要落在具体动作上
将AOF持久化单纯设成appendonly yes是不行的，还需要与auto-aof-rewrite-percentage以及auto-aof-rewrite-min-size相结合。杭州有一家支付类公司所做的设置较为合理，其能够做到每周自动进行一次rewrite，在上个月误执行FLUSHDB之后，直接重启了Redis，AOF文件对之前的所有操作进行了重放，仅仅丢失了十秒钟的数据量。用于表示15分钟之内有至少1个key发生变化便进行快照以至少能找回整点数据的RDB快照也是颇为实用的，save 900 1。
拜访管控务必要贯彻至IP白名单。上海某个别的证券组织将Redis绑定于127.0.0.1依旧不足够，又运用iptables限定只有应用服务器才能够访问6379 端口。密码得设定够长度，别采用redis123这类的字典词。监控告警设立三级阈值：key数量骤降20%发送邮件，下降50%拨打电话，降低80%直接停机以保全数据。一家位于郑州的电商公司的这套机制，在去年挽救了他们的命运，凌晨时分，刚发出FLUSHALL命令便遭受攻击，监控随即自动断网并进行备份，最终仅损失了9个key。
你有没有碰到过Redis突然间就丢失数据的情景呀，那个时候耗费了多长时间才把导致的原因给找出来呢？
Comments NOTHING