最近测试环境的redis经常性发生某些key丢失的问题，最终的找到的问题让人大吃一惊。
复盘一下步骤：
1、发现问题
不知道从某天开始，后台经常报错，原因是某些key丢失，一开始不在意，以为是小bug，后来越来越频繁。
2、检查代码
看看是不是有误删除的情况，这些key的访问范围很小，压根没有删除的逻辑，也没有设置过期时间，通过ttl命令检查也是如此。
3、实在没辙，开启monitor监控
本以为终极大招肯定能发现问题，陆续抓取了几个出问题时段的全部redis指令序列，没有发现任何可疑的指令，内心奔溃。
4、检查redis.log
终于发现了这样一段
29014:M 25 Apr 00:10:47.906 - DB 0: 4121 keys (4061 volatile) in 8192 slots HT.
29014:M 25 Apr 00:10:47.906 - 100 clients connected (0 slaves), 4476640 bytes in use
29014:M 25 Apr 00:10:48.038 - Accepted xx.xx.xx.xx:57998
29014:M 25 Apr 00:10:48.119 # Failed opening the RDB file backup.db (in server root dir /etc/cron.d) for saving: Permission denied
29014:M 25 Apr 00:10:48.279 # Failed opening the RDB file root (in server root dir /etc/cron.d) for saving: Permission denied
29014:M 25 Apr 00:10:48.358 # Failed opening the RDB file root (in server root dir /etc/cron.d) for saving: Permission denied
29014:M 25 Apr 00:10:48.385 - Client closed connection
29014:M 25 Apr 00:10:48.397 - Accepted xx.xx.xx.xx:52018
29014:M 25 Apr 00:10:52.915 - DB 0: 2 keys (0 volatile) in 4 slots HT.在00:10:48.119 这个时刻，尝试从/etc/cron.d下面的backup.db恢复数据，然后出错，然后就数据库被清空。
整个过程速度非常快，客户端都没有感觉。
我们内部没有人会在这个时刻去执行这个操作，redis的配置文件里面也不会有类似的配置。
网上搜索了一下，类似的情况说明，这是有人在尝试通过redis来攻击你的服务器。
由于机房设备不足，临时在腾讯云服上搭建了测试环境，没有做过多的安全性设置，redis也没有设置密码。
接下来做了两个设置：
1、redis设置了一个较为复杂的密码；
2、禁用了config指令
接下来几天，不再有类似问题。
折腾了几天，一开始完全没往安全这个方向去考虑，充分说明专业的事情还得专业的人来干，我这个运维临时工是不行的。