Redis阻塞原因详解

发现阻塞

线上应用服务最先感知到，可在应用方加入异常统计并通过邮件、短信、微信报警。

借助日志系统，统计异常和触发报警逻辑

借助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_id2、根据进程号查询内存交换信息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阻塞原因详解的详细内容，更多请关注小潘博客其它相关文章！