承德兴隆建设局网站,宁波seo推荐推广平台,做网站都用什么工具,怎么建立一个网站让百度搜到Redis作为内存数据库#xff0c;拥有非常高的性能#xff0c;单个实例的QPS能够达到10W左右。但我们在使用Redis时#xff0c;经常时不时会出现访问延迟很大的情况#xff0c;如果你不知道Redis的内部实现原理#xff0c;在排查问题时就会一头雾水。很多时候#xff0c;R…Redis作为内存数据库拥有非常高的性能单个实例的QPS能够达到10W左右。但我们在使用Redis时经常时不时会出现访问延迟很大的情况如果你不知道Redis的内部实现原理在排查问题时就会一头雾水。很多时候Redis出现访问延迟变大都与我们的使用不当或运维不合理导致的。这篇文章我们就来分析一下Redis在使用过程中经常会遇到的延迟问题以及如何定位和分析。使用复杂度高的命令 如果在使用Redis时发现访问延迟突然增大如何进行排查首先第一步建议你去查看一下Redis的慢日志。Redis提供了慢日志命令的统计功能我们通过以下设置就可以查看有哪些命令在执行时延迟比较大。首先设置Redis的慢日志阈值只有超过阈值的命令才会被记录这里的单位是微秒例如设置慢日志的阈值为5毫秒同时设置只保留最近1000条慢日志记录
# 命令执行超过5毫秒记录慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近1000条慢日志
CONFIG SET slowlog-max-len 1000设置完成之后所有执行的命令如果延迟大于5毫秒都会被Redis记录下来我们执行SLOWLOG get 5查询最近5条慢日志
127.0.0.1:6379 SLOWLOG get5
1)1)(integer)32693# 慢日志ID
2)(integer)1593763337# 执行时间
3)(integer)5299# 执行耗时(微秒)
4)1)LRANGE# 具体执行的命令和参数
2)user_list_2000
3)0
4)-1
2)1)(integer)32692
2)(integer)1593763337
3)(integer)5044
4)1)GET
2)book_price_1000
...通过查看慢日志记录我们就可以知道在什么时间执行哪些命令比较耗时如果你的业务经常使用O(n)以上复杂度的命令例如sort、sunion、zunionstore或者在执行O(n)命令时操作的数据量比较大这些情况下Redis处理数据时就会很耗时。如果你的服务请求量并不大但Redis实例的CPU使用率很高很有可能是使用了复杂度高的命令导致的。解决方案就是不使用这些复杂度较高的命令并且一次不要获取太多的数据每次尽量操作少量的数据让Redis可以及时处理返回。 存储大key如果查询慢日志发现并不是复杂度较高的命令导致的例如都是SET、DELETE操作出现在慢日志记录中那么你就要怀疑是否存在Redis写入了大key的情况。Redis在写入数据时需要为新的数据分配内存当从Redis中删除数据时它会释放对应的内存空间。如果一个key写入的数据非常大Redis在分配内存时也会比较耗时。同样的当删除这个key的数据时释放内存也会耗时比较久。你需要检查你的业务代码是否存在写入大key的情况需要评估写入数据量的大小业务层应该避免一个key存入过大的数据量。那么有没有什么办法可以扫描现在Redis中是否存在大key的数据吗Redis也提供了扫描大key的方法redis-cli -h $host -p $port --bigkeys -i 0.01使用上面的命令就可以扫描出整个实例key大小的分布情况它是以类型维度来展示的。需要注意的是当我们在线上实例进行大key扫描时Redis的QPS会突增为了降低扫描过程中对Redis的影响我们需要控制扫描的频率使用-i参数控制即可它表示扫描过程中每次扫描的时间间隔单位是秒。使用这个命令的原理其实就是Redis在内部执行scan命令遍历所有key然后针对不同类型的key执行strlen、llen、hlen、scard、zcard来获取字符串的长度以及容器类型(list/dict/set/zset)的元素个数。而对于容器类型的key只能扫描出元素最多的key但元素最多的key不一定占用内存最多这一点需要我们注意下。不过使用这个命令一般我们是可以对整个实例中key的分布情况有比较清晰的了解。针对大key的问题Redis官方在4.0版本推出了lazy-free的机制用于异步释放大key的内存降低对Redis性能的影响。即使这样我们也不建议使用大key大key在集群的迁移过程中也会影响到迁移的性能这个后面在介绍集群相关的文章时会再详细介绍到 集中过期有时你会发现平时在使用Redis时没有延时比较大的情况但在某个时间点突然出现一波延时而且报慢的时间点很有规律例如某个整点或者间隔多久就会发生一次。如果出现这种情况就需要考虑是否存在大量key集中过期的情况。如果有大量的key在某个固定时间点集中过期在这个时间点访问Redis时就有可能导致延迟增加。Redis的过期策略采用主动过期懒惰过期两种策略•主动过期Redis内部维护一个定时任务默认每隔100毫秒会从过期字典中随机取出20个key删除过期的key如果过期key的比例超过了25%则继续获取20个key删除过期的key循环往复直到过期key的比例下降到25%或者这次任务的执行耗时超过了25毫秒才会退出循环•懒惰过期只有当访问某个key时才判断这个key是否已过期如果已经过期则从实例中删除注意Redis的主动过期的定时任务也是在Redis**主线程**中执行的也就是说如果在执行主动过期的过程中出现了需要大量删除过期key的情况那么在业务访问时必须等这个过期任务执行结束才可以处理业务请求。此时就会出现业务访问延时增大的问题最大延迟为25毫秒。而且这个访问延迟的情况不会记录在慢日志里。慢日志中只记录真正执行某个命令的耗时Redis主动过期策略执行在操作命令之前如果操作命令耗时达不到慢日志阈值它是不会计算在慢日志统计中的但我们的业务却感到了延迟增大。此时你需要检查你的业务是否真的存在集中过期的代码一般集中过期使用的命令是expireat或pexpireat命令在代码中搜索这个关键字就可以了。如果你的业务确实需要集中过期掉某些key又不想导致Redis发生抖动有什么优化方案解决方案是在集中过期时增加一个随机时间把这些需要过期的key的时间打散即可。伪代码可以这么写# 在过期时间点之后的5分钟内随机过期掉
redis.expireat(key, expire_time random(300))这样Redis在处理过期时不会因为集中删除key导致压力过大阻塞主线程。另外除了业务使用需要注意此问题之外还可以通过运维手段来及时发现这种情况。做法是我们需要把Redis的各项运行数据监控起来执行info可以拿到所有的运行数据在这里我们需要重点关注expired_keys这一项它代表整个实例到目前为止累计删除过期key的数量。我们需要对这个指标监控当在很短时间内这个指标出现突增时需要及时报警出来然后与业务报慢的时间点对比分析确认时间是否一致如果一致则可以认为确实是因为这个原因导致的延迟增大。实例内存达到上限 有时我们把Redis当做纯缓存使用就会给实例设置一个内存上限maxmemory然后开启LRU淘汰策略。当实例的内存达到了maxmemory后你会发现之后的每次写入新的数据有可能变慢了。导致变慢的原因是当Redis内存达到maxmemory后每次写入新的数据之前必须先踢出一部分数据让内存维持在maxmemory之下。这个踢出旧数据的逻辑也是需要消耗时间的而具体耗时的长短要取决于配置的淘汰策略•allkeys-lru不管key是否设置了过期淘汰最近最少访问的key•volatile-lru只淘汰最近最少访问并设置过期的key•allkeys-random不管key是否设置了过期随机淘汰•volatile-random只随机淘汰有设置过期的key•allkeys-ttl不管key是否设置了过期淘汰即将过期的key•noeviction不淘汰任何key满容后再写入直接报错•allkeys-lfu不管key是否设置了过期淘汰访问频率最低的key4.0支持•volatile-lfu只淘汰访问频率最低的过期key4.0支持备注allkeys-xxx表示从所有的键值中淘汰数据而volatile-xxx表示从设置了过期键的键值中淘汰数据。具体使用哪种策略需要根据业务场景来决定。我们最常使用的一般是allkeys-lru或volatile-lru策略它们的处理逻辑是每次从实例中随机取出一批key可配置然后淘汰一个最少访问的key之后把剩下的key暂存到一个池子中继续随机取出一批key并与之前池子中的key比较再淘汰一个最少访问的key。以此循环直到内存降到maxmemory之下。如果使用的是allkeys-random或volatile-random策略那么就会快很多因为是随机淘汰那么就少了比较key访问频率时间的消耗了随机拿出一批key后直接淘汰即可因此这个策略要比上面的LRU策略执行快一些。但以上这些逻辑都是在访问Redis时真正命令执行之前执行的也就是它会影响我们访问Redis时执行的命令。另外如果此时Redis实例中有存储大key那么在淘汰大key释放内存时这个耗时会更加久延迟更大这需要我们格外注意。如果你的业务访问量非常大并且必须设置maxmemory限制实例的内存上限同时面临淘汰key导致延迟增大的的情况要想缓解这种情况除了上面说的避免存储大key、使用随机淘汰策略之外也可以考虑拆分实例的方法来缓解拆分实例可以把一个实例淘汰key的压力分摊到多个实例上可以在一定程度降低延迟。fork耗时严重如果你的Redis开启了自动生成RDB和AOF重写功能那么有可能在后台生成RDB和AOF重写时导致Redis的访问延迟增大而等这些任务执行完毕后延迟情况消失。遇到这种情况一般就是执行生成RDB和AOF重写任务导致的。生成RDB和AOF都需要父进程fork出一个子进程进行数据的持久化在fork执行过程中父进程需要拷贝**内存页表**给子进程如果整个实例内存占用很大那么需要拷贝的内存页表会比较耗时此过程会消耗大量的CPU资源在完成fork之前整个实例会被阻塞住无法处理任何请求如果此时CPU资源紧张那么fork的时间会更长甚至达到秒级。这会严重影响Redis的性能。我们可以执行info命令查看最后一次fork执行的耗时latest_fork_usec单位微秒。这个时间就是整个实例阻塞无法处理请求的时间。除了因为备份的原因生成RDB之外在主从节点第一次建立数据同步时主节点也会生成RDB文件给从节点进行一次全量同步这时也会对Redis产生性能影响。要想避免这种情况我们需要规划好数据备份的周期建议在从节点上执行备份而且最好放在**低峰期**执行。如果对于丢失数据不敏感的业务那么不建议开启AOF和AOF重写功能。另外fork的耗时也与系统有关如果把Redis部署在虚拟机上那么这个时间也会增大。所以使用Redis时建议部署在物理机上降低fork的影响。绑定CPU很多时候我们在部署服务时为了提高性能降低程序在使用多个CPU时上下文切换的性能损耗一般会采用进程绑定CPU的操作。但在使用Redis时我们不建议这么干原因如下:绑定CPU的Redis在进行数据持久化时fork出的子进程子进程会继承父进程的CPU使用偏好而此时子进程会消耗大量的CPU资源进行数据持久化子进程会与主进程发生CPU争抢这也会导致主进程的CPU资源不足访问延迟增大。所以在部署Redis进程时如果需要开启RDB和AOF重写机制一定不能进行CPU绑定操作开启AOF上面提到了当执行AOF文件重写时会因为fork执行耗时导致Redis延迟增大除了这个之外如果开启AOF机制设置的策略不合理也会导致性能问题。开启AOF后Redis会把写入的命令实时写入到文件中但写入文件的过程是先写入内存等内存中的数据超过一定阈值或达到一定时间后内存中的内容才会被真正写入到磁盘中。AOF为了保证文件写入磁盘的安全性提供了3种刷盘机制•appendfsync always每次写入都刷盘对性能影响最大占用磁盘IO比较高数据安全性最高•appendfsync everysec1秒刷一次盘对性能影响相对较小节点宕机时最多丢失1秒的数据•appendfsync no按照操作系统的机制刷盘对性能影响最小数据安全性低节点宕机丢失数据取决于操作系统刷盘机制当使用第一种机制appendfsync always时Redis每处理一次写命令都会把这个命令写入磁盘而且这个操作是在主线程中执行的。内存中的的数据写入磁盘这个会加重磁盘的IO负担操作磁盘成本要比操作内存的代价大得多。如果写入量很大那么每次更新都会写入磁盘此时机器的磁盘IO就会非常高拖慢Redis的性能因此我们不建议使用这种机制。与第一种机制对比appendfsync everysec会每隔1秒刷盘而appendfsync no取决于操作系统的刷盘时间安全性不高。因此我们推荐使用appendfsync everysec这种方式在最坏的情况下只会丢失1秒的数据但它能保持较好的访问性能。当然对于有些业务场景对丢失数据并不敏感也可以不开启AOF。使用Swap如果你发现Redis突然变得非常慢每次访问的耗时都达到了几百毫秒甚至秒级那此时就检查Redis是否使用到了Swap这种情况下Redis基本上已经无法提供高性能的服务。我们知道操作系统提供了Swap机制目的是为了当内存不足时可以把一部分内存中的数据换到磁盘上以达到对内存使用的缓冲。但当内存中的数据被换到磁盘上后访问这些数据就需要从磁盘中读取这个速度要比内存慢太多尤其是针对Redis这种高性能的内存数据库来说如果Redis中的内存被换到磁盘上对于Redis这种性能极其敏感的数据库这个操作时间是无法接受的。我们需要检查机器的内存使用情况确认是否确实是因为内存不足导致使用到了Swap。如果确实使用到了Swap要及时整理内存空间释放出足够的内存供Redis使用然后释放Redis的Swap让Redis重新使用内存。释放Redis的Swap过程通常要重启实例为了避免重启实例对业务的影响一般先进行主从切换然后释放旧主节点的Swap重新启动服务待数据同步完成后再切换回主节点即可。可见当Redis使用到Swap后此时的Redis的高性能基本被废掉所以我们需要提前预防这种情况。我们需要对Redis机器的内存和Swap使用情况进行监控在内存不足和使用到Swap时及时报警出来及时进行相应的处理网卡负载过高 如果以上产生性能问题的场景你都规避掉了而且Redis也稳定运行了很长时间但在某个时间点之后开始访问Redis开始变慢了而且一直持续到现在这种情况是什么原因导致的之前我们就遇到这种问题特点就是从某个时间点之后就开始变慢并且一直持续。这时你需要检查一下机器的网卡流量是否存在网卡流量被跑满的情况。网卡负载过高在网络层和TCP层就会出现数据发送延迟、数据丢包等情况。Redis高性能除了内存之外就在于网络IO请求量突增会导致网卡负载变高。如果出现这种情况你需要排查这个机器上的哪个Redis实例的流量过大占满了网络带宽然后确认流量突增是否属于业务正常情况如果属于那就需要及时扩容或迁移实例避免这个机器的其他实例受到影响。运维层面我们需要对机器的各项指标增加监控包括网络流量在达到阈值时提前报警及时与业务确认并扩容。总结 以上我们总结了Redis中常见的可能导致延迟增大甚至阻塞的场景这其中既涉及到了业务的使用问题也涉及到Redis的运维问题。可见要想保证Redis高性能的运行其中涉及到CPU、内存、网络甚至磁盘的方方面面其中还包括操作系统的相关特性的使用。作为开发人员我们需要了解Redis的运行机制例如各个命令的执行时间复杂度、数据过期策略、数据淘汰策略等使用合理的命令并结合业务场景进行优化。作为DBA运维人员需要了解数据持久化、操作系统fork原理、Swap机制等并对Redis的容量进行合理规划预留足够的机器资源对机器做好完善的监控才能保证Redis的稳定运行。
