推荐聊城做网站,wordpress 菜单去掉链接,电子政务公开 网站建设,wordpress开一、持久化原理
Redis是内存数据库#xff0c;数据都是存储在内存中#xff0c;为了避免进程退出导致数据的永久丢失#xff0c;需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘#xff1b;当下次Redis重启时#xff0c;利用持久化文件实现数据恢复。除此…一、持久化原理
Redis是内存数据库数据都是存储在内存中为了避免进程退出导致数据的永久丢失需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘当下次Redis重启时利用持久化文件实现数据恢复。除此之外为了进行灾难备份可以将持久化文件拷贝到一个远程位置
既然redis的数据可以保存在磁盘上那么这个流程是什么样的呢
1客户端向服务端发送写操作(数据在客户端的内存中)。
2数据库服务端接收到写请求的数据(数据在服务端的内存中)。
3服务端调用write这个系统调用将数据往磁盘上写(数据在系统内存的缓冲区中)。
4操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)。
5磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)。
前三步是由redis完成的后两步是由OS完成的
这5个过程是在理想条件下一个正常的保存流程但是在大多数情况下我们的机器等等都会有各种各样的故障这里划分了两种情况
1Redis数据库发生故障只要在上面的第三步执行完毕那么就可以持久化保存剩下的两步由操作系统替我们完成。
2操作系统发生故障必须上面5步都完成才可以。
为应对以上5步操作redis提供了两种不同的持久化方式RDB(Redis DataBase)和AOF(Append Only File)
RDB和AOF都可以在redis.conf进行相关配置
RDB详解
RDB是什么
在指定的时间间隔能对你的数据进行快照存储。是将当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化)保存的文件后缀是rdb当Redis重新启动时可以读取快照文件恢复数据。
RDB的触发及其原理
既然RDB是在指定时间间隔进行快照存储那么这个时间间隔到底是多久呢多久触发一次RDB操作呢这就要聊一聊他的触发原理了。
在Redis中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配置自动触发
根据我们的 save m n 配置规则自动触发redis.conf如下配置
# 时间策略
save 900 1 # 表示900 秒内如果至少有 1 个 key 的值变化则触发RDB
save 300 10 # 表示300 秒内如果至少有 10 个 key 的值变化则触发RDB
save 60 10000 # 表示60 秒内如果至少有 10000 个 key 的值变化则触发RDB# 文件名称
dbfilename dump.rdb# 文件保存路径
dir /home/work/app/redis/data/# 如果持久化出错主进程是否停止写入
stop-writes-on-bgsave-error yes# 是否压缩
rdbcompression yes# 导入时是否检查
rdbchecksum yes
配置其实非常简单这里说一下持久化的时间策略具体是什么意思。
save 900 1 表示900s内如果有1条是写入命令就触发产生一次快照可以理解为就进行一次备份save 300 10 表示300s内有10条写入就产生快照
其他一些自动触发机制
从节点全量复制时主节点发送rdb文件给从节点完成复制操作主节点会触发 bgsave执行 debug reload 时执行 shutdown时如果没有开启aof也会触发。
面试题RDB有什么缺点 数据丢失风险RDB 是周期性持久化假设时间间隔为5s第1s进行更新第4s发送宕机本来该第5s发送下一次快照更新但是由于宕机第1s和第4s之间的更新操作就丢失了也就是说在上次快照和故障之间的数据会丢失。对于高可用需求的场景AOF可能更合适。 资源开销大由于RDB是进行全量更新所以时间间隔不能设置太短否则导致频繁生成快照执行fork命令等等RDB 持久化使用 fork 生成子进程并且占用大量内存。对于大型数据集频繁的 RDB 持久化可能对性能产生负面影响。 执行时间较长RDB 的生成需要将整个内存快照写入磁盘对于大量数据会消耗较长时间。
AOF详解
AOF是什么
AOF通过记录每次对服务器写的操作命令,当服务器重启的时候会重新执行这些命令来恢复原始的数据。
特点
1. 以日志的形式来记录用户请求的写操作读操作不会记录因为写操作才会存储2. 文件以追加的形式而不是修改的形式3. redis的aof恢复其实就是通过一个伪客户端把追加的文件从开始到结尾读取 执行 写操作
如何在redis.conf开启 AOF
# 可以通过修改redis.conf配置文件中的appendonly参数开启
appendonly yes# AOF文件的保存位置和RDB文件的位置相同都是通过dir参数设置的。
dir .# 默认的文件名是appendonly.aof可以通过appendfilename参数修改
appendfilename appendonly.aof
AOF实现流程 如上图所示AOF 持久化功能的实现可以分为命令追加( append )、文件写入( write )、文件同步( sync )、文件重写(rewrite)和重启加载(load)。其流程如下
所有的写命令会追加到 AOF 缓冲中。AOF 缓冲区根据对应的策略向硬盘进行同步操作。随着 AOF 文件越来越大需要定期对 AOF 文件进行重写达到压缩的目的。当 Redis 重启时可以加载 AOF 文件进行数据恢复。
接下来我们分别介绍这几个部分
命令追加
当 AOF 持久化功能处于打开状态时Redis 在执行完一个写命令之后会以协议格式(也就是RESP即Redis 客户端和服务器交互的通信协议 )将被执行的写命令追加到 Redis 服务端维护的 AOF 缓冲区末尾。
文件写入同步 Redis 每次结束一个事件循环之前写事件它都会调用 flushAppendOnlyFile 函数判断是否需要将 AOF 缓冲区中的内容写入和同步到 AOF 文件中。 flushAppendOnlyFile 函数的行为由 redis.conf 配置中的 appendfsync 选项的值来决定。该选项有 三个可选值分别是 always 、 everysec 和 no always 每执行一个命令保存一次 高消耗,最安全 everysec 每一秒钟保存一次 no 只写入 不保存 AOF 或 Redis 关闭时执行由操作系统触发刷新文件到磁盘 三个配置项优缺点分析 大家根据自己的业务场景进行选择
如果想要高性能就选No如果想要高可靠就选always如果允许数据丢失一点但又想性能高就选择Everysec
重启加载数据恢复
本质就是读取aof文件进行命令执行数据恢复 以上是数据恢复的大致流程
详细流程剖析如下
创建一个不带网络连接的的伪客户端( fake client)因为 Redis 的命令只能在客户端上下文中执行而载入 AOF 文件时所使用的的命令直接来源于 AOF 文件而不是网络连接所以服务器使用了一个没有网络连接的伪客户端来执行 AOF 文件保存的写命令伪客户端执行命令的效果和带网络连接的客户端执行命令的效果完全一样的。从 AOF 文件中分析并取出一条写命令。使用伪客户端执行被读出的写命令。一直执行步骤 2 和步骤3直到 AOF 文件中的所有写命令都被处理完毕为止。
AOF文件重写rewrite
我们先来分析一下AOF采用文件追加方式随着Redis长时间运行会产生什么问题 只有重启才会进行数据恢复那么恢复之后才可以clear掉这个AOF文件但是在重启之前redis长时间运行会导致这个AOF文件越来越大。
为了解决 AOF 文件体积膨胀的问题Redis 提供了 AOF 文件重写( rewrite) 策略
AOF文件重写并不是更新原来的AOF文件而是创建新的AOF文件替换旧的AOF文件 如上图所示重写前要记录名为 list 的键的状态AOF 文件要保存五条命令而重写后则只需要保存一条命令。 AOF 文件重写并不需要对现有的 AOF 文件进行任何读取、分析或者写入操作而是通过读取服务器当前的数据库状态来实现的。首先从数据库中读取键现在的值然后用一条命令去记录键值对代替之前记录这个键值对的多条命令这就是 AOF 重写功能的实现原理。
如何触发AOF文件重写
手动调用 bgrewriteaof 命令如果当前有正在运行的 rewrite 子进程则本次rewrite 会推迟执行否则直接触发一次 rewrite自动触发 就是根据配置规则来触发
# 重写机制避免文件越来越大自动优化压缩指令会fork一个新的进程去完成重写动作新进程里的内存数据会被重写此时旧的aof文件不会被读取使用
# 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m满足两者则触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
接下来让我们探究一下AOF文件重写的原理吧
文件重写原理 前面几步和我们RDB的流程差不多我们不必多说我们从fork完了之后开始讲起
fork会另开一个子进程拷贝一份主进程的页表然后就可以操作主进程对应的物理内存了这时候子进程就开始进行重写操作①扫描redis的内存数据②逐一的把内存数据的key-value转换成一条命令③再把命令记录到新的AOF文件中如果说在子进程进行重写操作的期间主进程又发生了数据的读写那么子进程重写完了之后会向主进程发送一个信号主进程把这个期间发生的数据读写命令添加到新的AOF文件中最后再用新的AOF文件覆盖旧的AOF文件 在整个 AOF 后台重写过程中只有信号处理函数执行时会对 Redis 主进程造成阻塞在其他时候 AOF 后台重写都不会阻塞主进程。 持久化优先级
思考一个问题如果一台服务器上有既有RDB文件又有AOF文件该加载谁呢
这里给出一个执行流程图 持久化原理总结
我们都知道RDB的快照、AOF的重写都需要fork这是一个重量级操作会对Redis造 成阻塞。因此为了不影响Redis主进程响应我们需要尽可能降低阻塞。
降低fork的频率比如可以手动来触发RDB生成快照、与AOF重写 控制Redis最大使用内存防止fork耗时过长 使用更牛逼的硬件 合理配置Linux的内存分配策略避免因为物理内存不足导致fork失败
实际开发中该怎么做
1. 如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据可以关闭持久化如果丢失数据可以通过其它途径补回2. 自己制定策略定期检查Redis的情况然后可以手动触发备份、重写数据3. 可以加入主从机器利用一台从机器进行备份处理其它机器正常响应客户端的命令4. RDB持久化与AOF持久化可以同时存在配合使用。
二、过期删除策略内存淘汰策略
过期删除策略 如何设置过期时间 如何判定Key是否已经过期redis内部原理
在redis内部每当我们设置一个键的过期时间时Redis就会将该键带上过期时间存放到一个过期字典中。过期字典的结构
typedef struct redisDB {dict *dict; //数据库键空间存放着所有的键值对dict *expires; //键的过期时间
} redisDB;
当我们查询任意一个键时Redis首先检查该键是否存在于过期字典哈希表中
如果不在则正常读取value如果存在则会获取该key的过期时间然后与当前系统时间进行比对如果比系统时间大那就没有过期否则判定该key已过期
过期删除策略有哪些
1、定时删除
在设置某个key 的过期时间同时我们创建一个定时器让定时器在该过期时间到来时立即执行对其进行删除的操作。
2、惰性删除
设置该key 过期时间后我们不去管它当需要该key时我们在检查其是否过期如果过期我们就删掉它反之返回该key。
3、定期删除
每隔一段时间我们就对一些key进行检查删除里面过期的key。
面试题那么redis当中是采取什么措施来进行过期删除的呢 惰性删除每次访问一个键时Redis 会检查该键是否过期扫描过期字典比对时间。如果过期则删除该键。删除了之后再执行get命令肯定会报错呀 定期删除Redis 会定期以固定时间间隔扫描数据库中的一部分键删除过期的键。它通常会检查每个数据库的 10% 键并且随着时间推移扫描比例会逐渐增大。
这样Redis 既能保证键的过期及时清理又能避免每次访问时都进行全量扫描。
内存淘汰策略
Redis是基于内存的所以肯定有上限肯定也有瓶颈当Redis的运行内存已经超过Redis设置的最大内存之后则会使用内存淘汰策略删除符合条件的key以此来保障Redis的继续运行 在redis.conf中通过maxmemory bytes来设定最大内存 不设定该参数默认是无限制的但是通常会设定其为物理内存的3/4
Redis内存淘汰策略有哪些
1noeviction(Redis3.0之后默认的内存淘汰策略) 它表示当运行内存超过最大设置内存时不淘汰任何数据这时如果有新的数据写入则会触发 OOM但是如果没用数据写入的话只是单纯的查询或者删除操作的话还是可以正常工作。
剩下7种 LRU最近最少使用 LFU最不常用
allkeys-lru对所有键使用 LRU 淘汰最近最少使用的键。allkeys-lfu对所有键使用 LFU 淘汰最不常用的键。allkeys-random随机淘汰任意键。volatile-lru对有过期时间的键使用 LRU。volatile-lfu对有过期时间的键使用 LFU。volatile-random随机淘汰有过期时间的键。volatile-ttl优先淘汰过期时间最接近的键。
LRU和LFU的区别
LRU: 淘汰最久未使用的键。适合那些有时效性的数据能让最近活跃的键优先保留。
Redis的 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工具来模拟 N 个客户端同时发出 M 个请求,可以便捷对服务器进行读写性能压测
以下是一些参数说明
序号选项描述默认值1-h指定服务器主机名127.0.0.12-p指定服务器端口63793-s指定服务器 socket4-c指定并发连接数505-n指定请求数100006-d以字节的形式指定 SET/GET 值的数据大小27-k1keep alive 0reconnect18-rSET/GET/INCR 使用随机 key, SADD 使用随机值9-P通过管道传输 请求110-q仅显示 query/sec 值11--csv以 CSV 格式输出12*-l*L 的小写字母生成循环永久执行测试13-t仅运行以逗号分隔的测试命令列表。14*-I*i 的大写字母Idle 模式。仅打开 N 个 idle 连接并等待。
示例
