发现阻塞
线上应用服务最先感知到，可在应用方加入异常统计并通过邮件、短信、微信报警。
借助日志系统，统计异常和触发报警逻辑
借助Redis监控系统发现阻塞问题，触发报警。推荐CacheCloud系统。
内在原因
API或数据结构使用不合理
对于高并发场景，避免在大对象上执行算法复杂度超过O(n)O(n)的命令。
发现慢查询：slowlog get {n}
发现大对象：redis-cli -h{ip} -p{port} bigkeys
CPU饱和
CPU饱和指redis把单核CPU跑到100%。
top命令查看redis进程CPU使用率
redis-cli -h{ip} -p{port} –stat获取当前redis使用情况，判断并发是否达到极限
info commandstats 分析命令不合理开销时间，可能过度内存优化
持久化阻塞
1、fork阻塞
发生在RDB或AOF重写时，redis主线程调用fork产生子进程完成持久化文件重写
使用info stats命令获取lastest_fork_usec指标，表示redis最近一次fork操作耗时
2、AOF刷盘阻塞
开启AOF，文件刷盘一般每秒一次，硬盘压力过大时，fsync需要等待写入完成
查看redis日志或info persistence统计中的aof_delayed_fsync指标
可使用iotop差可能哪个进程消耗过多的硬盘资源
3、HugePage写操作阻塞
对于开启Transparent HugePages的操作系统，每次写命令引起的复制内存页单位由4KB变为2MB
会拖慢写操作的执行时间，导致大量写操作慢查询
外在原因
CPU竞争
1、进程竞争：redis是典型的CPU密集型应用。使用top、sar命令定位CPU消耗的时间点和进程
2、绑定CPU：常见优化是把redis进程绑定到CPU上，较低CPU上下文切换开销，如果fork子进程做了CPU绑定，则父子进程存在激烈的CPU竞争，极大影响redis稳定性。
内存交换
如果操作系统把redis使用的内存换出到硬盘上，会导致发生交换后的redis性能急剧下降。
识别redis内存交换的检查方法：
1、查询redis进程号
redis-cli info server | grep process_id
2、根据进程号查询内存交换信息
cat /proc/{process_id}/smaps | grep Swap
如果交换量都是0KB或者个别4KB，是正常现象。
预防内存交换：
1、保证机器充足的可用内存
2、确保所有redis示例设置最大可用内存(maxmemory)，防止极端情况下redis内存不可控的增长
3、降低系统使用swap优先级，如 echo 10>/proc/sys/vm/swappiness
网络问题
1、连接拒绝
网络闪断：一般在网络割接或带宽耗尽的情况
redis连接拒绝：
连接数大于maxclients时拒绝新的连接进入，info stats的rejected_connections指标
客户端访问redis尽量采用NIO长连接或连接池的方式
redis用于大量分布式节点访问且生命周期较短的场景(如Map/Reduce)时，建议设置tcp-keepalive和timeout参数让redis主动检查和关闭无效连接
连接溢出：
进程限制：进程可打开最大文件数控制,ulimit -n，通常1024，大量连接的redis需要增大该值
backlog队列溢出：系统对于特定端口tcp连接使用backlog队列保存，redis默认511，系统backlog默认128，线上可使用cron定时执行netstat -s | grep overflowed统计
2、网络延迟
测量机器之间网络延迟
redis-cli -h{ip} -p{port} –latencyredis-cli -h{ip} -p{port} –latency-history 默认15秒完成一行统计，-i控制采样时间redis-cli -h{ip} -p{port} –latency-dist 统计图展示，每1秒采样一次
3、网卡软中断
单个网卡队列只能使用一个CPU，高并发下网卡数据交互都集中在同一个CPU，导致无法充分利用多核CPU的情况。
一般出现在网络高流量吞吐的场景
更多redis知识请关注redis入门教程栏目。
以上就是Redis阻塞原因详解的详细内容，更多请关注24课堂在线网其它相关文章！
