摘抄来自：https://zhuoroger.github.io/
1、slowlog和排队延时
slowlog是排查性能问题关键监控指标。它是记录Redis queries运行时间超时特定阀值的系统。这类慢查询命令被保存到Redis服务器的一个定长队列，最多保存slowlog-max-len(默认128）个慢查询命令。
当慢查询命令达到128个时，新产生的慢查询被加入前，会从队列中删除最旧的慢查询命令。
如MySQL/MongoDB等常见数据库，慢查询的query_time都会包含命令所有耗时，包含锁等待这类时间； 而Redis的慢查询query_time只记录自己“被cpu服务的时间”，不包含排队等待、IO等待（如AOF SYNC）这类时间。在理想状态下，Redis单实例能处理8~10w的QPS, 如果大量的redis命令大量耗时大于1ms, 其实QPS只能达到1000甚于几百。
Redis出现耗时大的命令，导致其他所有请求被阻塞等待，redis处理能力急剧退化，易导致整个服务链雪崩。
用户反应的查询较慢有时候在slowlog查询不到，所以平常不仅要关注slowlog时间，还要关注命令排队时间。
2、redis数据丢失
常见Redis数据丢失的情况
- 程序bug或人为误操作
- 因客户端缓冲区内存使用过大，导致大量键被LRU淘汰
- 主库故障后自动重启，可能导致数据丢失
- 网络分区的问题，可能导致短时间的写入数据丢失
- 主从复制数据不一致，发生故障切换后，出现数据丢失
- 大量过期键，同时被淘汰清理
主库故障后自动重启，可能导致数据丢失:
这种故障发生，极有可能数据全部丢失。
问题发生的现象：时间点T1,主库故障关闭了，因设置有自动重启的守护程序，时间点T2主库被重新拉起，因(T2-T1)时间间隔过小，未达到Redis集群或哨兵的主从切换判断时长；这样从库发现主库runid变了或断开过，会全量同步主库rdb清理，并清理自己的数据。
而为保障性能,Redis主库往往不做数据持久化设置，那么时间点T2启动的主库，很有可能是个空实例（或很久前的rdb文件）。
这种问题发生时间间隔，一般小于1分钟，可能监控告警无法感知到。
这类总是的预防和监控：
1 强烈反对Redis粗暴地设置自动重启
2 这种监控键个数的变化，缓存命中率，同时ELK类型准实时监控redis日志变化并告警
建议：数据库这类重“状态性”服务，不建议程序暴力自动重启