《Redis开发与运维》---- Redis的噩梦：阻塞

一、发现阻塞

• 常见的做法是在应用方加入异常统计并通过邮件/微信/短信报警，以便及时发现通知问题。
  1、在实现异常统计时要注意，由于Redis调用API会分散在项目的多个地方，每个地方都监听异常并加入监控代码必然难以维护。这可以借助于日志系统，使用logback或者log4j.当异常发生时，异常信息最终会被日志系统收集到Appender，默认的Appender一般是具体的日志文件，开发人员可以自定义一个Appender，用于专门统计异常和触发报警逻辑。
  2、记得在代码中打印ip和port信息，因为报错信息里没有，问题定位困难。
• 借助Redis监控系统发现阻塞问题

二、Redis内在原因发生阻塞

API或数据结构使用不合理

• 慢查询
  slowlog get {n} 命令可以获取最近的n条慢查询命令
• 大对象
  redis-cli -h {ip} -p {port} --bigkeys 可以查询大对象

CPU饱和

top命令查出对应Redis进程的CPU使用率。

redis-cli -h {ip} -p {port} --stat获取Redis的使用情况

持久化阻塞

• fork阻塞
  info stats可以获取到最近一次fork操作耗时：latest_fork_usec，如果耗时很大，需要优化调整。参见5.3节

• AOF刷盘阻塞
  硬盘压力引起，info persistence 统计aof_delayed_fsync指标，每次发生fdatasync阻塞主线程时会累加。参见5.3节。
  PS：可以使用iotop工具查看地具体是哪个进程消耗过多的硬盘资源。

三、外在原因使Redis阻塞

CPU竞争

• 进程间竞争
  Redis是典型的CPU密集型应用，不建议和其他多核CPU密集型服务部署在一起。top、sar等命令定位到CPU消耗的时间点和具体进程。
• 绑定到指定CPU，自己阻塞了
  Redis进程绑定CPU上，用于降低CPU频繁上下文切花的开销。当Redis父进程创建子进程进行RDB/AOF重写时，如果做了CPU绑定，会与父进程共享一个CPU，也就会产生竞争。因此对于开启了持久化或参与复制的主节点不建议绑定CPU。

内存交换

内存交换（swap）是指操作系统把Redis使用的部分内存换出到硬盘，这是致命的。
1、查询Redis进程号

# redis-cli -p 6386 info server | grep process_id
process_id:4476

2、根据进程号查内存交换信息

# cat /proc/4476/swaps |grep Swap

如果是0KB或者个别的是4KB，则是正常现象。
预防内存交换的方法有：
1、保证机器内存充足 2、设置最大可用内存（maxmemory） 3、降低系统使用swap优先级

网络问题

• 连接拒绝
  1、网络闪断。2、Redis连接拒绝。3、连接溢出
• 网络延迟

redis-cli -h {host} -p {port}

--latency: 持续进行延迟测试 分别统计：最小值、最大值、平均值、采样次数。
--latency-history:统计结果同--latency，但默认每15秒完成一行统计，可通过-i参数控制采样时间。
--latency-dist:使用统计图的形式展示延迟统计，每1秒采样一次。