Redis阻塞

Redis阻塞

发现阻塞

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

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

借助Redis监控系统发现阻塞问题，触发报警。推荐CacheCloud系统。

内在原因

API或数据结构使用不合理

对于高并发场景，避免在大对象上执行算法复杂度超过 O(n) O ( n ) 的命令。

1. 发现慢查询：slowlog get {n}
2. 发现大对象：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} –latency

   redis-cli -h{ip} -p{port} –latency-history 默认15秒完成一行统计，-i控制采样时间

   redis-cli -h{ip} -p{port} –latency-dist 统计图展示，每1秒采样一次

3. 网卡软中断

   单个网卡队列只能使用一个CPU，高并发下网卡数据交互都集中在同一个CPU，导致无法充分利用多核CPU的情况。

   一般出现在网络高流量吞吐的场景