redis缓存失效策略

A. Redis持久化策略(看这篇,你肯定会有所获)

RDB：Redis DataBase ， 记录快照

        RDB是redis 默认的持久化方案. RDB 是当满足一定条件时, 就会将redis内存中的数据写入磁盘,并生成一个快照文件mp.rdb 文件.Redis 重启会通过加载mp.rdb文件恢复数据.

        一定条件分为以下几种情况: 1.自动触发  2. 手动触发 . 下面分开说明下:

a).redis.conf 中 SNAPSHOTTING 其中定义了触发把数据保存到磁盘的触发频率.

        如果不需要rdb 方案, 注释save 或者配置成空字符串" ".

        save 900 1 #900秒内至少有一个key被修改(包括添加)

        save 300 10 #400秒内至少10个key被修改

        save 10000 #60秒内至少有10000个key 被修改.

        这三条配置不冲突, 只要满足一条就触发.

        rdb 文件位置和目录 (默认在安装根目录下) 

        #文件路径

        dir ./

        #文件名称

        dbfilename mp.rdb

        #是否以LZY压缩rdb 文件

        rdbcompression yes 

        #开启数据校验

        rdbchecksum yes

b) shutdown触发 ,保证服务器正常关闭.

c) flushall , rdb文件是空的, 会生成一个空的文件,所以这种情况也没有什么意义.但需要知道,这种情况下

会触发生成rdb文件.

Redis 提供了两条命令: save 和 bgsave

a). save 命令

        save 在生成快照的时候会阻塞当前Redis 服务器,Redis不能处理其他命令.如果内存数据较多,会造成

b).bgsave 命令

        执行bgsave命令时,   Redis会在后台进行异步快照操作,快照同时还可以响应客户端请求.

具体操作

        具体操作:Redis进程会执行fork操作创建子进程(-on-write),RDB 持久化过程由子进程负载,完成后自动结束.它不会记录fork之后产生的记录.阻塞只发送在fork阶段,一般时间较短.

一.优势

    1.RDB是一个非常紧凑的文件,它保存了Redis在某个时间点上的数据集.这种文件非常适合进行备份和

灾难恢复.

    2.生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存的工作,主进程不需要进行任何

IO操作.

    3.RDB在恢复大数据集时的速度比AOF的恢复速度要快

二.劣势

    1).RDB 没办法做到实时持久化/妙级持久化.因为bgsave每次运行都要执行fork创建子进程,频繁执行成本过高.    

    2).在一定间隔时间做一次备份,所以如果Redis 以为down掉的话,就会丢失最后一次快照之后所有修改

(数据有丢失)

AOF：<Append Only File> ， 记录日志

Redis 默认不开启.AOF采用日志的形式来记录每个写操作,并追加到文件中.开启后,执行更改Redis    命令时,就会把命令写入到AOF文件中.

Redis 重启时会根据日志文件的内容把写指令从前往后执行一次以完成数据的恢复工作.

#开关

appendonly no

#文件名

appendfilename "appendonly.aof"

        由于操作系统缓存机制,AOF数据并没有真正地写入硬盘,而是进入了系统的硬盘缓存.什么时候

把缓冲区的内容写入到AOF文件中? 由下面参数决定

appendfsync :  值: no  \ always \everysec 

        no: 表示不执行fync, 由操作系统保证数据同步到磁盘,速度最快,但是不安全.

        always:表示每次写入都执行fync,以保证数据同步到磁盘,效率很低

        everysec:表示每秒执行以fync ,可能会导致丢失1s数据.通常选择everysec,兼顾效率和安全性.

    因为AOF文件只有一个, 随着redis 不断进行,AOF 的文件会越来越大,文件越大, 文件占用服务器内存

