共计 1596 个字符，预计需要花费 4 分钟才能阅读完成。
1、应用简单度过高的命令（例如 SORT/SUION/ZUNIONSTORE/KEYS），或一次查问全量数据（例如 LRANGE key 0 N，但 N 很大）
剖析：a) 查看 slowlog 是否存在这些命令 b) Redis 过程 CPU 使用率是否飙升（聚合运算命令导致）
解决：a) 不应用简单度过高的命令，或用其余形式代替实现（放在客户端做）b) 数据尽量分批查问（LRANGE key 0 N，倡议 N <=100，查问全量数据倡议应用 HSCAN/SSCAN/ZSCAN）
2、操作 bigkey
剖析：a) slowlog 呈现很多 SET/DELETE 变慢命令（bigkey 分配内存和开释内存变慢）b) 应用 redis-cli -h $host -p $port –bigkeys 扫描出很多 bigkey
解决：a) 优化业务，防止存储 bigkey b) Redis 4.0+ 可开启 lazy-free 机制
3、大量 key 集中过期
剖析：a) 业务应用 EXPIREAT/PEXPIREAT 命令 b) Redis info 中的 expired_keys 指标短期突增
解决：a) 优化业务，过期减少随机工夫，把工夫打散，加重删除过期 key 的压力 b) 运维层面，监控 expired_keys 指标，有短期突增及时报警排查
4、Redis 内存达到 maxmemory
剖析：a) 实例内存达到 maxmemory，且写入量大，淘汰 key 压力变大 b) Redis info 中的 evicted_keys 指标短期突增
解决：a) 业务层面，依据状况调整淘汰策略（随机比 LRU 快）b) 运维层面，监控 evicted_keys 指标，有短期突增及时报警 c) 集群扩容，多个实例加重淘汰 key 的压力
5、大量短连贯申请
剖析：Redis 解决大量短连贯申请，TCP 三次握手和四次挥手也会减少耗时
解决：应用长连贯操作 Redis
6、生成 RDB 和 AOF 重写 fork 耗时重大
剖析：a) Redis 变慢只产生在生成 RDB 和 AOF 重写期间 b) 实例占用内存越大，fork 拷贝内存页表越久 c) Redis info 中 latest_fork_usec 耗时变长
解决：a) 实例尽量小 b) Redis 尽量部署在物理机上 c) 优化备份策略（例如低峰期备份）d) 合理配置 repl-backlog 和 slave client-output-buffer-limit，防止主从全量同步 e) 视状况思考敞开 AOF f) 监控 latest_fork_usec 耗时是否变长
7、AOF 应用 awalys 机制
剖析：磁盘 IO 负载变高
解决：a) 应用 everysec 机制 b) 失落数据不敏感的业务不开启 AOF
8、应用 Swap
剖析：a) 所有申请全副开始变慢 b) slowlog 大量慢日志 c) 查看 Redis 过程是否应用到了 Swap
解决：a) 减少机器内存 b) 集群扩容 c) Swap 应用时监控报警
9、过程绑定 CPU 不合理
剖析：a) Redis 过程只绑定一个 CPU 逻辑核 b) NUMA 架构下，网络中断处理程序和 Redis 过程没有绑定在同一个 Socket 下
解决：a) Redis 过程绑定多个 CPU 逻辑核 b) 网络中断处理程序和 Redis 过程绑定在同一个 Socket 下
10、开启通明大页机制
剖析：生成 RDB 和 AOF 重写期间，主线程解决写申请耗时变长（拷贝内存正本耗时变长）
解决：敞开通明大页机制
11、网卡负载过高
剖析：a) TCP/IP 层提早变大，丢包重传变多 b) 是否存在流量过大的实例占满带宽
解决：a) 机器网络资源监控，负载过高及时报警 b) 提前布局部署策略，访问量大的实例隔离部署
总之，Redis 的性能与 CPU、内存、网络、磁盘都非亲非故，任何一处产生问题，都会影响到 Redis 的性能。
次要波及到的包含业务应用层面和运维层面：业务人员须要理解 Redis 根本的运行原理，应用正当的命令、躲避 bigke 问题和集中过期问题。运维层面须要 DBA 提前布局好部署策略，预留足够的资源，同时做好监控，这样当产生问题时，可能及时发现并尽快解决。
