redis事务和持久化

一、事务

1.事务定义

● redis事务是一个单独的隔离操作，事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

● redis事务的主要作用就是串联多个命令防止别的命令插队。

2.Multi、Exec、Discard

● 从输入multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入exec后，redis会将之前的命令队列中的命令依次执行。

● 组队的过程中可以通过discard来放弃组队

● 事务的错误处理：

○ 组队中某个命令出现了错误报告，执行时整个的所有队列都会被取消

○ 如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行， 而其他的命令都会执行，不会回滚

3.乐观锁和悲观锁

redis用乐观锁进行实现

4. WATCH key [key...]

在执行multi之前，先执行watch，可以监视一个或多个key，如果在事务执行之前这些key被其他命令所改动，那么事务将被打断

二、Redis持久化之RDB(Redis DataBase)

1.RDB是什么？

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

2.备份是如何执行的？

Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式

要比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能丢失。

3.Fork

● Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致，但是是一个全新的进程，并作为原

进程的子进程。

● 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了"写时复制技术"

● 一般情况下父进程和子进程会共用一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程

4.RDB持久化流程

5.dump.rdb文件

在redis.conf中配置文件名称，默认为dump.rdb

6.如何触发RDB快照：保持策略

1）命令save VS bgsave

save：save时只管保存，其它不管，全部阻塞。手动保存。不建议

bgsave：redis会在后台异步进行快照操作，快照同时还可以响应客户端请求

2）flushall

执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义。

3）stop-writes-on-bgsave-error

当redis无法写入磁盘的话，直接关掉redis的写操作，推荐yes

4）rdbchecksum检查完整性

在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗

7.rdb的备份

● 先通过config get dir 查询rdb文件的目录

● 将*.rdb的文件拷贝到别的地方

● rdb的恢复

○ 关闭redis

○ 先把备份文件拷贝到工作目录下

○ 启动redis，备份数据会直接加载

8.优势

● 适合大规模的数据恢复

● 对数据完整性和一致性要求不高更适合使用

● 节省磁盘空间

● 恢复速度快

9.劣势

● Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

● 虽然redis在fork时使用了写时拷贝技术，但是数据庞大时还是比较消耗性能

● 在备份周期在一定间隔时间做一次备份，所有如果redis意外down掉的话，就会丢失最后一次快照后的所有修改

三、Redis持久化之AOF(Append Only File)

1.AOF是什么？

以日志的形式来记录每个写操作(增量保存)，将redis执行过的所以写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会

读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2.AOF持久化流程

1）客户端的请求写命令会被append追加到AOF缓冲区内；

2）AOF缓冲区根据AOF持久化策略[always，everysec，no]将操作sync同步到磁盘的AOF文件中；

3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量

4）redis服务重启时，会重新load加载AOF文件中的写操作达到恢复数据的目的

3.AOF默认不开启

● 可以在redis.conf中配置文件名称，默认为Aappendonly.aof

● AOF文件的保存路径，同RDB的路径一致

4.AOF和RDB同时开启，redis听谁的？

AOF和RDB同时开启，系统默认取AOF的数据(数据不会存在丢失)

5.AOF启动/修复/恢复

● AOF的备份机制和性能虽然和RDB不同，但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要时再拷贝到redis工作目录下，启动系统即加载。

● 正常恢复

○ 修改默认的appendonly no，改为yes

○ 将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)

○ 恢复：重启redis然后重新加载

● 异常恢复

○ 修改默认的appendonly no，改为yes

○ 如遇到AOF文件损坏，通过redis-check-aof --fix appendonly.aof进行恢复

○ 备份被写坏的AOF文件

○ 恢复：重启redis，然后重新加载

6.AOF同步频率设置

● appendfsync always

始终同步，每次redis的写入都会立刻计入日志；性能较差但数据完整性比较好

● appendfsync everysec

每秒同步，每秒计入日志一次，如果宕机，本秒的数据可能丢失

● appendfsync no

redis不主动进行同步，把同步时机交给操作系统

7.Rewrite压缩

8.优势

● 备份机制更稳健，丢失数据概率更低

● 可读的日志文本，通过操作AOF稳健，可以处理误操作

9.劣势

● 比起RDB占用更多的磁盘空间

● 恢复备份速度要慢

● 每次读写都同步的话，有一定的性能压力

● 存在个别big，造成恢复不能

10.用哪种持久化方式好？

● 官方推荐两个都启用

● 如果对数据不敏感，可以选单独RDB

● 不建议单独用AOF，因为可能会出现bug

● 如果只是做纯内存缓存，可以都不用