两种策略
一、持久化策略
1. 为什么需要持久化
了解持久化策略之前,我们需要知道redis为什么需要持久化,是因为redis数据是保存在内存中,为了避免关闭程序之后数据丢失,所以我们需要将数据保存在磁盘文件上,这个过程就是持久化。
2. 持久化的分类
1.RDB
1.1 RDB的原理
RDB是redis默认的持久化策略,当redis中写操作达到指定的次数同时距离上一次持久化达到指定的时间就会将redis内存中数据生成数据快照保存到指定的rdb文件中。
1.2 RDB默认触发持久化的条件
900s/1次 | 900秒中修改至少1个键 |
300s/10次 | 300秒中修改至少10个键 |
60s/10000次 | 60秒中修改至少10000个键 |
1.3 选择持久化策略
视业务场景而定:
允许少量数据丢失,性能要求高,选择RDB
只允许很少数据丢失,选择AOF
几乎不允许数据丢失,选择RDB + AOF
1.4 配置方法
在redis.config中配置持久化代码
- # Save the DB on disk:保存数据库到磁盘
- #
- # save <秒> <更新>
- #
- # 如果指定的秒数和数据库写操作次数都满足了就将数据库保存。
- #
- # 下面是保存操作的实例:
- # 900秒(15分钟)内至少1个key值改变(则进行数据库保存--持久化)
- # 300秒(5分钟)内至少10个key值改变(则进行数据库保存--持久化)
- # 60秒(1分钟)内至少10000个key值改变(则进行数据库保存--持久化)
- #
- # 注释:注释掉“save”这一行配置项就可以让保存数据库功能失效。
- #
- # 你也可以通过增加一个只有一个空字符串的配置项(如下面的实例)来去掉前面的“save”配置。
- #
- # save ""
- save 900 1
- save 300 10
- save 60 10000
- #在默认情况下,如果RDB快照持久化操作被激活(至少一个条件被激活)并且持久化操作失败,Redis则会停止接受更新操作。
- #这样会让用户了解到数据没有被正确的存储到磁盘上。否则没人会注意到这个问题,可能会造成灾难。
- #
- #如果后台存储(持久化)操作进程再次工作,Redis会自动允许更新操作。
- #
- #然而,如果你已经恰当的配置了对Redis服务器的监视和备份,你也许想关掉这项功能。
- #如此一来即使后台保存操作出错,redis也仍然可以继续像平常一样工作。
- stop-writes-on-bgsave-error yes
- #是否在导出.rdb数据库文件的时候采用LZF压缩字符串和对象?
- #默认情况下总是设置成‘yes’, 他看起来是一把双刃剑。
- #如果你想在存储的子进程中节省一些CPU就设置成'no',
- #但是这样如果你的kye/value是可压缩的,你的到处数据接就会很大。
- rdbcompression yes
- #从版本RDB版本5开始,一个CRC64的校验就被放在了文件末尾。
- #这会让格式更加耐攻击,但是当存储或者加载rbd文件的时候会有一个10%左右的性能下降,
- #所以,为了达到性能的最大化,你可以关掉这个配置项。
- #
- #没有校验的RDB文件会有一个0校验位,来告诉加载代码跳过校验检查。
- rdbchecksum yes
- # 导出数据库的文件名称
- dbfilename dump.rdb
- # 工作目录
- #
- # 导出的数据库会被写入这个目录,文件名就是上面'dbfilename'配置项指定的文件名。
- #
- # 只增的文件也会在这个目录创建(这句话没看明白)
- #
- # 注意你一定要在这个配置一个工作目录,而不是文件名称。
- dir ./
1.5 RDB的优缺点
优点:
(1)在数据量较小的情况下,执行速度比较快
(2)由于RDB是以数据快照形式保存的,我们可以通过检索拷贝rdb文件轻松实现redis数据移植
缺点:
(1)如果redis出现故障,存在数据丢失的风险,丢失上一次持久化之后的操作数据(因为每次持久化,都会有操作次数以及时间间隔)
(2)RDB采用的数据快照的形式进行的持久化,不适合实时性持久化
(3)如果数据量庞大,在RDB持久化过程中生成数据快照子进程执行时间过长,会导致redis卡顿,因此Save的时间周期设置不宜过短(默认配置即可)
2.AOF
2.1 AOF的原理
redis将每一个成功的写操作写入aof文件中,当redis重启的时候就执行aof文件中的指令以恢复数据
2.2 AOF触发持久化的条件:
appendfsync always | 只要进行成功写操作,aof就执行 |
appendfsync everysec | 每秒进行一次aof(默认) |
appendfsync no | 让redis执行决定aof |
redis默认是AOF未开启的;可以通过将redis配置文件中‘appendonly no’修改为‘appendonly yes’进行开启 ;AOF也可以设置aof路径,默认是‘appendfilename "appendonly.aof"’
2.3 AOF持久化细节分析
1.可以通过拷贝aof文件jinxingredis数据移植
2.aof存储的是指令,而且会对指令进行整理,而RDB直接生成的数据快照,在数据量不大的时候会比较快
3.aof是对文件进行增量更新,更适合实时性持久化
4.redis官方建议是同时开启两种持久化策略,如果同时存在aof文件以及rdb文件,当我们需要进行数据移植的时候,优先选择aof(数据完整性会相对高一点)
二、淘汰策略
1.什么是淘汰策略
Redis中的数据太多可能导致内存溢出,Redis会根据情况淘汰一些数据。 Redis的内存上限:64位系统,上限就是内存上限;32位系统,最大是4G 配置最大内存:max-memory 配置0就是无上限(默认)。
2.配置淘汰策略
2.1 分类
noevication | 不淘汰(默认) |
volatile-ttl | 在将过期键中淘汰存活时间短的键 |
volatile-lfu | 在将过期的键中淘汰使用频率较少的键 |
volatile-lru | 在将过期的键中淘汰很久前使用的键 |
volatile-random | 在将过期键中随机淘汰 |
allkeys-random | 在所有键中随机淘汰 |
allkeys-lfu | 在所有键中淘汰使用频率较少的键 |
allkeys-lru | 在所有键中使用LRU算法淘汰比较少使用的键 (推荐) |
2.2 涉及的算法
主要是4种算法,针对不同的key,形成的策略。
算法:
- lru 最近很少的使用的key(根据时间,最不常用的淘汰)
- lfu 最近很少的使用的key (根据计数器,用的次数最少的key淘汰)
- random 随机淘汰
- ttl 快要过期的先淘汰
2.3内存淘汰算法的具体工作原理是
1.客户端执行一条新命令,导致数据库需要增加数据(比如set key value)
2.Redis会检查内存使用,如果内存使用超过 maxmemory,就会按照置换策略删除一些 key
3.新的命令执行成功
总结
redis的两种策略,都是为了提升机器的性能,针对不同的情况选择不同的处理方式,提升用户体验感。