RDB(Redis DataBase)
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
Fork
Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量,环境变量,程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程。
RDB保存的文件是dump.rdb
如何触发快照
1、配置文件中默认的快照配置,建议多用一台机子作为备份,复制一份dump.rdb
2、命令save或者是bgsave
save时只管保存,其他不管,全部阻塞
bgsave,Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。可以通过 lastsave命令获取最后一次成功执行快照的时间。
3、执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义!
4、退出的时候也会产生dump.rdb文件!
如何恢复数据
1.将备份文件(
dump.rdb
)移动到
redis
安装目录并启动服务即可
2
、
CONFIG GET dir
获取目录
127.0.0.1:6379> config get dir
dir
/usr/local/bin
RDB的优点和缺点:
优点:
1 、适合大规模的数据恢复2 、对数据完整性和一致性要求不高
缺点:
1 、在一定间隔时间做一次备份,所以如果 redis 意外 down 掉的话,就会丢失最后一次快照后的所有修改2 、 Fork 的时候,内存中的数据被克隆了一份,大致 2 倍的膨胀性需要考虑。
AOF(Append Only File)
以日志的形式来记录每个写操作,将
Redis
执行过的所有指令记录下来(读操作不记录),
只许追加文件,但不可以改写文件
,redis
启动之初会读取该文件重新构建数据,换言之,
redis
重启的话就根据日志文件 的内容将
写指令
从前到后执行一次以完成数据的恢复工作。
Aof
保存的是
appendonly.aof
文件
优点:
1
、每修改同步:
appendfsync always
同步持久化,每次发生数据变更会被立即记录到磁盘,性能较差
但数据完整性比较好
2
、每秒同步:
appendfsync everysec
异步操作,每秒记录 ,如果一秒内宕机,有数据丢失
3
、不同步:
appendfsync no
从不同步
缺点:
1
、相同数据集的数据而言,
aof
文件要远大于
rdb
文件,恢复速度慢于
rdb
。
2
、
Aof
运行效率要慢于
rdb
,每秒同步策略效率较好,不同步效率和
rdb
相同
Redis事务
Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令,一个事务中所有命令都会被序列化。在事务执行过程,会按照顺序串行化执行队列中的命令,其他客户端提交的命令请求不会插入到事务执行命令序列中。总结说: redis 事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。
Redis
事务没有隔离级别的概念:
批量操作在发送 EXEC
命令前被放入队列缓存,并不会被实际执行!
Redis
不保证原子性:
Redis中,单条命令是原子性执行的,但事务不保证原子性,且没有回滚。事务中任意命令执行失败,其余的命令仍会被执行。
Redis
事务的三个阶段:
1. 开始事务2.命令入队3.执行事务
Redis
事务相关命令:
watch key1 key2 ... # 监视一或多个 key, 如果在事务执行之前,被监视的 key 被其他命令改动,则事务被打断 (类似乐观锁 )multi # 标记一个事务块的开始(queued )exec # 执行所有事务块的命令 (一旦执行 exec 后,之前加的监控锁都会被取消掉 )discard # 取消事务,放弃事务块中的所有命令unwatch # 取消 watch 对所有 key 的监控
若在事务队列中存在命令性错误(类似于
java
编译性错误),则执行
EXEC
命令时,
所有命令都不会 执行;
若在事务队列中存在语法性错误(类似于
java
的
1/0
的运行时异常),则执行
EXEC
命令时,
其他正确 命令会被执行,错误命令抛出异常
。