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），实现了在软件层面模仿硬件的多队列网卡性能。