redis的 持久化和 事务

redis的 持久化和 事务

• 六、redis的持久化
• 1. RDB
• 1. 是什么
• 2. fork
• 3.rdb 保存的是dump.rdb文件
• 4. 如何触发RDB快照
• 5.如何恢复
• 5. 优势
• 6.劣势
• 7. 如何停止
• 2. AOF
• 1. 是什么
• 2. 保存文件
• 3.配置地方在 配置文件中可以找到
• 4. AOF启动/修复/恢复
• 1. 正常恢复
• 2. 异常恢复
• 3. rewrite
• 4. 优势
• 5. 劣势
• 3. select who
• 1. 建议 开启两种
• 六、事务
• 1. 是什么
• 2. 能干什么
• 3. 具体操作
• 1. 正常执行
• 2. 放弃事务
• 3.全体连坐
• 4. 各做各的
• 5. watch监控
• 4. 阶段
• 5. 特性

六、redis的持久化

1. RDB

1. 是什么

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

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到
一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方
式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

2. fork

就是 复制一个与当前进程一样的进程。新进程的所有数据都和原进程一样，但是是一个全新的进程，并作为原进程的子进程

3.rdb 保存的是dump.rdb文件

4. 如何触发RDB快照

1. 配置文件中默认的快照配置

   1. 冷拷贝后 ，
   2. cp dump.rdb dump1.rdb

2. 命令save或者是bgsave

   1. save ： 只管保存，其他不管，全部阻塞
   2. Bgsave ： redis在后台异步进行快照操作，同时快照相应客户端请求 ，通过lastsave 获取最后一个成功执行快照的时间

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

5.如何恢复

1. 将上述备份文件移动到redis安装目录并启动服务
   2. config get dir 获取目录

5. 优势

1. 适合大规模的数据恢复
2. 对数据完整性和一致性要求不高

6.劣势

1. 在一定间隔时间做一次备份，如果出现意外，会丢失最后一次备份修改
2. fork 会导致内存 2倍膨胀性

7. 如何停止

1. 动态所有停止rdb保存规则的办法
   1. redis-cli config set save “”

2. AOF

1. 是什么

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，

只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis

重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

2. 保存文件

1. appendonly.aof 文件

3.配置地方在 配置文件中可以找到

4. AOF启动/修复/恢复

1. 正常恢复

1. 启动
   1. 设置yes
2. 将数据的aof文件复制一份到对应目录
3. 恢复 ： 重启redis 重新加载

2. 异常恢复

1. 启动
   1. 设置yes
2. 备份被写坏的aof文件
3. 修复
   1. redis-check-aof --fix进行修复
4. 重启进行加载

3. rewrite

1. 是什么

   AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,

   当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，

   只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

2. 重写原理

   AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，

   遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，

   而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

3. 触发机制

   Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

4. 优势

1. 每修改同步 ： appendfsync
   1. always ： 同步持久化，每次发生数据变更，都会记录，性能较差，但是完整性较好
   2. everysec ： 异步操作，每秒记录
   3. no ： 从不同步

5. 劣势

1. 相同的数据集 aof比rdb打，恢复速度也较慢
2. aof 运行效率慢于rdb ，每秒同步策略效率较好，不同步效率相同

3. select who

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些

命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.

Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大

只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

1. 建议 开启两种

在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,

因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？

作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，

快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

具体的性能 、安全 、效率 根据实际情况，来自己调整

六、事务

1. 是什么

可以一次执行多个命令，本质是一组命令的集合。一个事务中的

所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞

2. 能干什么

一个队列中，一次性、顺序性、排他性的执行一系列命令

3. 具体操作

1. 正常执行

MULTI

set id l2

get id

incr tl

incr tl

get tl

EXEC

2. 放弃事务

MULTI

set name z3

set age 28

incr tl

discard

3.全体连坐

MULTI 

set name z3

get name

incr tl

get tl

set email

EXEC

一个事务都不执行

4. 各做各的

MULTI 

set age 11

incr tl

set email abc@11.com

incr email

EXEC

只运行能执行的事务

5. watch监控

1. 原理

   1. 悲观锁/乐观锁/CAS(Check And Set)

       悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁
       
        乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，
      乐观锁策略:提交版本必须大于记录当前版本才能执行更新
       
       
       CAS
      

   2. 例如 信用卡可用余额和欠额

      • 如果要改动金额
      • 首先 监控 可用余额 watch
      • 然后 开启 事务
      • 如果 自己的事务不能执行
      • 则是 版本不一致，有人修改，要unwatch ，解锁
      • 如果 自己事务exec 执行了，监控锁会取消掉

   3. watch 类似 乐观锁，

   4. watch 可以监控 多个keys，

   5. 在exec 执行失败 ，同时返回Nullmulti-bulk应答以通知调用者事务执行失败

4. 阶段

1. 开启 ； multi 开始一个事务
2. 入队 ： 将多个命令入队到书屋中
   3. 执行 ； exec 触发事务

5. 特性

1. 单独的隔离操作 ： 事务中，所有命令都会序列化，不会被其他命令请求打断
2. 没有隔离级别的概念 ： 队列中的命令没有提交之前，不会实际执行
3. 不保证原子性 ： 同一个事务 中的，命令各自运行，没有回滚