以及AOF恢复要求时间越长.

    为了解决这个问题,可以使用bgwriteaof来重写.那什么时候重写? 又是怎样重写?

    一. 什么时候重写?

    #重写触发机制

    auto-aof-rewrite-percentage 100 默认值是100. 当前aof 文件大小超过 上一次重写的aof文件大小百分之多少进行重写,即当aof文件增长到一定大小时,Redis能够调用bgwriteaof对日志文件进行重写.当前aof文件大小是上次日志重写得到aof文件大小的二倍时, 自动启动新的日志重写过程.

    auto-aof-rewrite-min-size 默认是64M.设置允许重写的最小aof文件大小,避免达到了约定百分比 但尺寸

仍然很小的情况还要重写.

   二. 怎样重写?

    并不是对原文件进行重新整理,而是直接读取服务器上现有的键值对,然后用一条命令去代替之间记录这

个键值对的多条命令,生成一个新的文件后去替换原来的 AOF文件.

    看下面这两个参数:

        no-appendfsync-on-rewrite

        aof-load-truncated

   AOF 数据恢复

        重启Redis之后就会进行AOF文件恢复.

   AOF 的优势和劣势

优点:

1.AOF 持久化的方法提供了多种的同步频率,即使使用默认的同步频率每秒同步一次,Redis最多也就丢失

1秒的数据.

缺点:

1.对于具有相同数据的Redis, AOF文件通常比RDF文件体积更大(RDB存的是数据快照)

2.虽然AOF提供了多种同步的频率,默认的情况下,没秒同步一次的频率也具有较高的性能.在高并发的情况下,RDB比AOF具有更好的性能.

        如果可以忍一小段时间数据的丢失,毫无疑问使用RDB 是最好的,定时生成RDB快照非常便于进行数据备份,而且RDB恢复数据集的速度也要比AOF恢复速度要快.

        否则就要使用AOF重写.但是一般情况下建议不要单独使用某一种持久化机制,而是两种一起用.

本文内容来自咕泡学院-青山老师,感谢青山老师!!

B. Redis的LRU缓存淘汰算法实现

LRU， 最近最少使用 （Least Recently Used，LRU），经典缓存算法。

LRU会使用一个链表维护缓存中每个数据的访问情况，并根据数据的实时访问，调整数据在链表中的位置，然后通过数据在链表中的位置，表示数据是最近刚访问的，还是已有段时间未访问。

LRU会把链头、尾分别设为MRU端和LRU端：

LRU可分成如下情况：

case2图解：链表长度为5，从链表头部到尾部保存的数据分别是5，33，9，10，8。假设数据9被访问一次，则9就会被移动到链表头部，同时，数据5和33都要向链表尾部移动一位。

所以若严格按LRU实现，假设Redis保存的数据较多，还要在代码中实现：

最终导致降低Redis访问性能。

所以，无论是为节省内存 or 保持Redis高性能，Redis并未严格按LRU基本原理实现，而是 提供了一个近似LRU算法实现 。

Redis的内存淘汰机制是如何启用近似LRU算法的？redis.conf中的如下配置参数：

所以，一旦设定maxmemory选项，且将maxmemory-policy配为allkeys-lru或volatile-lru，近似LRU就被启用。allkeys-lru和volatile-lru都会使用近似LRU淘汰数据，区别在于：

Redis如何实现近似LRU算法的呢？

近似LRU算法仍需区分不同数据的访问时效性，即Redis需知道数据的最近一次访问时间。因此，有了LRU时钟：记录数据每次访问的时间戳。

Redis对每个KV对中的V，会使用个redisObject结构体保存指向V的指针。那redisObject除记录值的指针，还会使用24 bits保存LRU时钟信息，对应的是lru成员变量。这样，每个KV对都会把它最近一次被访问的时间戳，记录在lru变量。

redisObject定义包含lru成员变量的定义：

每个KV对的LRU时钟值是如何计算的？Redis Server使用一个实例级别的全局LRU时钟，每个KV对的LRU time会根据全局LRU时钟进行设置。

这全局LRU时钟保存在Redis全局变量server的成员变量 lruclock

