南昌住房建设局网站,徐州58同城网,wordpress瀑布流图片主题,wordpress采集小说的主题谈谈Redis 的持久化策略#xff1f;
参考文章#xff1a;
Redis 持久化机制演进与百度智能云的实践
Redis的确是将数据存储在内存的#xff0c;但是也会有相关的持久化机制将内存持久化备份到磁盘#xff0c;以便于重启时数据能够重新恢复到内存中#xff0c;避免数据丢…谈谈Redis 的持久化策略
参考文章
Redis 持久化机制演进与百度智能云的实践
Redis的确是将数据存储在内存的但是也会有相关的持久化机制将内存持久化备份到磁盘以便于重启时数据能够重新恢复到内存中避免数据丢失的风险。而Redis持久化机制有三种AOF、RDB、混合型持久化4.x版本后提供 RDB持久化 关闭 RDB 持久化只需要将 save 保存策略注释掉即可 RDB持久化的方式有两种 手动触发分为手动 save 和手动 bgsave 手动save阻塞当前 Redis直到持久化完成可能造成长时间阻塞线上不建议使用。 手动bgsaveRedis 进程执行 fork 创建子进程进行持久化阻塞事件很短。在执行Redis-cli shutdown关闭Redis服务时或执行flushall命令时如果没有开启AOF持久化自动执行bgsave 被动触发以下四种情况会被动触发 达到了在 redis.conf 中配置被动触发的条件会触发 bgsave 生成 rdb 文件 Redis 中 save 操作的配置从右向左条件主键变弱如果60s发生了10000次写操作就进行持久化如果没有达到在300s时如果有100次写操作就会持久化如果没有达到在3600s如果有一次写操作就会持久化 主从复制时从节点需要全量同步主节点的数据会触发 bgsave 执行 debug reload 命令重新加载 redis 时会触发 bgsave 执行 shutdown 命令时如果没有开启 aof 持久化会触发 bgsave bgsave子进程工作原理 由子进程继承父进程所有资源且父进程不能拒绝子进程继承bgsave子进程先将内存中的全量数据copy到磁盘的一个RDB临时文件持久化完成后将该临时文件替换原来的dump.rdb文件。 如果持久化过程中出现了新的写请求则系统会将内存中发生数据修改的物理块copy出一个副本bgsave 子进程会把这个副本数据写入 RDB 文件在这个过程中主线程仍然可以直接修改原来的数据fork 使用了 写时复制技术Copy-On-Write。 操作系统中的写时复制技术 目的是避免不必要的内存拷贝。 在Linux系统中调用 fork 系统调用创建子进程时并不会把父进程所有占用的内存页复制一份而是与父进程共用相同的内存页而当子进程或者父进程对内存页进行修改时才会进行复制 —— 这就是著名的 写时复制 机制。 那么bgsave中的写时复制技术即如果在持久化过程中写入了新的数据此时再去将元数据重新拷贝一份进行修改。 优点 使用单独子进程持久化保证 redis 高性能。RDB 持久化存储压缩的二进制文件适用于备份、全量复制可用于灾难备份同时RDB文件的加载速度远超于AOF文件。 缺点 没有实时持久化可能造成数据丢失。备份时占用内存因为Redis 在备份时会独立创建一个子进程将数据写入到一个临时文件需要的内存是原本的两倍RDB文件保存的二进制文件存在新老版本不兼容的问题。 AOF持久化 默认AOF没有开启可在redis.conf中配置 Redis7发生了重大变化原来只有一个appendonly.aof文件现在具有了三类多个文件 基本文件RDB格式或AOF格式。存放RDB转为AOF当时内存的快照数据。该文件可以有多个。增量文件以操作日志形式记录转为AOF后的写入操作。该文件可以有多个。清单文件维护AOF文件的创建顺序保证激活时的应用顺序。该文件只可以有1个。 aof 文件中存储的 resp 协议数据格式如果执行命令set a helloaof文件内容如下*3代表有3条命令$5代表有5个字符 *3
$3
set
$1
a
$5
helloAOF持久化时其实是先写入缓存中之后再同步到磁盘中同步策略有三种 appendfsync always每次写入都同步到磁盘最安全但影响性能。appendfsync everysec推荐、默认配置每秒同步一次最多丢失1秒的数据。appendfsync no Redis并不直接调用文件同步而是交给操作系统来处理操作系统可以根据buffer填充情况/通道空闲时间等择机触发同步这是一种普通的文件操作方式。性能较好在物理服务器故障时数据丢失量会因OS配置有关。 优点 数据丢失风险较低后台线程处理持久化不影响客户端请求处理的线程。 缺点 文件体积由于保存的是所有命令会比RDB大上很多而且数据恢复时也需要重新执行指令在重启时恢复数据的时间往往会慢很多。 AOF的重写Rewrite机制 为了防止AOF文件太大占用大量磁盘空间降低性能Redis引入了Rewrite机制对AOF文件进行压缩 Rewrite就是对AOF文件进行重写整理。当开启Rewrite主进程redis-server创建出一个子进程bgrewriteaof由该子进程完成rewrite过程。 首先会对现有aof文件进行重写将计算结果写到一个临时文件写入完毕后再重命名为原aof文件进行覆盖。 配置AOF重写频率 # auto‐aof‐rewrite‐min‐size 64mb //aof文件至少要达到64M才会自动重写文件太小恢复速度本来就很快重写的意义不大
# auto‐aof‐rewrite‐percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写AOF的持久化流程图 混合持久化开启 默认开启即AOF持久化的基本文件时的基本文件是RDB格式的。必须先开启aof 混合持久化重写aof文件流程aof 在重写时不再将内存数据转为 resp 数据写入 aof 文件而是将之前的内存数据做 RDB 快照处理将 RDB快照AOF增量数据 存在一起写入新的 AOF 文件完成后覆盖原有的 AOF 文件。 Redis重启加载数据流程 先加载 RDB 数据到内存中再重放增量 AOF 日志加载 AOF 增量数据 优点 结合了 RDB 和 AOF既保证了重启 Redis 的性能又降低数据丢失风险 缺点 AOF 文件中添加了 RDB 格式的内容使得 AOF 文件的可读性变得很差
