用AI赚第一桶💰低成本搭建一套AI赚钱工具,源码可二开。 广告
## 一、持久化的作用 * 什么是持久化 * redis所有数据保存在内存中,对数据的更新将异步地保存到磁盘上。 * 持久化方式 * 快照 - 某事某点数据的完整备份 * MySQL Dump * Redis RDB * 写日志 - 只要有操作就记录到日志中 * MySQL Binlog * Hbase HLog * Redis AOF ## 二、RDB * 什么是RDB * 通过一条命令将redis内存中的数据完整生成一个快照保存到硬盘当中,也就是RDB文件(二进制),进行持久化。 * 对redis进行重启,可以加载 RDB文件,进行恢复。 * 触发机制-主要三种方式 * save 同步 * 向redis发送一个save命令,创建RDB文件,会造成redis阻塞。 * 文件策略:如存在老的RDB文件,新替换老。 * 负责度:O(N) * bgsave 异步 * 在redis主进程生产fork() 子进程,创建RDB文件 * 如果fork 慢,会阻塞主进程。非常快的情况不会阻塞主进程。 * 自动 * 默认配置 | 配置 | seconds | changes | | --- | --- | --- | | save | 900 | 1 | | save | 300 | 10 | | save | 60 | 10000 | 当900秒内有1条修改则执行save,当300秒内有10条修改则执行save,当60秒内有10000条修改则执行save | 配置 | 参数 | 说明 | | --- | --- | --- | | dbfilename | dump.rdb | 生产的文件名 | | dir | ./ | 保存的文件路径 | | stop-writes-on-bgsave-error | yes | 发生错误是否停止写入 | | rdbcompression | yes | 是否采用压缩格式 | | rdbchecksum | yes | 是否进行检验 | * 推荐配置 | 配置 | 参数 | | --- | --- | | dbfilename | dump-${port}.rdb | | dir | /bigdiskpath | | stop-writes-on-bgsave-error | yes | | rdbcompression | yes | | rdbchecksum | yes | * save 与 bgsave 的不同 | 命令 | save | bgsave | | --- | --- | --- | | IO类型 | 同步 | 异步 | | 阻塞? | 是 | 是(阻塞发生在fork) | | 复杂度 | O(n) | O(n) | | 优点 | 不会消耗额外内存 | 不阻塞客户端命令 | | 缺点 | 阻塞客户端命令 | 需要fork,消耗内存 | * 触发机制-不容忽视方式 * 全量复制,即主从复制 * debug reload,发生错误时需建立RDB * shutdown,重启时建立RDB * 总结 * RDB是Redis内存到硬盘的快照,用于持久化。 * save通常会阻塞Redis。 * bgsave不会阻塞Redis,但是会fork新进程。 * save自动配置满足任一条件就会被执行。 * 有些触发机制不容忽视 ## 三、AOF * RDB有什么问题 * 耗时、耗性能 * 需要把所有数据dumo到磁盘中,耗时O(n)的过程 * fork() : 消耗内存,copy-on-writh策略 * Disk I/O : IO性能消耗 * 不可控、丢失数据 | 时间戳 | save | | --- | --- | | T1 | 执行多个写命令 | | T2 | 满足RDB自动创建的条件 | | T3 | 再次执行多个写命令 | | T4 | 宕机 | 当T1时间点执行了很多写命令,在T2时间点满足RDB自动创建的条件,T3时间点又执行了很多写命令,T4时间点宕机了,T3-T4时间段的写入命令会丢失。 * AOF运行原理 * 创建 -- 以写日志的方式把每一条写命令追加到AOF文件当中 * redis在执行写命令时,会写到硬盘的缓冲区当中,缓冲区会根据一些**策略**把写命令的日志刷新到磁盘当中 * 恢复 -- 当发生宕机时,重启之后将AOF文件载入到Redis当中,进行数据恢复。 * AOF的三种策略 * always * 写每条命令都会fsync到磁盘 * everysec * 每秒把缓冲区 fsync 到磁盘,出现故障有可能会丢失一秒的数据 * no * 根据操作系统决定,操作系统说什么时候 刷,就什么时候刷。 | 命令 | always | everysec | no | | --- | --- | --- | --- | | 优点 | 不丢失数据 | 每秒一次 fsync 丢1秒数据 | 不用管 | | 缺点 | IO开销较大,一般的 sata 盘只有几百 TPS | 丢1秒数据 | 不可控 | * AOF重写 * 把过期的、没有用的、重复的以及可以优化的命令进行化简,化简为一个很小的AOF文件。 * 减少硬盘占用量 * 加速恢复速度 * AOF重写实现的两种方式 * bgrewriteaof * 由客户端发送 bgrewriteaof 命令到服务端,redis接收到命令后会 fork 出一个子进程,来完成AOF重写。 * AOF重写配置---实现自动重写 | 配置名 | 含义 | | --- | --- | | auto-aof-rewrite-min-size | AOF文件重写需要的尺寸 | | auto-aof-rewrite-percentage | AOF 文件增长率 | | 统计名 | 含义 | | --- | --- | | aof_current_size | AOF当前尺寸(单位:字节) | | aof_base_size | AOF上次启动和重写的尺寸(单位:字节) | * 自动触发时机 * 当前尺寸 > 最小尺寸 * (当前尺寸 - 最小尺寸) / 最小尺寸 > 增长率 * 配置 | 命令 | 配置 | 说明 | | --- | --- | --- | | appendonly | yes | 开打AOF功能 | | appendfilename | appendonly-${port}.aof | AOF生产的文件名 | | appendfsync | everysec | 同步的策略 | | dir | /bigdiskpath | 保存的目录 | | no-appendfsync-on-rewrite | yes | 是否在重写的时候,关闭 AOF 的 appen操作,如果不关闭有可能会导致数据丢失,这里是 yes ,重写时不做其他操作 | | auto-aof-rewrite-percentage | 100 | 增长率 | | auto-aof-rewrite-min-size | 64mb | 最小尺寸 | * RDB和AOF抉择 | 命令 | RDB | AOF | | --- | --- | --- | | 启动优先级 | 低 | 高 | | 体积 | 小 | 大 | | 恢复速度 | 快 | 慢 | | 数据安全性 | 丢数据 | 根据策略决定 | | 操作的轻重 | 重,因为它要操作全部的redis数据 | 轻,日志追加的方式 | * RDB最佳策略 * “关”- 在主从会用到 * 集中管理 - 如果需要按天按小时备份数据,是个不错的选择。 * 主从,从开? * AOF最佳策略 * “开”:缓存和存储 -- 如果只当缓存可以关掉 * AOF重写集中管理 * everysec * 最佳策略 * 小分片 - * 缓存或者存储 - 根据缓存或存储的特性决定使用那种策略 * 监控(硬盘、内存、负载、网络) * 足够的内存