当Redis Server启动后，调用initServerConfig初始化各项参数时，会调用getLRUClock设置lruclock的值：

于是，就得注意， 若一个数据前后两次访问的时间间隔 1s，那这两次访问的时间戳就是一样的！ 因为LRU时钟精度就是1s，它无法区分间隔小于1秒的不同时间戳！

getLRUClock函数将获得的UNIX时间戳，除以LRU_CLOCK_RESOLUTION后，就得到了以LRU时钟精度来计算的UNIX时间戳，也就是当前的LRU时钟值。

getLRUClock会把LRU时钟值和宏定义LRU_CLOCK_MAX（LRU时钟能表示的最大值）做与运算。

所以默认情况下，全局LRU时钟值是以1s为精度计算得UNIX时间戳，且是在initServerConfig中进行的初始化。

那Redis Server运行过程中，全局LRU时钟值是如何更新的？和Redis Server在事件驱动框架中，定期运行的时间事件所对应的serverCron有关。

serverCron作为时间事件的回调函数，本身会周期性执行，其频率值由redis.conf的 hz配置项 决定，默认值10，即serverCron函数会每100ms（1s/10 = 100ms）运行一次。serverCron中，全局LRU时钟值就会按该函数执行频率，定期调用getLRUClock进行更新：

这样，每个KV对就能从全局LRU时钟获取最新访问时间戳。

对于每个KV对，它对应的redisObject.lru在哪些函数进行初始化和更新的呢？

对于一个KV对，其LRU时钟值最初是在这KV对被创建时，进行初始化设置的，这初始化操作在 createObject函数 中调用，当Redis要创建一个KV对，就会调用该函数。

createObject除了会给redisObject分配内存空间，还会根据maxmemory_policy配置，初始化设置redisObject.lru。

LRU_CLOCK返回当前全局LRU时钟值。因为一个KV对一旦被创建，就相当于有了次访问，其对应LRU时钟值就表示了它的访问时间戳：

那一个KV对的LRU时钟值又是何时再被更新？

只要一个KV对被访问，其LRU时钟值就会被更新！而当一个KV对被访问时，访问操作最终都会调用 lookupKey 。

lookupKey会从全局哈希表中查找要访问的KV对。若该KV对存在，则lookupKey会根据maxmemory_policy的配置值，来更新键值对的LRU时钟值，也就是它的访问时间戳。

而当maxmemory_policy没有配置为LFU策略时，lookupKey函数就会调用LRU_CLOCK函数，来获取当前的全局LRU时钟值，并将其赋值给键值对的redisObject结构体中的lru变量

这样，每个KV对一旦被访问，就能获得最新的访问时间戳。但你可能好奇：这些访问时间戳最终是如何被用于近似LRU算法进行数据淘汰的？

Redis之所以实现近似LRU，是为减少内存资源和操作时间上的开销。

近似LRU主要逻辑在performEvictions。

performEvictions被evictionTimeProc调用，而evictionTimeProc函数又是被processCommand调用。

processCommand，Redis处理每个命令时都会调用：

然后，isSafeToPerformEvictions还会再次根据如下条件判断是否继续执行performEvictions：

一旦performEvictions被调用，且maxmemory-policy被设置为allkeys-lru或volatile-lru，近似LRU就被触发执行了。

执行可分成如下步骤：

调用getMaxmemoryState评估当前内存使用情况，判断当前Redis Server使用内存容量是否超过maxmemory配置值。

若未超过maxmemory ，则返回C_OK，performEvictions也会直接返回。

getMaxmemoryState评估当前内存使用情况的时候，若发现已用内存超出maxmemory，会计算需释放的内存量。这个释放内存大小=已使用内存量-maxmemory。

但已使用内存量并不包括用于主从复制的复制缓冲区大小，这是getMaxmemoryState通过调用freeMemoryGetNotCountedMemory计算的。

而若当前Server使用的内存量超出maxmemory上限 ，则performEvictions会执行while循环淘汰数据释放内存。

