redis的 持久化和 事务

redis的 持久化和 事务

• 6、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. 建议 开启两种
• 6、事务
• 1. 是什么
• 2. 能干什么
• 3. 具体操做
• 1. 正常执行
• 2. 放弃事务
• 3.全体连坐
• 4. 各作各的
• 5. watch监控
• 4. 阶段
• 5. 特性

6、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，留着做为一个万一的手段。

具体的性能 、安全 、效率 根据实际状况，来本身调整

6、事务

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. 不保证原子性 ： 同一个事务 中的，命令各自运行，没有回滚