本篇文章给大家带来了关于Redis的相关常识，其间主要介绍了浅谈Redis变慢的原因及排查方法，文中经过示例代码介绍的非常详细，对大家的学习或者作业具有必定的参考学习价值，下面一起来看一下，期望对大家有帮助。
- 引荐学习：Redis视频教程
原因1：实例内存到达上限
排查思路
假如你的 Redis 实例设置了内存上限 maxmemory，那么也有或许导致 Redis 变慢。
当咱们把 Redis 当做纯缓存运用时，一般会给这个实例设置一个内存上限 maxmemory，然后设置一个数据筛选战略。而当实例的内存到达了 maxmemory 后，你或许会发现，在此之后每次写入新数据，操作推迟变大了。
导致变慢的原因
当 Redis 内存到达 maxmemory 后，每次写入新的数据之前，Redis 有必要先从实例中踢出一部分数据，让整个实例的内存维持在 maxmemory 之下，然后才能把新数据写进来。
这个踢出旧数据的逻辑也是需求消耗时刻的，而详细耗时的长短，要取决于你装备的筛选战略：
- allkeys-lru：不论 key 是否设置了过期，筛选最近最少拜访的 key
- volatile-lru：只筛选最近最少拜访、并设置了过期时刻的 key
- allkeys-random：不论 key 是否设置了过期，随机筛选 key
- volatile-random：只随机筛选设置了过期时刻的 key
- allkeys-ttl：不论 key 是否设置了过期，筛选即将过期的 key
- noeviction：不筛选任何 key，实例内存到达 maxmeory 后，再写入新数据直接回来过错
- allkeys-lfu：不论 key 是否设置了过期，筛选拜访频率最低的 key（4.0+版别支撑）
- volatile-lfu：只筛选拜访频率最低、并设置了过期时刻 key（4.0+版别支撑）
详细运用哪种战略，咱们需求依据详细的事务场景来装备。一般最常运用的是 allkeys-lru / volatile-lru 筛选战略，它们的处理逻辑是，每次从实例中随机取出一批 key（这个数量可装备），然后筛选一个最少拜访的 key，之后把剩下的 key 暂存到一个池子中，继续随机取一批 key，并与之前池子中的 key 比较，再筛选一个最少拜访的 key。以此往复，直到实例内存降到 maxmemory 之下。
需求留意的是，Redis 的筛选数据的逻辑与删除过期 key 的一样，也是在命令真实履行之前履行的，也便是说它也会添加咱们操作 Redis 的推迟，而且，写 OPS 越高，推迟也会越显着。
别的，假如此刻你的 Redis 实例中还存储了 bigkey，那么在筛选删除 bigkey 开释内存时，也会耗时比较久。
看到了么？bigkey 的危害到处都是，这也是前面我提示你尽量不存储 bigkey 的原因。
解决方案
- 防止存储 bigkey，下降开释内存的耗时
- 筛选战略改为随机筛选，随机筛选比 LRU 要快很多（视事务状况调整）
- 拆分实例，把筛选 key 的压力分摊到多个实例上
- 假如运用的是 Redis 4.0 以上版别，敞开 layz-free 机制，把筛选 key 开释内存的操作放到后台线程中履行（装备 lazyfree-lazy-eviction = yes）
原因2：敞开内存大页
排查思路
- 咱们都知道，应用程序向操作系统恳求内存时，是按内存页进行恳求的，而惯例的内存页巨细是 4KB。
- Linux 内核从 2.6.38 开端，支撑了内存大页机制，该机制答应应用程序以 2MB 巨细为单位，向操作系统恳求内存。
- 应用程序每次向操作系统恳求的内存单位变大了，但这也意味着恳求内存的耗时变长。
导致变慢的原因
- 当 Redis 在履行后台 RDB 和 AOF rewrite 时，采用 fork 子进程的方法来处理。但主进程 fork 子进程后，此刻的主进程依旧是能够接收写恳求的，而进来的写恳求，会采用 Copy On Write（写时仿制）的方法操作内存数据。
- 也便是说，主进程一旦有数据需求修正，Redis 并不会直接修正现有内存中的数据，而是先将这块内存数据复制出来，再修正这块新内存的数据，这便是所谓的「写时仿制」。
- 写时仿制你也能够理解成，谁需求产生写操作，谁就需求先复制，再修正。
- 这样做的好处是，父进程有任何写操作，并不会影响子进程的数据耐久化（子进程只耐久化 fork 这一瞬间整个实例中的一切数据即可，不关心新的数据变更，由于子进程只需求一份内存快照，然后耐久化到磁盘上）。
- 但是请留意，主进程在复制内存数据时，这个阶段就涉及到新内存的恳求，假如此刻操作系统敞开了内存大页，那么在此期间，客户端即使只修正 10B 的数据，Redis 在恳求内存时也会以 2MB 为单位向操作系统恳求，恳求内存的耗时变长，从而导致每个写恳求的推迟添加，影响到 Redis 功能。
- 同样地，假如这个写恳求操作的是一个 bigkey，那主进程在复制这个 bigkey 内存块时，一次恳求的内存会更大，时刻也会更久。可见，bigkey 在这儿又一次影响到了功能。
解决方案
封闭内存大页机制。
首先，你需求查看 Redis 机器是否敞开了内存大页：
$cat/sys/kernel/mm/transparent_hugepage/enabled
[always]madvisenever
假如输出选项是 always，就表明目前敞开了内存大页机制，咱们需求关掉它：
$echonever>/sys/kernel/mm/transparent_hugepage/enabled
其实，操作系统供给的内存大页机制，其优势是，能够在必定程序上下降应用程序恳求内存的次数。
但是关于 Redis 这种对功能和推迟极端灵敏的数据库来说，咱们期望 Redis 在每次恳求内存时，耗时尽量短，所以我不建议你在 Redis 机器上敞开这个机制。
原因3：运用Swap
排查思路
假如你发现 Redis 突然变得非常慢，每次的操作耗时都到达了几百毫秒乃至秒级，那此刻你就需求查看 Redis 是否运用到了 Swap，在这种状况下 Redis 基本上已经无法供给高功能的服务了。
导致变慢的原因
什么是 Swap？为什么运用 Swap 会导致 Redis 的功能下降？
假如你对操作系统有些了解，就会知道操作系统为了缓解内存不足对应用程序的影响，答应把一部分内存中的数据换到磁盘上，以到达应用程序对内存运用的缓冲，这些内存数据被换到磁盘上的区域，便是 Swap。
问题就在于，当内存中的数据被换到磁盘上后，Redis 再拜访这些数据时，就需求从磁盘上读取，拜访磁盘的速度要比拜访内存慢几百倍！尤其是针对 Redis 这种对功能要求极高、功能极端灵敏的数据库来说，这个操作延时是无法接受的。
此刻，你需求查看 Redis 机器的内存运用状况，承认是否存在运用了 Swap。你能够经过以下方法来查看 Redis 进程是否运用到了 Swap：
#先找到Redis的进程ID
$ps-aux|grepredis-server
#查看RedisSwap运用状况
$cat/proc/$pid/smaps|egrep'^(Swap|Size)'
输出成果如下
Size:1256kB
Swap:0kB
Size:4kB
Swap:0kB
Size:132kB
Swap:0kB
Size:63488kB
Swap:0kB
Size:132kB
Swap:0kB
Size:65404kB
Swap:0kB
Size:1921024kB
Swap:0kB
…
这个成果会列出 Redis 进程的内存运用状况。
每一行 Size 表明 Redis 所用的一块内存巨细，Size 下面的 Swap 就表明这块 Size 巨细的内存，有多少数据已经被换到磁盘上了，假如这两个值持平，阐明这块内存的数据都已经完全被换到磁盘上了。
假如仅仅少数数据被换到磁盘上，例如每一块 Swap 占对应 Size 的份额很小，那影响并不是很大。假如是几百兆乃至上 GB 的内存被换到了磁盘上，那么你就需求警惕了，这种状况 Redis 的功能肯定会急剧下降。
解决方案
- 添加机器的内存，让 Redis 有满足的内存能够运用
- 整理内存空间，开释出满足的内存供 Redis 运用，然后开释 Redis 的 Swap，让 Redis 从头运用内存
开释 Redis 的 Swap 过程一般要重启实例，为了防止重启实例对事务的影响，一般会先进行主从切换，然后开释旧主节点的 Swap，重启旧主节点实例，待从库数据同步完成后，再进行主从切换即可。
可见，当 Redis 运用到 Swap 后，此刻的 Redis 功能基本已达不到高功能的要求（你能够理解为武功被废），所以你也需求提早防备这种状况。
防备的方法便是，你需求对 Redis 机器的内存和 Swap 运用状况进行监控，在内存不足或运用到 Swap 时报警出来，及时处理。
原因4：网络带宽过载
排查思路
假如以上产生功能问题的场景，你都规避掉了，而且 Redis 也安稳运行了很长时刻，但在某个时刻点之后开端，操作 Redis 突然开端变慢了，而且一直继续下去，这种状况又是什么原因导致？
此刻你需求排查一下 Redis 机器的网络带宽是否过载，是否存在某个实例把整个机器的网路带宽占满的状况。
导致变慢的原因
网络带宽过载的状况下，服务器在 TCP 层和网络层就会呈现数据包发送推迟、丢包等状况。
Redis 的高功能，除了操作内存之外，就在于网络 IO 了，假如网络 IO 存在瓶颈，那么也会严重影响 Redis 的功能。
解决方案
- 及时承认占满网络带宽 Redis 实例，假如属于正常的事务拜访，那就需求及时扩容或迁移实例了，防止由于这个实例流量过大，影响这个机器的其他实例。
- 运维层面，你需求对 Redis 机器的各项目标添加监控，包括网络流量，在网络流量到达必定阈值时提早报警，及时承认和扩容。
原因5：其他原因
1) 频频短衔接
你的事务应用，应该运用长衔接操作 Redis，防止频频的短衔接。
频频的短衔接会导致 Redis 大量时刻消耗在衔接的建立和开释上，TCP 的三次握手和四次挥手同样也会添加拜访推迟。
2) 运维监控
前面我也提到了，要想提早预知 Redis 变慢的状况产生，必不可少的便是做好完善的监控。
监控其实便是对采集 Redis 的各项运行时目标，一般的做法是监控程序守时采集 Redis 的 INFO 信息，然后依据 INFO 信息中的状况数据做数据展示和报警。
这儿我需求提示你的是，在写一些监控脚本，或运用开源的监控组件时，也不能漫不经心。
在写监控脚本拜访 Redis 时，尽量采用长衔接的方法采集状况信息，防止频频短衔接。同时，你还要留意操控拜访 Redis 的频率，防止影响到事务恳求。
在运用一些开源的监控组件时，最好了解一下这些组件的实现原理，以及正确装备这些组件，防止呈现监控组件产生 Bug，导致短时大量操作 Redis，影响 Redis 功能的状况产生。
咱们当时就产生过，DBA 在运用一些开源组件时，由于装备和运用问题，导致监控程序频频地与 Redis 建立和断开衔接，导致 Redis 响应变慢。
3）其它程序争抢资源
最后需求提示你的是，你的 Redis 机器最好专项专用，只用来布置 Redis 实例，不要布置其他应用程序，尽量给 Redis 供给一个相对「安静」的环境，防止其它程序占用 CPU、内存、磁盘资源，导致分配给 Redis 的资源不足而受到影响。
- 引荐学习：Redis视频教程
- 本文转载自：www.php.cn/redis/49586…