为淘汰数据，Redis定义数组EvictionPoolLRU，保存待淘汰的候选KV对，元素类型是evictionPoolEntry结构体，保存了待淘汰KV对的空闲时间idle、对应K等信息：

这样，Redis Server在执行initSever进行初始化时，会调用evictionPoolAlloc为EvictionPoolLRU数组分配内存空间，该数组大小由EVPOOL_SIZE决定，默认可保存16个待淘汰的候选KV对。

performEvictions在淘汰数据的循环流程中，就会更新这个待淘汰的候选KV对集合，即EvictionPoolLRU数组。

performEvictions调用evictionPoolPopulate，其会先调用dictGetSomeKeys，从待采样哈希表随机获取一定数量K：

于是，dictGetSomeKeys返回采样的KV对集合。evictionPoolPopulate根据实际采样到的KV对数量count，执行循环：调用estimateObjectIdleTime计算在采样集合中的每一个KV对的空闲时间：

接着，evictionPoolPopulate遍历待淘汰的候选KV对集合，即EvictionPoolLRU数组，尝试把采样的每个KV对插入EvictionPoolLRU数组，取决于如下条件之一：

有一成立，evictionPoolPopulate就能把采样KV对插入EvictionPoolLRU数组。等所有采样键值对都处理完后，evictionPoolPopulate函数就完成对待淘汰候选键值对集合的更新了。

接下来，performEvictions开始选择最终被淘汰的KV对。

因evictionPoolPopulate已更新EvictionPoolLRU数组，且该数组里的K，是按空闲时间从小到大排好序了。所以，performEvictions遍历一次EvictionPoolLRU数组，从数组的最后一个K开始选择，若选到的K非空，就把它作为最终淘汰的K。

该过程执行逻辑：

一旦选到被淘汰的K，performEvictions就会根据Redis server的惰性删除配置，执行同步删除或异步删除：

至此，performEvictions就淘汰了一个K。若此时释放的内存空间还不够，即没有达到待释放空间，则performEvictions还会 重复执行 前面所说的更新待淘汰候选KV对集合、选择最终淘汰K的过程，直到满足待释放空间的大小要求。

performEvictions流程：

近似LRU算法并未使用耗时且耗空间的链表，而使用 固定大小的待淘汰数据集合 ，每次随机选择一些K加入待淘汰数据集合。

最后，按待淘汰集合中K的空闲时间长度，删除空闲时间最长的K。

根据LRU算法的基本原理，发现若严格按基本原理实现LRU算法，则开发的系统就需要额外内存空间保存LRU链表，系统运行时也会受到LRU链表操作的开销影响。

而Redis的内存资源和性能都很重要，所以Redis实现近似LRU算法：

一个算法的基本原理和算法的实际执行，在系统开发中会有一定折中，需综合考虑所开发的系统，在资源和性能方面的要求，以避免严格按照算法实现带来的资源和性能开销。

C. redis 失效如何快速响应

Redis是key-value数据库，我们可以设置Redis中缓存的key的过期时间。Redis的过期策略就是指当Redis中缓存的key过期了，Redis如何处理。
过期策略通常有以下三种：
1、定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
2、惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
3、定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。(expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。)

D. redis过期策略有哪些

redis 过期策略是：定期删除+惰性删除。

所谓定期删除，指的是redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。

假设redis里放了10w个key，都设置了过期时间，每隔几百毫秒，就检查10w个key，那redis基本上就死了，cpu负载会很高的，消耗在检查过期key上了。实际上redis是每隔100ms随机抽取一些key来检查和删除的。

Redis常用内存优化：

Redis内部实现没有对内存分配方面做过多的优化，在一定程度上会存在内存碎片，不过大多数情况下这个不会成为Redis的性能瓶颈，不过如果在Redis内部存储的大部分数据是数值型的话，Redis内部采用了一个shared integer的方式来省去分配内存的开销。

