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/binRDB的优点和缺点：
优点：
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
命令时，
其他正确 命令会被执行，错误命令抛出异常
。
809
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
