redis从入门到入坑之4_两种持久化方式以及redis事务

1：Redis持久化方式之rdb，如图

        rdb：RedisDataBase，是redis持久化的一种方式，是在指定时间内将内存中的数据持久化到磁盘中（默认是自己的安装位置），持久化是会单独创建一个进程来进行持久化的操作（redis主进程不进行任何域持久化相关的io操作）。

       fork：复制一个和当前进程一样的进程，并作为原进程的子进程

      rdb名称以及，保存路径以及 定时执行：这里的定时执行就是配置文件中的save选项。

       

       这种持久化方式速度非常快，但是精度不高，在最后一次持久化后的数据可能会丢失（执行持久化后服务宕机.........）

       rdb文件的名称也是在配置文件中配置的。

      

      注：bgsave 执行后台备份 ，shutdown时会立即备份，save命令也会立即备份

     而保存路径则是（也可以自定义保存路径，如下图）

    

     flushall，和flushdb，这两个清除所有库中的key和当前库中的key的命令，也是会备份数据的，由于命令执行的时候库中的数据已经不存在了，所以这两个命令是备份的是空的rdb文件。如下图。

1 ：没有执行flushall命令，此时文件夹中没有相对于的rdb文件

      

2：执行后如下

所以flushall和flushdb都会执行备份，但是备份的只是空的文件而已。

2：Redis持久化方式之aof，如图

   aof默认是关闭的，在配置文件中需要进行打开，如图

     

         aof：是一个文件模块，aof只记录add操作和set操作，他是以日志文件的形式记录用户每一次对redis的操作，将这个文件从前往后执行一次，数据就会被万千恢复出来。

         aof的记录方式和sql脚本非常的相似，很容易读懂，但是也很容易被损坏（比如人为的修改了aof中的内容，导致redis加载aof文件时加载到被修改的地方会出现问题，）此时只需要使用redis-check-aof 来修复即可。

         rdb和aof的区别  ：首先，这两种持久化的方式是可以共存的，在有aof文件的情况下首先加载aof文件

         aof文件追加的方式会导致该文件变得非常的大，在超过一定量的时候会启用aof压缩

        

        aof的恢复速度慢于rdb，效率也慢于rdb。

 

    3：redis的事务：   是可以一次执行多个命令，本质是一组命令的集合，在一个事务中的命令会序列化依次执行

    作用：命令的批处理，一次性的，排他性的执行多个redis命令

   常用命令

1：正常的案列

执行后在1号库中已经有了3个key，而这3个key就是刚才事务执行时添加进去的。

2：放弃事务（如图）

放弃事务后显然test这个key并没有在test中

3:队列中命令执行的强一致性（命令队列中一个失败，全都失败，如图）

 

4：与3相反的是，如果在执行过程中，命令正确，但是命令执行的结果出现了错误，除了该错误命令不执行，其他的都执行（如图）

在这个事务中，我对一个字符串进行了+1操作，很显然是不行的，在最后的结果是 +1 操作失败，其他的都成功了。