情況：
設置了key，默認永久，但第二天再看，緩存消失了。很奇怪。
看了網上的分析，極有可以被黑了。
感染原因如下：
Redis 默認情況下，會綁定在 0.0.0.0:6379，在沒有利用防火牆進行屏蔽的情況下，將會將 Redis 服務暴露到公網上，如果在沒有開啟認證的情況下，可以導致任意用戶在可以訪問目標服務器的情況下未授權訪問 Redis 以及讀取 Redis 的數據。攻擊者在未授權訪問 Redis 的情況下利用 Redis 的相關方法，可以成功將自己的公鑰寫入目標服務器的 ~/.ssh 文件夾的 authotrized_keys 文件中，進而可以直接登錄目標服務器；如果 Redis 服務是以 root 權限啟動，可以利用該問題直接獲得服務器 root 權限。
經過對捕獲的事件進行分析，整個入侵流程大概是包含以下幾個環節：
- 掃描開放 6379 端口的 Linux 服務器（后續感染掃描網段為 1.0.0.0/16 到 224.255.0.0/16 ）
- 通過 redis-cli 嘗試連接 Redis 並執行預置在.dat 文件里的利用命令將 Redis 的數據文件修改為 /var/spool/cron/root，然后通過在 Redis 中插入數據，將下載執行腳本的動作寫入 crontab 任務
- 通過腳本實現以上的相關行為，完成植入並啟動挖礦程序
Redis 服務加固
- 導致入侵的主要原因是 Redis 未授權訪問問題，所以如果要扼制入侵的入口，需要針對 Redis 服務進行加固，避免黑客通過該途徑進行入侵植入挖礦蠕蟲。
- 如無必要，修改 bind 項，不要將 Redis 綁定在 0.0.0.0 上，避免 Redis 服務開放在外網，可以通過 iptables 或者騰訊雲用戶可以通過安全組限制訪問來源
- 在不影響業務的情況，不要以 root 啟動 Redis 服務，同時建議修改默認的 6379 端口，大部分針對 Redis 未授權問題的入侵都是針對默認端口進行的
- 配置 AUTH，增加密碼校驗，這樣即使開放在公網上，如果非弱口令的情況，黑客也無法訪問 Redis 服務進行相關操作
- 使用 rename-command CONFIG "RENAME_CONFIG"重命名相關命令，這樣黑客即使在連接上未授權問題的 Redis 服務，在不知道命令的情況下只能獲取相關數據，而無法進一步利用
以上來源：https://www.v2ex.com/t/584369#reply52