Redis 持久化
RDB
rdb是redis默认的持久化方案 在指定次数的写操作时,会将内存的快照(snapshot)的数据写入到磁盘。读取时也是读快照恢复
redis.conf文件对应 SNAPSHOTTING部分
1.save <seconds> <changes> # save<指定时间间隔><指定操作次数> # save “” save 900 1 # 900秒内有一个操作 save一下 save 300 10 save 60 10000 2. 指定文件名。default为 dump.rdb dbfilename dump.rdb 3 文件存放路径 dir ./ 4.默认开启数据压缩 rdbcompression yes
5.stop-writes-on-bgsave-error yes
当redis无法写入磁盘时,直接关掉redis的写操作
如何执行
(bgsave)redis会单独fork一个子进程来进行持久化,先将一数据写入一个临时文件中,待整个持久化过程结束,再用这个临时文件替换掉上次持久化好了的文件,而父进程可以继续处理客户端请求。
(save) 这是阻塞式的存储,客户端无法连接redis,等save完成后 主进程接到子进程的信号,才开始工作。
优点:由于保存文件是内存的快照,所以这种在恢复时非常快,适用于备份和灾难恢复。
生成rdb文件的时候 主进程不会受到干扰。
由于保存的是内存快照,文件较小。
缺点:rdb没法实时持久化,因为每次bgsave都要 fork子进程 属于重量级操作,导致在上一次快照后的数据丢失。
rdb使用二进制格式保存,多个rdb版本易造成不兼容
因为使用fork 写时复制 所以在子进程复制的时候 如果 父进程在原有键上修改 会创建新的空间,若此时空间不够,会写入失败或者lru。-----(不确定)
AOF
以日志的形式来记录每个写操作(只能追加不能改写)、redis重启的话就会根据该文件构建数据。
每有一个客户端执行了一条写操作,就在aof文件后append一条。读不予理会。
配置文件:
1.appendonly no
redis默认关闭aof 开启需要把no改为yes
2.appendfilename “appendonly.aof” 指定文件名
3.appendfysnc [always|ererysec|no]
指定日志更新条件
always:同步持久化,每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好(慢,安全)
everysec:出厂默认推荐,每秒异步记录一次(默认值)
no:不同步
AOF的重写机制
前面也说到了,AOF的工作原理是将写操作追加到文件中,文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时,Redis就会对AOF文件的内容压缩。
重写的原理:Redis 会fork出一条新进程,读取内存中的数据,并重新写到一个临时文件中。并没有读取旧文件(你都那么大了,我还去读你??? o(゚Д゚)っ傻啊!)。最后替换旧的aof文件。
触发机制:当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。
配置:
auto-aof-rewrite-percentage 100 ---一倍 auto-aof-rewrite-min-size 64mb ---最小64mb
优点:数据的完整性跟一致性较高,日志文本可读,可以在日志文件上修改处理误操作。
缺点:AOF记录内容多,数据备份恢复会变慢,每次都同步写入对性能有较大影响。
当aof与rdb同时开启时,重启后默认加载aof文件。
Redis的aof 和 cli与server通信 通过 RESP协议 详见