即在系统启动时先分配一个从1~n那么多个数值对象放在一个池子中，如果存储的数据恰好是这个数值范围内的数据，则直接从池子里取出该对象，并且通过引用计数的方式来共享，这样在系统存储了大量数值下。

也能一定程度上节省内存并且提高性能，这个参数值n的设置需要修改源代码中的一行宏定义REDIS_SHARED_INTEGERS，该值默认是10000，可以根据自己的需要进行修改，修改后重新编译就可以了。

以上内容参考网络—Redis

E. 该怎么解决 Redis 缓存穿透和缓存雪崩问题

缓存雪崩： 由于缓存层承载着大量请求，有效地 保护了存储层，但是如果缓存层由于某些原因不能提供服务，比如 Redis 节点挂掉了，热点 key 全部失效了，在这些情况下，所有的请求都会直接请求到数据库，可能会造成数据库宕机的情况。
预防和解决缓存雪崩问题，可以从以下三个方面进行着手：
1、使用 Redis 高可用架构：使用 Redis 集群来保证 Redis 服务不会挂掉
2、缓存时间不一致： 给缓存的失效时间，加上一个随机值，避免集体失效
3、限流降级策略：有一定的备案，比如个性推荐服务不可用了，换成热点数据推荐服务
缓存穿透： 缓存穿透是指查询一个根本不存在的数据，这样的数据肯定不在缓存中，这会导致请求全部落到数据库上，有可能出现数据库宕机的情况。
预防和解决缓存穿透问题，可以考虑以下两种方法：
1、缓存空对象： 将空值缓存起来，但是这样就有一个问题，大量无效的空值将占用空间，非常浪费。
2、布隆过滤器拦截： 将所有可能的查询key 先映射到布隆过滤器中，查询时先判断key是否存在布隆过滤器中，存在才继续向下执行，如果不存在，则直接返回。布隆过滤器有一定的误判，所以需要你的业务允许一定的容错性。

F. 2022-03-12 SpringBoot 使用redis做缓存，设置失效时间以及序列化

SpringBoot的cache缓存，是针对返回值的一种操作
springboot使用redis做缓存时，默认只需要导入redis依赖，即可实现使用redis做缓存

不需要导入cache依赖
在启动类上加上 @EnableCaching 即可开启缓存功能
关于各个注解的使用，这里不再细说，网上详细的教程很多，这里主要讲一下如何指定过期时间

默认是永不过期，如果需要指定过期时间，则需要增加配置类

G. Redis常见延迟问题排查手册！附33条优化建议

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 get 5

1) 1) (integer) 32693 # 慢日志ID

2) (integer) 1593763337 # 执行时间

3) (integer) 5299 # 执行耗时(微妙)

4) 1) 'LRANGE' # 具体执行的命令和参数

2) 'user_list_2000'

3) Ɔ'

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可以及时处理返回。

如果查询慢日志发现，并不是复杂度较高的命令导致的，例如都是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的主动过期的定时任务，也是在Redis主线程中执行的 ，也就是说如果在执行主动过期的过程中，出现了需要大量删除过期key的情况，那么在业务访问时，必须等这个过期任务执行结束，才可以处理业务请求。此时就会出现，业务访问延时增大的问题，最大延迟为25毫秒。

而且这个访问延迟的情况， 不会记录在慢日志里。 慢日志中 只记录真正执行某个命令的耗时 ，Redis主动过期策略执行在操作命令之前，如果操作命令耗时达不到慢日志阈值，它是不会计算在慢日志统计中的，但我们的业务却感到了延迟增大。

此时你需要检查你的业务，是否真的存在集中过期的代码，一般集中过期使用的命令是expireat或pexpireat命令，在代码中搜索这个关键字就可以了。

如果你的业务确实需要集中过期掉某些key，又不想导致Redis发生抖动，有什么优化方案？

解决方案是， 在集中过期时增加一个随机时间，把这些需要过期的key的时间打散即可。

