redis 事务、持久化

redis 事务、持久化

事务

事务的概念大家想必一点也不陌生，在mysql关系数据库中，事务是一组命令的集合，这组命令作为整体来执行，要么全部执行成功，要么全部执行失败；事务具有ACID（原子，一致，隔离，持久）四大特性。具有四大隔离级别（读未提交，读已提交[脏读]，可重复读[脏读，不可重复读 mvcc机制]，串行化[脏读，不可重复读，幻读]）。

在 redis 数据库中，事务本质上依然是一组命令集合。一个事务中的所有命令都会被序列化，在事务执行过程中按照顺序执行。在事务中，redis的命令具有 一次性，顺序性，排他性。redis 将事务的命令集合作为一个整体来进行执行，整体具有原子性，要么全部执行成功，要么全部执行失败，单条命令不在保持本省的原子性。

redis事务相比较于mysql事务，最大的不同体现在redis事务没有隔离级别的概念，原因在于redis是单线程的数据库，所以不存在多线程时面临的并发问题。

multi # 开启事务
exec # 提交执行事务
discard # 放弃事务

从上面事务的运行情况来看，redis确实把上述命令集合当作一个整体来进行执行，而不再是单个命令事务性。redis的命令加入到队列中，按照队列先进先出的特性来执行。

redis 事务遇到异常情况，需要具体分为两种来进行讨论。编译时异常（代码有错，命令有错误），在这样的情况下所有的命令都不会被执行。运行时异常（1/0）， 如果事务队列中存在语法性，那么执行命令的时候，其他命令是可以正常执行的，错误命令抛出异常！

从上面的执行情况，我们错误的使用了 getset 命令。导致发生了编译型错误。事务直接没有进行执行。

从上面的执行情况，我们没有明显的命令代码上的问题，但因为ince 针对的值应为数值类型，所以产生了运行时的错误，但是事务的命令编译成功，只有错误命令执行失败，其他命令执行成功。

持久化

redis 是基于内存的数据库，如果不把内存中的数据持久化到磁盘，一旦服务进程退出，服务器中数据库状态也就会消失，我们也就丢失了这些数据。所以为了解决这些问题，redis 为我们提供了持久化数据的功能。

RDB（Resis DataBase）

RDB的本质是对内存中的数据做备份。

RDB相当于对内存数据集的备份。RDB 机制说的是在指定时间间隔内将内存中的数据集快照（Snapshot 快照）写入磁盘。它恢复时是将快照中的文件直接读入内存。、

过程：（前提 Redis在使用时会把数据加载入内存）

​ Redis会单独创建（fork）一个子进程来进行RDB持久化，子进程会将共享内存数据写入到一个临时RDB文件，待本次持久化过程结束，会用这个临时RDB文件去替换原来的旧的RDB 文件。整个过程中，父进程不会进行任何设计RDB 持久化的IO操作，只是在写数据时，采用了复制机制，这样极大确保了父进程的性能。

RDB 持久化的恢复机制只需要我们把备份文件 dump.rdb 放在redis启动目录下就行，基于这种方式，如果需要进行大数据量的恢复且对数据的完整性要求不高，这种方式就比下面的 AOF 更加高效。为什么说 RDB 对数据的完整性不能保证，原因就在于 RDB可能丢失最后一次持久化，也就时来不及快照完成，redist服务就崩溃了。

redis默认采用了RDB的备份机制。

RDB 持久化触发机制：

关于 rdb持久化的配置，都在我们配置启动的redis.conf 中。

​ 1.sava 规则满足，会自动触发RDB

​ 2.flushall命令执行，自动触发RDB 规则

​ 3.当退出 Redis 服务，会产生RDB 文件

RDB 持久化恢复

只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb 恢复其中的数据！

RDB优缺点

优点：

1、适合大规模数据恢复，效率更高。

2、对数据的完整性要求不高。

缺点：

1、需要一定的时间间隔进程操作！如果redis意外宕机了，这个最后一次修改数据就没有的了。

2、fork进程的时候，会占用一定的内存空间。

AOF(Append Only File)

AOF 是以日志的形式来记录每个写操作，将redis执行过的所有指令记录下来（读操作不记录），只许以追加的方式，不可以改写文件，redis启动之初会读取该文件重新构建redis数据库，换言之，redis重启的话就根据日志的内容将写指令从前到后执行一次以完成数据的恢复工作。总的来说AOF持久化本质上就是以追加的方式记录下来redis写操作的历史命令，通过重新执行历史命令来恢复到数据库原来的状态。也就是通过记录历史命令实现持久化机制。

AOF的使用

AOF默认是不开启的，我们需要手动进行配置！我们只需要将 appendonly 改为yes就开启了 aof！重启，redis 就可以生效了！

如果这个 aof 文件有错位，这时候 redis 是启动不起来的吗，我们需要修复这个aof文件,redis 给我们提供了一个工具 redis- check-aof --fix 。

查看产生的 AOF文件（AOF 持久化文件同RDB 持久化文件一样保存redis.conf中的配置目录）

AOF文件内容（记录了写的命令）

AOF 持久化文件 出错修复

AOF 重写规则说明

aof 默认就是文件的无限追加，文件会越来越大

如果 aof 文件大于 64m，太大了！ fork一个新的进程来将我们的文件进行重写！

优缺点

AOF 配置

优点：

1、每一次修改都同步，文件的完整性会更加好 。

2、每秒同步一次，可能会丢失一秒的数据。

3、从不同步，效率最高的。

缺点：

1、相对于数据文件来说，aof远远大于 rdb，修复的速度也比 rdb慢。从头到尾执行一次历史命令

2、Aof 运行效率也要比 rdb 慢，所以我们redis默认的配置就是rdb持久化。