Redis 过期策略+conf 记录

一：redis的过期策略

三种过期键删除策略
1）定时删除：创建一个定时器，到时间立即执行删除操作（对内存友好，因为能保证过期了立马删除，但是对cpu不友好）

2）惰性删除：键过期不管，每次获取键时调用expireIfNeeded(）方法检查是否过期，过期就删除，并返回不存在（对cpu友好，但是只有在使用的时候才可能删除，对内存不友好）

3）定期删除：Redis 默认会每秒进行 10 次（redis.conf 中通过 hz 配置）过期扫描

Redis会通过执行定期任务来主动清除过期key，执行过程如下：

1. 从设置了过期时间的key的集合中随机检查20【Redis参数，默认是20】个key
2. 删除检查中发现的所有过期key。
3. 如果检查结果中25%以上的key已过期，则重复1,2
4. (

   每秒钟执行server.hz次serverCron()方法serverCron()调用databasesCron()，databasesCron()调用activeExpireCycle()

   activeExpireCycle()对每个expires[*]逐一进行检测，每次执行250ms/server.hz，其中expires[*]表示redis数据库的过期数据信息内存块

   )

1：检查结果中25%以上的key已过期，Redis就会循环扫描多次删除以释放内存空间，注意，删除操作时阻塞（Redis 4.0 后可以用异步线程机制（BIO）来减少阻塞影响）。所以一旦该条件触发，Redis的线程就会一直执行删除，就会无法正常服务其他键值对操作，进一步引起其他键值操作的延迟增加，Redis就会变慢。

2：如果过期key数量很多或者增加速度很快，而Redis的主动清除频率较低，过期key将占用大量的内存空间，可能会影响Redis服务的性能。适当调整hz参数的值，提高清除频率

3：为了保证扫描不会出现循环过度，导致线程卡死现象，还增加了扫描时间的上限，默认是 25 毫秒，所以客户端设置的超时时间不能小于 25 毫秒，否则就会导致链接因为超时而关闭，就会造成异常

Redis服务器实际使用的是惰性删除和定期删除两种策略：通过配合使用这两种删除策略，服务器可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡。Redis默认每隔100ms随机抽取一些设置了过期时间的key，检查是否过期，如果过期就删除

二：内存淘汰机制

Redis 的内存占用会越来越高。Redis 为了限制最大使用内存，提供了 redis.conf 中的 配置参数 maxmemory。当内存超出 maxmemory，Redis 提供了几种内存淘汰机制让用户选择，配置 maxmemory-policy：

• noeviction：当内存超出 maxmemory，写入请求会报错，但是删除和读请求可以继续。
• allkeys-lru：当内存超出 maxmemory，在所有的 key 中，移除最少使用的key。只把 Redis 既当缓存是使用这种策略。
• allkeys-random：当内存超出 maxmemory，在所有的 key 中，随机移除某个 key。
• volatile-lru：当内存超出 maxmemory，在设置了过期时间 key 的字典中，移除最少使用的 key。把 Redis 既当缓存，又做持久化的时候使用这种策略。
• volatile-random：当内存超出 maxmemory，在设置了过期时间 key 的字典中，随机移除某个key。
• volatile-ttl：当内存超出 maxmemory，在设置了过期时间 key 的字典中，优先移除 ttl 小的

逐出算法
redis使用内存存储数据，在执行每一个命令前，会调用freeMemoryIfNedded()检测内存是否充足，如果内存不满足新加入数据的最低存储要求，redis要临时删除一些数据为当前指令清理存储空间，清理数据的策略称为逐出算法
逐出数据的过程不是100%能够清理出足够的可使用的内存空间的，如果不成功则反复执行，当对所有数据尝试完毕后，如果不能达到内存中的存储要求，将报错

三：基本配置了解

cd /usr/local/redis/bin  ,./redis-cli -h 172.19.0.1 -p 6379

查看redis的内存淘汰机制：config get maxmemory-policy 

​

redis.conf 

hz 10

(调整Redis定期任务的执行频率

通过修改hz参数的值，您可以调整Redis执行定期任务的频率，从而改变Redis清除过期key、清理超时连接的效率)

为了定期检测资源和服务状态并根据预定策略执行相应的操作，Redis调用一个内部函数来执行多种后台任务，例如：

• 计算LRU信息并清除过期key。
• 关闭超时的客户端连接。
• 整理hash类型的数据。
• 执行RDB或AOF持久化相关操作。
• 更新统计信息

这些定期任务是Redis服务正常运行的保障，它们的执行频率由hz参数的值指定，默认为10，即每秒执行10次

databases 16

Redis默认支持16个数据库，这可以通过修改Redis的配置文件/redis/redis.conf中的databases字段的值，设置完毕并重启Redis即可完成配置。

此外，客户端与Redis建立连接之后，默认会选择0号数据库即db0，但可以使用select命令更换存储的数据库

一般springboot使用配置：

spring.redis.database=0
spring.redis.host=172.66.20.1
spring.redis.port=6379
spring.redis.timeout=2000

daemonize no

Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程 # 启用守护进程后，Redis会把pid写到一个pidfile中，在/var/run/redis.pid

save 900 1
save 300 10
save 60 10000

满足以下条件将会同步数据:
#   900秒（15分钟）内有1个更改,则持久化1次
#   300秒（5分钟）内有10个更改,则持久化1次
#   60秒内有10000个更改,则持久化1次

stop-writes-on-bgsave-error yes

默认值为yes，进行 RDB 备份文件生成过程中遭遇错误，是否停止 redis 提供写服务

备份过程中redis 会fork一个新的后台进程dump rdb(异步执行，不影响主进程后续命令执行)。但Fork子进程，涉及父进程的内存复制，会增加服务器内存开销，比如：如果主进程使用了2GB的内存，Fork子进程的时候需要额外的2GB，容易造成内存不够，当bgsave快照操作出错时,比如磁盘满了,停止写数据到磁盘,Redis也会拒绝新的写入。因此使用bgsave需要保证服务器空闲内存足够(可以通过top -p pid动态监控内存使用情况)

rdbcompression yes

指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大

dbfilename dump.rdb

dbfilename 配置项决定了生成的 RDB 文件名称，默认配置为 dump.rdb

rdbchecksum yes

rdbchecksum 配置 redis 是否使用 CRC64 校验算法校验 RDB 文件是否发生损坏，默认开启状态，如果你需要提升性能，可以选择性关闭

slave-serve-stale-data yes

当从库同主机失去连接或者复制正在进行，yes(默认设置)，从库会继续响应客户端的请求

no，除去INFO和SLAVOF命令之外的任何请求都会返回一个错误”SYNC with master in progress”

slave-read-only yes

保证从节点只有读的操作

repl-disable-tcp-nodelay no

设置成yes，则redis会合并小的TCP包从而节省带宽，但会增加同步延迟（最长40ms），造成master与slave数据不一致，适合垮机房部署的情况

设置成no，则redis master会立即发送同步数据，数据的延迟将将减少，但将使用更多带宽进行复制，适合主从网络环境良好的场景

slave-priority 100

slave端的优先级设置，值是一个整数，数字越小表示优先级越高

默认情况下，优先级为100。当master故障时将会按照优先级来选择slave端进行恢复，如果值设置为0，则表示该slave将标记为永远不被选则

appendonly no

yes开启AOF，no关闭AOF 默认 no

appendfilename "appendonly.aof"

生成的 aof文件名称

appendfsync everysec

  三种不同模式：always、everysec和no

 设置为always时，会极大消弱Redis的性能，因为这种模式下每次write后都会调用fsync

如果设置为no，则write后不会有fsync调用，由操作系统自动调度刷磁盘，性能是最好的

everysec为最多每秒调用一次fsync，这种模式性能并不是很糟糕，一般也不会产生毛刺，这归功于Redis引入了BIO线程，所有fsync操作都异步交给了BIO线程（Redis 4.0.0版本后）

no-appendfsync-on-rewrite no

当AOF fsync策略设置为always或everysec时,主进程中调用fsync（）同时bgrewriteaof也在操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形。

如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes，这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。在linux的操作系统的默认设置下，最多会丢失30s的数据

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

自动重写隐式调用的日志文件规则

指定 Redis 重写 AOF 文件的条件，默认为 100，它会对比上次生成的 AOF 文件大小。如果当前 AOF 文件的增长量大于上次 AOF 文件的 100%，就会触发重写操作；如果将该选项设置为 0，则不会触发重写操作

lua-time-limit 5000

Lua脚本最大执行时间，默认5秒