伪代码可以这么写：

# 在过期时间点之后的5分钟内随机过期掉

redis.expireat(key, expire_time + random(300))

这样Redis在处理过期时，不会因为集中删除key导致压力过大，阻塞主线程。

另外，除了业务使用需要注意此问题之外，还可以通过运维手段来及时发现这种情况。

我们需要对这个指标监控，当在 很短时间内这个指标出现突增 时，需要及时报警出来，然后与业务报慢的时间点对比分析，确认时间是否一致，如果一致，则可以认为确实是因为这个原因导致的延迟增大。

有时我们把Redis当做纯缓存使用，就会给实例设置一个内存上限maxmemory，然后开启LRU淘汰策略。

当实例的内存达到了maxmemory后，你会发现之后的每次写入新的数据，有可能变慢了。

导致变慢的原因是，当Redis内存达到maxmemory后，每次写入新的数据之前，必须先踢出一部分数据，让内存维持在maxmemory之下。

这个踢出旧数据的逻辑也是需要消耗时间的，而具体耗时的长短，要取决于配置的淘汰策略：

具体使用哪种策略，需要根据业务场景来决定。

我们最常使用的一般是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的压力分摊到多个实例上，可以在一定程度降低延迟。

如果你的Redis开启了自动生成RDB和AOF重写功能，那么有可能在后台生成RDB和AOF重写时导致Redis的访问延迟增大，而等这些任务执行完毕后，延迟情况消失。

遇到这种情况，一般就是执行生成RDB和AOF重写任务导致的。

生成RDB和AOF都需要父进程fork出一个子进程进行数据的持久化，在fork执行过程中，父进程需要拷贝内存页表给子进程，如果整个实例内存占用很大，那么需要拷贝的内存页表会比较耗时，此过程会消耗大量的CPU资源，在完成fork之前，整个实例会被阻塞住，无法处理任何请求，如果此时CPU资源紧张，那么fork的时间会更长，甚至达到秒级。这会严重影响Redis的性能。

具体原理也可以参考我之前写的文章：Redis持久化是如何做的？RDB和AOF对比分析。

我们可以执行info命令，查看最后一次fork执行的耗时latest_fork_usec，单位微妙。这个时间就是整个实例阻塞无法处理请求的时间。

除了因为备份的原因生成RDB之外，在 主从节点第一次建立数据同步时 ，主节点也会生成RDB文件给从节点进行一次全量同步，这时也会对Redis产生性能影响。

要想避免这种情况，我们需要规划好数据备份的周期，建议 在从节点上执行备份，而且最好放在低峰期执行。 如果对于丢失数据不敏感的业务，那么不建议开启AOF和AOF重写功能。

另外，fork的耗时也与系统有关，如果把Redis部署在虚拟机上，那么这个时间也会增大。所以使用Redis时建议部署在物理机上，降低fork的影响。

很多时候，我们在部署服务时，为了提高性能，降低程序在使用多个CPU时上下文切换的性能损耗，一般会采用进程绑定CPU的操作。

但在使用Redis时，我们不建议这么干，原因如下。

绑定CPU的Redis，在进行数据持久化时，fork出的子进程，子进程会继承父进程的CPU使用偏好，而此时子进程会消耗大量的CPU资源进行数据持久化，子进程会与主进程发生CPU争抢，这也会导致主进程的CPU资源不足访问延迟增大。

所以在部署Redis进程时，如果需要开启RDB和AOF重写机制，一定不能进行CPU绑定操作！

上面提到了，当执行AOF文件重写时会因为fork执行耗时导致Redis延迟增大，除了这个之外，如果开启AOF机制，设置的策略不合理，也会导致性能问题。

开启AOF后，Redis会把写入的命令实时写入到文件中，但写入文件的过程是先写入内存，等内存中的数据超过一定阈值或达到一定时间后，内存中的内容才会被真正写入到磁盘中。

