情况：
设置了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