Redis 是典型的单线程架构，所有的读写操作都是在一条主线程中实现的。当 Redis 用于高并发场景时，这条线程就变成了它的生命线。如果呈现阻塞，哪怕是很短时间，对于咱们的利用来说都是噩梦。
发现阻塞
当 Redis 阻塞时，线上应用服务应该最先感知到，这时利用方会收到大量 Redis 超时异样，比方 Jedis 客户端会抛出 JedisConnectionException 异样。常见的做法是在利用方退出异样统计并通过邮件 / 短信 / 微信报警，以便及时发现告诉问题 。开发人员须要解决如何统计异样以及触发报警的机会。何时触发报警个别依据利用的并发量决定，如 1 分钟内超过 10 个异样触发报警。在实现异样统计时要留神，因为 Redis 调用 API 会扩散在我的项目的多个中央， 每个中央都监听异样并退出监控代码必然难以保护。这时能够借助于日志零碎，如 Java 语言能够应用 logback 或 log4j。当异样产生时，异样信息最终会被日志零碎收集到 Appender（输入目的地），默认的 Appender 个别是具体的日志文件，能够自定义一个 Appender，用于专门统计异样和触发报警逻辑。
借助日志零碎统计异样的前提是，须要我的项目必须应用日志 API 进行异样对立输入，比方所有的异样都通过 logger.error 打印，这应该作为开发标准推广。其余编程语言也能够采纳相似的日志零碎实现异样统计报警。利用方退出异样监控之后还存在一个问题，当开发人员接到异样报警后，通常会去线上服务器查看谬误日志细节。这时如果利用操作的是多个 Redis 节点（比方应用 Redis 集群），如何决定是哪一个节点超时还是所有的节点都有超时呢？这是线上很常见的需要，但绝大多数的客户端类库并没有在异样信息中打印 ip 和 port 信息，导致无奈疾速定位是哪个 Redis 节点超时。不过批改 Redis 客户端老本很低，比方 Jedis 只须要批改 Connection 类下的 connect、sendCommand、readProtocolWithCheckingBroken 办法专门捕捉连贯，发送命令，协定读取事件的异样。因为客户端类库都会保留 ip 和 port 信息，当异样产生时很容易打印出对应节点的 ip 和 port，辅助咱们疾速定位问题节点。
除了在利用方退出统计报警逻辑之外，还能够借助 Redis 监控零碎发现阻塞问题，当监控零碎检测到 Redis 运行期的一些要害指标呈现不失常时会触发报警。Redis 相干的监控零碎开源的计划有很多，一些公司外部也会本人开发监控零碎。一个牢靠的 Redis 监控零碎首先须要做到对要害指标全方位监控和异样辨认，辅助开发运维人员发现定位问题。如果 Redis 服务没有引入监控零碎作辅助撑持，对于线上的服务是十分不负责任和危险的。
外在起因
API 或数据结构应用不合理
如何发现慢查问
Redis 原生提供慢查问统计性能，执行 slowlog get{n}命令能够获取最近的 n 条慢查问命令，默认对于执行超过 10 毫秒的命令都会记录到一个定长队列中，线上实例倡议设置为 1 毫秒便于及时发现毫秒级以上的命令。慢查问队列长度默认 128，可适当调大。慢查问自身只记录了命令执行工夫，不包含数据网络传输工夫和命令排队工夫，因而客户端产生阻塞异样后，可能不是以后命令迟缓，而是在期待其余命令执行。须要重点比对异样和慢查问产生的工夫点，确认是否有慢查问造成的命令阻塞排队。
发现慢查问后，开发人员须要作出及时调整。能够依照以下两个方向去调整：
- 批改为低算法度的命令，如 hgetall 改为 hmget 等，禁用 keys、sort 等命令。
- 缩减大对象数据或把大对象拆分为多个小对象，避免一次命令操作过多的数据。大对象拆分过程须要视具体的业务决定，如用户好友汇合存储在 Redis 中，有些热点用户会关注大量好友，这时能够按工夫或其余维度拆分到多个汇合中。
如何发现大对象
Redis 自身提供发现大对象的工具，对应命令：redis-cli -h {ip} -p {port} bigkeys。外部原理采纳分段进行 scan 操作，把历史扫描过的最大对象统计进去便于剖析优化，依据后果汇总信息能十分不便地获取到大对象的键，以及不同类型数据结构的应用状况。
CPU 饱和
单线程的 Redis 解决命令时只能应用一个 CPU。而 CPU 饱和是指 Redis 把单核 CPU 使用率跑到靠近 100%。应用 top 命令很容易辨认出对应 Redis 过程的 CPU 使用率。CPU 饱和是十分危险的，将导致 Redis 无奈解决更多的命令，重大影响吞吐量和利用方的稳定性。
对于这种状况，首先判断以后 Redis 的并发量是否达到极限，倡议应用统计命令 redis-cli -h {ip} -p {port} –stat 获取以后 Redis 应用状况，该命令每秒输入一行统计信息。
对于这种状况，垂直层面的命令优化很难达到成果，这时就须要做 集群化程度扩大 来摊派 OPS 压力。如果只有几百或几千 OPS 的 Redis 实例就靠近 CPU 饱和是很不失常的，有可能应用了高算法复杂度的命令。还有一种状况是适度的内存优化，这种状况有些荫蔽，须要咱们依据 info commandstats 统计信息剖析出命令不合理开销工夫。
例如 Redis 实例为了谋求低内存使用量，适度放宽 ziplist 应用条件（批改了 hash-max-ziplist-entries 和 hash-max-ziplist-value 配置）。过程内的 hash 对象均匀存储着上万个元素，而针对 ziplist 的操作算法复杂度在 O（n）到 O（n2）之间。尽管采纳 ziplist 编码后 hash 构造内存占用会变小，然而操作变得更慢且更耗费 CPU。ziplist 压缩编码是 Redis 用来均衡空间和效率的优化伎俩，不可适度应用。
长久化阻塞
fork 阻塞
fork 操作产生在 RDB 和 AOF 重写时，Redis 主线程调用 fork 操作产生共享内存的子过程，由子过程实现长久化文件重写工作。如果 fork 操作自身耗时过长，必然会导致主线程的阻塞。
能够执行 info stats 命令获取到 latest_fork_usec 指标，示意 Redis 最近一次 fork 操作耗时，如果耗时很大，比方超过 1 秒，则须要做出优化调整，如防止应用过大的内存实例和躲避 fork 迟缓的操作系统等。
AOF 刷盘阻塞
当咱们开启 AOF 长久化性能时，文件刷盘的形式个别采纳每秒一次，后盾线程每秒对 AOF 文件做 fsync 操作。当硬盘压力过大时，fsync 操作须要期待，直到写入实现。如果主线程发现间隔上一次的 fsync 胜利超过 2 秒，为了数据安全性它会阻塞直到后盾线程执行 fsync 操作实现。这种阻塞行为次要是硬盘压力引起，能够查看 Redis 日志辨认出这种状况，也能够查看 info persistence 统计中的 aof_delayed_fsync 指标，每次产生 fdatasync 阻塞主线程时会累加。
HugePage 写操作阻塞
子过程在执行重写期间利用 Linux 写时复制技术升高内存开销，因而只有写操作时 Redis 才复制要批改的内存页。对于开启 Transparent HugePages 的操作系统，每次写命令引起的复制内存页单位由 4K 变为 2MB，放大了 512 倍，会拖慢写操作的执行工夫，导致大量写操作慢查问。例如简略的 incr 命令也会呈现在慢查问中。
外在起因
CPU 竞争
过程竞争
Redis 是典型的 CPU 密集型利用，不倡议和其余多核 CPU 密集型服务部署在一起。当其余过程适度耗费 CPU 时，将重大影响 Redis 吞吐量。能够通过 top、sar 等命令定位到 CPU 耗费的工夫点和具体过程，这个问题比拟容易发现，须要调整服务之间部署构造。
绑定 CPU
部署 Redis 时为了充分利用多核 CPU，通常一台机器部署多个实例。常见的一种优化是把 Redis 过程绑定到 CPU 上，用于升高 CPU 频繁上下文切换的开销。这个优化技巧失常状况下没有问题，然而存在例外情况。
当 Redis 父过程创立子过程进行 RDB/AOF 重写时，如果做了 CPU 绑定，会与父过程共享应用一个 CPU。子过程重写时对单核 CPU 使用率通常在 90% 以上，父过程与子过程将产生强烈 CPU 竞争，极大影响 Redis 稳定性。因而 对于开启了长久化或参加复制的主节点不倡议绑定 CPU。
内存替换
内存替换（swap）对于 Redis 来说是十分致命的，Redis 保障高性能的一个重要前提是所有的数据在内存中。如果操作系统把 Redis 应用的局部内存换出到硬盘，因为内存与硬盘读写速度差几个数量级，会导致产生替换后的 Redis 性能急剧下降。辨认 Redis 内存替换的查看办法如下：
1）查问 Redis 过程号：
redis-cli -p 6383 info server | grep process_id
process_id:4476
2）依据过程号查问内存替换信息：
cat /proc/4476/smaps | grep Swap
如果交换量都是 0KB 或者个别的是 4KB，则是失常景象，阐明 Redis 过程内存没有被替换。预防内存替换的办法有：
- 保障机器短缺的可用内存。
- 确保所有 Redis 实例设置最大可用内存（maxmemory），避免极其状况下 Redis 内存不可控的增长。
- 升高零碎应用 swap 优先级，如 echo10 > /proc/sys/vm/swappiness。
网络问题
连贯回绝
当呈现网络闪断或者连接数溢出时，客户端会呈现无奈连贯 Redis 的状况。咱们须要辨别这三种状况：网络闪断、Redis 连贯回绝、连贯溢出。
1) 网络闪断
个别产生在网络割接或者带宽耗尽的状况，对于网络闪断的辨认比拟难，常见的做法能够通过 sar-n DEV 查看本机历史流量是否失常，或者借助内部系统监控工具（如 Ganglia）进行辨认。具体问题定位须要更下层的运维反对，对于重要的 Redis 服务须要充分考虑部署架构的优化，尽量避免客户端与 Redis 之间异地跨机房调用。
2) Redis 连贯回绝
Redis 通过 maxclients 参数管制客户端最大连接数，默认 10000。当 Redis 连接数大于 maxclients 时会回绝新的连贯进入，info statsrejected_connections 统计指标记录所有被回绝连贯的数量。
Redis 应用多路复用 IO 模型可撑持大量连贯，然而不代表能够无限连
接。客户端拜访 Redis 时尽量采纳 NIO 长连贯或者连接池的形式。
当 Redis 用于大量分布式节点拜访且生命周期比拟短的场景时，如比拟典型的在 Map/Reduce 中应用 Redis。因为客户端服务存在频繁启动和销毁的状况且默认 Redis 不会被动敞开长时间闲置连贯或查看敞开有效的 TCP 连贯，因而会导致 Redis 连接数疾速耗费且无奈开释的问题。这种场景下倡议设置 tcp-keepalive 和 timeout 参数让 Redis 被动检查和敞开有效连贯。
3) 连贯溢出
- 过程限度（ulimit）
- backlog 队列溢出
网络提早
网络提早取决于客户端到 Redis 服务器之间的网络环境。次要包含它们之间的物理拓扑和带宽占用状况。
网络提早问题经常出现在跨机房的部署构造上，对于机房之间提早比较严重的场景须要调整拓扑构造，如把客户端和 Redis 部署在同机房或同城机房等。
带宽占用次要依据过后使用率是否达到瓶颈无关，如频繁操作 Redis 的大对象对于千兆网卡的机器很容易达到网卡瓶颈，因而须要重点监控机器流量，及时发现网卡打满产生的网络提早或通信中断等状况，而机房专线和交换机带宽个别由下层运维监控反对，通常呈现瓶颈的概率较小。
网卡软中断
网卡软中断是指因为单个网卡队列只能应用一个 CPU，高并发下网卡数据交互都集中在同一个 CPU，导致无奈充分利用多核 CPU 的状况。
Linux 在内核 2.6.35 当前反对 Receive Packet Steering（RPS），实现了在软件层面模仿硬件的多队列网卡性能。