Redis是内存数据库数据都是存储在内存中为了避免进程退出导致数据的永久丢失需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘当下次Redis重启时利用持久化文件实现数据恢复。

除此之外为了进行灾难备份可以将持久化文件拷贝到一个远程位置

3服务端调用write这个系统调用将数据往磁盘上写(数据在系统内存的缓冲区中)。

4操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)。

5磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)。

这5个过程是在理想条件下一个正常的保存流程但是在大多数情况下我们的机器等等都会有各种各样的故障这里划分了两种情况

1Redis数据库发生故障只要在上面的第三步执行完毕那么就可以持久化保存剩下的两步由操作系统替我们完成。

为应对以上5步操作redis提供了两种不同的持久化方式RDB(Redis

DataBase)和AOF(Append

在指定的时间间隔能对你的数据进行快照存储。

是将当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化)保存的文件后缀是rdb当Redis重新启动时可以读取快照文件恢复数据。

既然RDB是在指定时间间隔进行快照存储那么这个时间间隔到底是多久呢多久触发一次RDB操作呢这就要聊一聊他的触发原理了。

redis.conf

主要有两个命令save命令和bgsave命令都可以生成RDB文件

save会阻塞当前Redis服务器直到RDB文件创建完毕为止线上应该禁止使用。

在接收到save命令后redis服务器的主进程就会读取内存和生成RDB文件这两件事合为RDB操作由主进程实现所以主进程干这个事去了就无法处理新的redis客户端的请求了就会阻塞住。

bgsave该触发方式会fork一个子进程由子进程负责持久化过程因此阻塞只会发生在fork子进程的时候。

进行fork操作后会利用操作系统的“写时复制”Copy-On-WriteCOW机制

1、执行bgsave命令的时候会通过fork()创建子进程此时子进程和父进程是共享同一片内存数据的因为创建子进程的时候会复制父进程的页表但是页表指向的物理内存还是同一个

这时候共享同一片物理内存然后直接读取生成临时rdb文件生成完毕再覆盖之前的rdb文件就结束bgsave的流程。

但是你会有一个疑问

都是共享一片内存那父进程这时候收到别的redis客户端请求需要写数据那么不同样会操作同一片内存空间吗就会造成错误。

2、这时就有了写时复制只有在修改内存数据的情况时物理内存才会被复制一份。

然后各个进程各自读各自的内存互不影响

redis.conf配置自动触发

表示900s内如果有1条是写入命令就触发产生一次快照可以理解为就进行一次备份save

300

从节点全量复制时主节点发送rdb文件给从节点完成复制操作主节点会触发

bgsave执行

是周期性持久化假设时间间隔为5s第1s进行更新第4s发送宕机本来该第5s发送下一次快照更新但是由于宕机第1s和第4s之间的更新操作就丢失了也就是说在上次快照和故障之间的数据会丢失。

对于高可用需求的场景AOF可能更合适。

资源开销大由于RDB是进行全量更新所以时间间隔不能设置太短否则导致频繁生成快照执行fork命令等等RDB

持久化使用

AOF通过记录每次对服务器写的操作命令,当服务器重启的时候会重新执行这些命令来恢复原始的数据。

以日志的形式来记录用户请求的写操作读操作不会记录因为写操作才会存储2.

redis的aof恢复其实就是通过一个伪客户端把追加的文件从开始到结尾读取

写操作

可以通过修改redis.conf配置文件中的appendonly参数开启

appendonly

AOF文件的保存位置和RDB文件的位置相同都是通过dir参数设置的。

dir

默认的文件名是appendonly.aof可以通过appendfilename参数修改

appendfilename

)、文件重写(rewrite)和重启加载(load)。

其流程如下

AOF