AOF为了保证文件写入磁盘的安全性，提供了3种刷盘机制：

当使用第一种机制appendfsync always时，Redis每处理一次写命令，都会把这个命令写入磁盘，而且 这个操作是在主线程中执行的。

内存中的的数据写入磁盘，这个会加重磁盘的IO负担，操作磁盘成本要比操作内存的代价大得多。如果写入量很大，那么每次更新都会写入磁盘，此时机器的磁盘IO就会非常高，拖慢Redis的性能，因此我们不建议使用这种机制。

与第一种机制对比，appendfsync everysec会每隔1秒刷盘，而appendfsync no取决于操作系统的刷盘时间，安全性不高。因此我们推荐使用appendfsync everysec这种方式，在最坏的情况下，只会丢失1秒的数据，但它能保持较好的访问性能。

当然，对于有些业务场景，对丢失数据并不敏感，也可以不开启AOF。

如果你发现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的稳定运行。

在上文中，主要讲解了 Redis 常见的导致变慢的场景以及问题定位和分析，主要是由业务使用不合理和运维不当导致的。

H. Redis缓存过期机制

一、针对与设置了过期时间的key值

    1.（主动）定期删除：定时随机的检查过期的key，如果过期则清理删除

        redis.conf(每秒检查的次数1-500)配置:   hz 10

    2.（被动）惰性删除：当客户端请求到一个已经过期的key时，redis会检查是否过期并删除

所以，虽然key过期了，但是没被清理的话，还是会占内存的。

二、内存淘汰管理机制Memory Management

    当内存占满之后，redis提供缓存淘汰机制。

    redis.conf: maxmemory <bytes>

* noeviction：旧缓存永不过期，新缓存设置不了，返回错误 

* allkeys-lru：清除最少用的旧缓存，然后保存新的缓存（推荐使用）

* allkeys-random：在所有的缓存中随机删除（不推荐）

* volatile-lru：在那些设置了expire过期时间的缓存中，清除最少用的旧缓存，然后保存新的缓存

* volatile-random：在那些设置了expire过期时间的缓存中，随机删除缓存

* volatile-ttl：在那些设置了expire过期时间的缓存中，删除即将过期的

I. redis做mysql的缓存

redis缓存其实就是把经常访问的数据放到redis里面，用户查询的时候先去redis查询，没有查到就执行sql语句查询，同时把数据同步到redis里面。redis只做读操作，在内存中查询速度快。

使用redis做缓存必须解决两个问题，首先就是确定用何种数据结构存储来自mysql的数据；确定数据结构之后就是需要确定用什么标识来作为数据的key。
mysql是按照表存储数据的，这些表是由若干行组成。每一次执行select查询，mysql都会返回一个结果集，这个结果是由若干行组成的。redis有五种数据结构：列表list，哈希hash，字符串string，集合set，sorted set(有序集合)，对比几种数据结构，string和hash是比较适合存储行的数据结构，可以把数据转成json字符串存入redis。

全量遍历键： keys pattern keys *
有人说 KEYS 相当于关系性数据的库的 select * ，在生产环境几乎是要禁用的

不管上面说的对不对， keys 肯定是有风险的。那我们就换一种方案，在存数据的时候。把数据的键存一下，也存到redis里面选hash类型，那么取的时候就可以直接通过这个hash获取所有的值，自我感觉非常好用！

J. 我配置了redis注解缓存，为什么不起作用

作为缓存服务器，如果不加以限制内存的话，就很有可能出现将整台服务器内存都耗光的情况，可以在redis的配置文件里面设置：
example：
#
限定最多使用1.5GB内存
maxmemory
1536mb
如果内存到达了指定的上限，还要往redis里面添加更多的缓存内容，需要设置清理内容的策略：
默认为0，没有指定最大缓存，如果有新的数据添加，超过最大内存，则会使redis崩溃，所以一点要设置。
设置maxmemory之后，配合的要设置缓存数据回收策略。