最近測試環境的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指令
接下來幾天，不再有類似問題。
折騰了幾天，一開始完全沒往安全這個方向去考慮，充分說明專業的事情還得專業的人來干，我這個運維臨時工是不行的。