Redis 是典型的单线程架构，所有的读写操作都是在一条主线程中完成的。当Redis用于高并发场景时，这条线程就变的极其重要。如果它出现阻塞，就会对应用带来致命的问题。当 Redis 出现阻塞时，可以从以下方面着手分析。
内在原因
当出现阻塞时，应该首先排查是否Redis 自身原因导致。其自身可能导致阻塞的原因有
API或数据结构使用不合理
当Redis中的 API或数据结构使用不当时，就会出现慢查询，从而会导致，Redis处理相对较慢。
1 发现慢查询
通过命令 slowlog get {n} 可以获取最近的 n 条慢查询命令。当发现慢查询后，可以通过如下方式进行调整
- 修改为低算法度的命令，如
getall 改为 hmget等，禁用 keys，sort 等。 - 调整大对象：缩减大对象数据或把大对象拆分为多个小对象，防止一次命令操作过多数据
2 发现大对象
通过命令 redis-cli -h {ip} -p {port} --bigkeys 查找大对象。
CPU饱和
单线程的Redis处理命令时只能使用一个CPU，CPU饱和是指Redis把单核 CPU 使用率达到接近 100% 。可以使用 top 命令找出 对应的 Redis 进程。然后，通过 使用 redis-cli -h {ip} -p {port} --stat 获取当前 Redis 的使用情况。也可以通过 info commandstats 统计信息分析出命令不合理开心时间。
持久化相关的阻塞
引起主线程阻塞的持久化操作有
1 fork 阻塞
Redis 在 RDB和 AOF 重写是，会通过 fork 操作创建共享内存的子进程，如果 fork 操作本身比较耗时，就会导致 主线程阻塞。
可以通过 命令 info stats 获取 latest_fork_usec 指标，其表示 Redis 最近一次 fork 操作耗时。
2 AOF 刷盘阻塞
当开启 AOF 持久化功能时，一般是采用一秒刷盘一次的方式，当硬盘压力过大时，刷盘操作就会等待，直到写完。可以通过命令info persistence 统计中的aof_delayed_fsync指标分析。
3 HugePage 写操作阻塞
由于子进程在重新期间是采用的 写时复制 来降低内存开销，如果对开启了 Transparent HugePages 的操作系统，每次写命令引起的复制内存页将会很大，会拖慢写操作的执行时间，导致大量的写操作慢查询。
外在原因
如果排查 Redis 内因引起的阻塞原因后，还是没有定位到问题，就需要排查一下外因了。
CPU竞争
- 进程竞争：
Redis 是CPU 密集型应用，最好不要跟其他 CPU 密集型服务部署在一起。 - 绑定CPU：有时为了减少CPU频繁上下文切换，把
Redis 绑定到 CPU 上。此种情况当 进行 RDB 或 AOF 重写时，就会导致 CPU 使用率飙高。
内存交换
内存交换对于Redis 来说是非常致命的，Redis 保证高性能的一个重要前提是所有的数据在内存中。如果操作系统把 Redis 使用的内存数据置换到硬盘中，由于内存和硬盘的读写速度相差几个数据量级，从而会导致Redis 的性能急剧下降。 可以通过如下方式检查是否存在内存交换：
- 查询 Redis 进程号
redis-cli -p {port} info server | grep process_id
- 根据进程号查询内存交换信息
cat /proc/{process_id}/smaps | grep Swap
防止内存交换方法
- 保证机器可用内存充足
- 确保所有 Redis 实例设置最大可用内存
- 降低系统内存使用 swap 优先级。
网络问题
网络问题经常是引起 Redis 阻塞的问题点。常见的网络问主要有：
连接拒绝
- 网络闪断：一般发生在网络割接或带宽耗尽的情况，这种情况比较难识别
- Redis 连接拒绝：连接数 超过了 maxclients 参数控制的最大允许连接数
- 连接溢出：超过Linux 操作系统现在最大文件数控制 或者 tcp-backlog 超过最大数。
网络延迟
此种方式主要是 客户端到 Redis 服务器之间的网络环境问题。
网卡软中断
网卡中断是指由于单个网卡队列只能使用一个 CPU，高并发下网卡数据交换都集中在同一个 CPU，导致无法充分利用多核 CPU的情况。网卡软中断瓶颈一般出现在网络高流量吞吐的场景。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
