Redis读书笔记（六）Redis阻塞

Redis的所有读写操作都是在一条主线程中完成的。这条线程就可以说是Redis的生命线。

当Redis阻塞时，Jedis客户端可能会抛出JedisConnectionException异常。常见的做法是加入异常统计并通过邮件/短信/微信报警。

阻塞首先应该从Redis自身原因开始排查。
API或数据结构使用不合理。
CPU饱和的问题。
持久化相关的阻塞。

1）API或数据使用不合理
比如包含上万个元素的hash结构执行hgetall操作，数据量大而且命令算法复杂度是O(n)，着一定会很慢。

这就需要发现这些慢查询。
slowlog get{n}命令可以获取最近n条慢查询命令。
解决办法，降低算法时间复杂度，调整大对象。
Redis本身提供发现大对象的工具 redis -cli -h{ip} -p{port} bigkeys。

2）CPU饱和
单线程的Redis处理命令只能使用一个CPU，CPU饱和是指Redis把单核CPU使用率接近100%。此时优化很难达到效果，需要集群来分摊压力。

3）持久化阻塞
持久化引起主线程阻塞的操作主要有：fork阻塞，AOF刷盘阻塞，HugePage写操作阻塞。

fork操作发生在RDB和AOF重写时，Redis主线程调用fork操作产生共享内存的子进程。如果fork操作本身耗时，就会阻塞。
通过info stats 获取到latest_fork_usec指标，最近一次fork耗时，超过1秒，基本要做调整。

AOF刷盘阻塞，当我们卡其AOF持久化功能时，文件刷盘的方式一盘采用每秒一次，后台线程每秒对AOF文件做fsync操作。当硬盘压力过大时，fsync操作需要等待，知道写入完成，如果这个过程超过2秒，主线程就会阻塞等待他。

参看info persistence统计中的aof_delayed_fsync指标。

外部原因
1）CPU竞争
2）内存交换
3）网络问题

CPU竞争，Redis是典型的CPU密集型应用，不建议和其他多核CPU密集型服务器部署在一起。当其他进程过度消耗CPU时，将严重影响Redis的吞吐量。

部署Redis时为了充分利用多核CPU，通常一台机器部署多个实例。优化是把Redis进程绑定到CPU上，避免CPU切换带来的开销。开启了持久化和参与复制的主节点不建议绑定CPU。

内存交换
内存交换对Redis来说是致命的。如果操作系统把Redis使用的部分内存换出到硬盘，会导致性能急速下降。

如果交换量都是0kb或者个别是4kb，是正常现象，说明没有被交换。

预防交换的方法：
保证机器充足的可用内存。
确保所有Redis实例设置最大可用内存（maxmemory），防止阶段情况下Redis内存的不可控增长。
降低系统使用swap的优先级（linux和windows使用情况不同）。