在执行完一个写命令之后会以协议格式(也就是RESP即Redis

Redis

如果想要高性能就选No如果想要高可靠就选always如果允许数据丢失一点但又想性能高就选择Everysec

重启加载数据恢复

文件而不是网络连接所以服务器使用了一个没有网络连接的伪客户端来执行

AOF

文件保存的写命令伪客户端执行命令的效果和带网络连接的客户端执行命令的效果完全一样的。

从

AOF

文件中分析并取出一条写命令。

使用伪客户端执行被读出的写命令。

一直执行步骤

和步骤3直到

我们先来分析一下AOF采用文件追加方式随着Redis长时间运行会产生什么问题

只有重启才会进行数据恢复那么恢复之后才可以clear掉这个AOF文件但是在重启之前redis长时间运行会导致这个AOF文件越来越大。

AOF

AOF文件重写并不是更新原来的AOF文件而是创建新的AOF文件替换旧的AOF文件

如上图所示重写前要记录名为

文件进行任何读取、分析或者写入操作而是通过读取服务器当前的数据库状态来实现的。

首先从数据库中读取键现在的值然后用一条命令去记录键值对代替之前记录这个键值对的多条命令这就是

AOF

重写机制避免文件越来越大自动优化压缩指令会fork一个新的进程去完成重写动作新进程里的内存数据会被重写此时旧的aof文件不会被读取使用

并且文件体积达到64m满足两者则触发重写

前面几步和我们RDB的流程差不多我们不必多说我们从fork完了之后开始讲起

fork会另开一个子进程拷贝一份主进程的页表然后就可以操作主进程对应的物理内存了这时候子进程就开始进行重写操作①扫描redis的内存数据②逐一的把内存数据的key-value转换成一条命令③再把命令记录到新的AOF文件中如果说在子进程进行重写操作的期间主进程又发生了数据的读写那么子进程重写完了之后会向主进程发送一个信号主进程把这个期间发生的数据读写命令添加到新的AOF文件中最后再用新的AOF文件覆盖旧的AOF文件

在整个

思考一个问题如果一台服务器上有既有RDB文件又有AOF文件该加载谁呢

这里给出一个执行流程图

我们都知道RDB的快照、AOF的重写都需要fork这是一个重量级操作会对Redis造

成阻塞。

因此为了不影响Redis主进程响应我们需要尽可能降低阻塞。

降低fork的频率比如可以手动来触发RDB生成快照、与AOF重写

合理配置Linux的内存分配策略避免因为物理内存不足导致fork失败

实际开发中该怎么做

如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据可以关闭持久化如果丢失数据可以通过其它途径补回2.

自己制定策略定期检查Redis的情况然后可以手动触发备份、重写数据3.

可以加入主从机器利用一台从机器进行备份处理其它机器正常响应客户端的命令4.

在redis内部每当我们设置一个键的过期时间时Redis就会将该键带上过期时间存放到一个过期字典中。

过期字典的结构

typedef

当我们查询任意一个键时Redis首先检查该键是否存在于过期字典哈希表中

如果不在则正常读取value如果存在则会获取该key的过期时间然后与当前系统时间进行比对如果比系统时间大那就没有过期否则判定该key已过期

1、定时删除

的过期时间同时我们创建一个定时器让定时器在该过期时间到来时立即执行对其进行删除的操作。

2、惰性删除

过期时间后我们不去管它当需要该key时我们在检查其是否过期如果过期我们就删掉它反之返回该key。

3、定期删除

会检查该键是否过期扫描过期字典比对时间。

如果过期则删除该键。

删除了之后再执行get命令肯定会报错呀

定期删除Redis

会定期以固定时间间隔扫描数据库中的一部分键删除过期的键。

它通常会检查每个数据库的

10%

Redis是基于内存的所以肯定有上限肯定也有瓶颈当Redis的运行内存已经超过Redis设置的最大内存之后则会使用内存淘汰策略删除符合条件的key以此来保障Redis的继续运行

bytes来设定最大内存

1noeviction(Redis3.0之后默认的内存淘汰策略)

它表示当运行内存超过最大设置内存时不淘汰任何数据这时如果有新的数据写入则会触发

OOM但是如果没用数据写入的话只是单纯的查询或者删除操作的话还是可以正常工作。

剩下7种

淘汰最不常用的键。

allkeys-random随机淘汰任意键。

volatile-lru对有过期时间的键使用

LFU。

volatile-random随机淘汰有过期时间的键。

volatile-ttl优先淘汰过期时间最接近的键。

LRU:

淘汰最久未使用的键。

适合那些有时效性的数据能让最近活跃的键优先保留。

LRU

算法。

在LRU的实现中redis会给每个数据增加一个类似于时间戳的字段Redis

并不记录每个键的访问顺序而是通过定期从键空间中随机采样若干键并根据其“上次使用时间”来淘汰其中最不常使用的键。

这种方法能够在减少开销的前提下接近实现

LRU

LRU会导致缓存污染问题特别是在访问模式中包含大量短时、随机访问的数据时。

由于

LRU

会优先淘汰“最近最少使用”的数据较少被访问的重要数据可能在频繁的短时访问数据引入时被替换掉。

这样重要的但低频率的数据可能被过早清除

LFU淘汰使用频率最低的键。

适用于访问频率具有稳定性的场景因为它能识别出“冷”数据并优先淘汰这些低频使用的键。

所以能解决缓存污染问题不会因像LRU算法的偶尔一次被访问被误认为是热点数据

在Redis中实现LFU是在LRU的基础上将LRU的“时间戳字段24bit”拆分成两部分前16bit表示数据的访问时间戳后8bit表示数据的访问次数

当LFU策略筛选数据时Redis会在候选集合中根据数据LRU字段的后8bit选择访问次数最少的数据进行淘汰当访问次数相同时再根据LRU字段的前16bit值大小选择访问时间最久远的数据进行淘汰。

三、性能压测

介绍一个工具专门用来对redis进行压测目前也是主流使用--------redis-benchmark

redis-benchmark工具来模拟

序号选项描述默认值1-h指定服务器主机名127.0.0.12-p指定服务器端口63793-s指定服务器

socket4-c指定并发连接数505-n指定请求数100006-d以字节的形式指定

SET/GET

的小写字母生成循环永久执行测试13-t仅运行以逗号分隔的测试命令列表。

14*-I*i

idle