1.内因：
A.api或数据结构使用不合理： 如：对一个包含上万元素的hash结构执行hgetall操作,数据量大且命令复杂度O(n),必然阻塞
B.慢查询：前面有介绍
C.大对象：
执行./redis-cli -h {ip} -p {port} --bigkeys命令可找出当前最大对象出来,接着便可对大对象进行调整或缩减或分成多个小对象
生产环境可执行debug object key查看key对应value序列化后的长度,或strlen key查看key的字节数
主动检测大对象：scan + debug object key命令
可使用info commandstats命令分析命令不合理的开销时间，会返回最近执行命令的调用次数、耗时等信息
D.CPU饱和：redis单线程只能使用一个CPU,饱和将无法处理更多命令 可以执行命令redis-cli -h {ip} -p {port} --stat获取当前redis使用情况
E.持久化相关阻塞：
a.fork阻塞： fork操作发生在rdb和aof重写时,redis主线程调用fork操作产生共享内存的子进程,由子进程完成持久化文件重写工作,若fork操作本身耗时过长,则必会导致主线程阻塞；可执行info stats命令获取到latest_fork_usec指标,表示redis最近一次fork操作耗时,若超过1s,则需要做出优化调整
b.aof刷盘阻塞： 当开启aof持久化功能时,文件刷盘的方式一般采用每秒一次,后台线程每秒对aof文件做fsync操作,硬盘压力过大时,fsync操作需要等待,直到写入完成如果主线程发现距离上一次的fsync成功超过2秒,为了数据安全性它会阻塞直到后台线程执行fsync操作完成,这种阻塞行为主要是硬盘压力引起,可查看Redis日志识别出这种情况,当发生这种阻塞行为时,会打印如下日志：
亦可查看info persistence统计中的aof_delayed_fsync指标,每次发生aof刷盘阻塞主线程时会累加
c.HugePage写操作阻塞(求大佬指教)： 子进程在执行重写期间利用Linux写时复制技术降低内存开销,因此只有写操作时Redis才复制要修改的内存页,对于开启Transparent HugePages的操作系统,每次写命令引起的复制内存页单位由4K变为2MB,放大了512倍,会拖慢写操作的执行时间,导致大量写操作慢查询
2.外因：
A.CPU竞争：
a.进程竞争：当redis与其他cpu密集型服务部署在一起时可能发生
b.绑定cpu：由于redis单线程架构,为充分利用多核cpu,一台机器部署多个redis并将redis进程绑定到cpu(可降低cpu上下文切换开销),当redis父进程fork操作创建子进程进行rdb/aof重写(很耗cpu)时,父子进程共享同一cpu,将影响redis的稳定性
B.内存交换：指操作系统把redis使用的部分内存换出到硬盘,导致交换后redis性能急剧下降(内存与硬盘处理速度不在一个数量级),可如下查看内存交换信息获取redis进程号→cat /proc/进程号/smaps | grep Swap
C.网络问题：
1)连接拒绝：
a).网络闪段：网络割接或者带宽耗尽
b).连接拒绝：超过客户端最大连接数
c).连接溢出：指操作系统或redis客户端在连接时的问题，2种原因：
原因1：进程限制 操作系统会对进程使用的资源做限制，其中之一便是对可打开最大文件数进行控制，ulimit –n可查看,超过则发送too many open files错误
原因2：backlog队列溢出 系统对于特定端口的tcp连接使用backlog队列保存，redis默认长度为511，通过tcp-backlog参数设置，高并发场景下可增大该值，但必须大于操作系统允许值才生效，系统默认backlog为128，使用echo511>/proc/sys/net/core/somaxconn命令进行修改，可通过netstat -s命令获取因队列溢出造成的连接拒绝统计
2)网络延迟： 可使用redis提供的测试工具进行测试,在redis-cli -h {ip} -p {port}命令后加入参数进行测试：
--latency：持续进行延迟测试,分别统计：最小值、最大值、平均值、采样次数
--latency-history：统计结果同—latency,但默认每15秒完成一行统计,可通过-i参数控制采样时间
--latency-dist：使用统计图的形式展示延迟统计,每1秒采样一次
3)网卡软中断(求大佬指教)：
网卡软中断是指由于单个网卡队列只能使用一个CPU,高并发下网卡数据交互都集中在同一个CPU,导致无法充分利用多核CPU的情况,网卡软中断瓶颈一般出现在网络高流量吞吐的场景