redis的所有数据保存在内存中, 对数据的更新将异步的保存到硬盘中
快照: 某时某刻数据的一个完成备份
mysql的Dump
redis的RDB
写日志: 任何操作记录到日志, 要恢复数据, 只要把日志重新走一片即可
mysql的Binlog
redis的AOF
1.触发机制的主要三种方式
‘‘‘ save(同步) 1 客户端执行save命令----》redis服务端----》同步创建RDB二进制文件 2 会造成redis的阻塞(数据量非常大的时候) 3 文件策略:如果老的RDB存在,会替换老的 4 复杂度 o(n) ‘‘‘ ‘‘‘ bgsave(异步,Backgroud saving started) 1 客户端执行save命令----》redis服务端----》异步创建RDB二进制文件(fork函数生成一个子进程(fork会阻塞reids),执行createRDB,执行成功,返回给reids消息) 2 此时访问redis,会正常响应客户端 3 文件策略:跟save相同,如果老的RDB存在,会替换老的 4 复杂度 o(n) ‘‘‘ ‘‘‘ 自动(通过配置) 配置 seconds changes save 900 1 save 300 10 save 60 10000 如果60s中改变了1w条数据,自动生成rdb 如果300s中改变了10条数据,自动生成rdb 如果900s中改变了1条数据,自动生成rdb 以上三条符合任意一条,就自动生成rdb,内部使用bgsave ‘‘‘ #配置: save 900 1 #配置一条 save 300 10 #配置一条 save 60 10000 #配置一条 dbfilename dump.rdb #rdb文件的名字,默认为dump.rdb dir ./ #rdb文件存在当前目录 stop-writes-on-bgsave-error yes #如果bgsave出现错误,是否停止写入,默认为yes rdbcompression yes #采用压缩格式 rdbchecksum yes #是否对rdb文件进行校验和检验 #最佳配置 save 900 1 save 300 10 save 60 10000 dbfilename dump-${port}.rdb #以端口号作为文件名,可能一台机器上很多reids,不会乱 dir /bigdiskpath #保存路径放到一个大硬盘位置目录 stop-writes-on-bgsave-error yes #出现错误停止 rdbcompression yes #压缩 rdbchecksum yes #校验
1 全量复制 #没有执行save和bgsave没有添加rdb策略,还会生成rdb文件,如果开启主从复制,主会自动生成rdb 2 debug reload #debug级别的重启,不会将内存中的数据清空 3 shutdown save#关闭会出发rdb的生成
耗时, 耗性能
不可控, 可能会丢失数据
客户端每写入一条命令, 都会记录一条日志, 放到日志文件中, 如果出现宕机, 可以将数据恢复
日志不是直接写到硬盘上, 而是先放到缓冲区, 缓冲区根据一些策略, 写到硬盘上
always: redis>>写命令刷新缓冲区>>每条命令fsync到硬盘>>AOF文件
everysec(默认值): redis>>写命令刷新缓冲区>>每秒把缓冲区fsync到硬盘>>AOF文件
no: redis>>写命令刷新缓冲区>>操作系统决定, 缓冲区fsync到硬盘>>AOF文件
命令 | always | everysec | no |
---|---|---|---|
优点 | 不丢失数据 | 每秒一次fsync,丢失1秒数据 | 不用管 |
缺点 | IO开销大,一般的sata盘只有几百TPS | 丢1秒数据 | 不可控 |
随着命令的逐步写入,并发量的变大, AOF文件会越来越大,通过AOF重写来解决该问题
本质就是把过期的, 无用的, 重复的, 可以优化的命令, 来优化, 这样可以减少磁盘占用量, 加速恢复速度
原生AOF | AOF重写 |
---|---|
set hello world set hello java set hello hehe incr counter incr counter rpush mylist a rpush mylist b rpush mylist c 过期数据 |
set hello hehe set counter 2 rpush mylist a b c |
bgrewriteaof: 客户端向服务端发送bgrewriteaof命令, 服务端会起一个fork进程, 完成AOF重新
appendonly yes #将该选项设置为yes,打开 appendfilename "appendonly-${port}.aof" #文件保存的名字 appendfsync everysec #采用第二种策略 dir /bigdiskpath #存放的路径 no-appendfsync-on-rewrite yes #在aof重写的时候,是否要做aof的append操作,因为aof重写消耗性能,磁盘消耗,正常aof写磁盘有一定的冲突,这段期间的数据,允许丢失
原文:https://www.cnblogs.com/zhuangshenhao/p/12120795.html