Redis事务和持久化

1.事务

1.1 概念

Redis事务的概念：
Redis事务提供了一种“将多个命令打包， 然后一次性、按顺序地执行”的机制， 并且事务在执行的期间不会主动中断 —— 服务器在执行完事务中的所有命令之后， 才会继续处理其他客户端的命令。
Redis单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

1.2 阶段

Redis事务的三个阶段：
开始事务
命令入队
执行事务

1.3 相关命令

Redis事务相关命令：
　　watch key1 key2 … : 监视一或多个key,如果在事务执行之前，被监视的key被其他命令改动，则事务被打断 （ 类似乐观锁 ）
　　multi : 标记一个事务块的开始（ queued ）
　　exec : 执行所有事务块的命令 （ 一旦执行exec后，之前加的监控锁都会被取消掉 ）　
　　discard : 取消事务，放弃事务块中的所有命令
　　unwatch : 取消watch对所有key的监控
所以事务中的命令在加入时都没有被执行，直到提交时才会开始执行(Exec)一次性完成。

127.0.0.1:6379> multi # 开启事务
127.0.0.1:6379> set k1 v1 # 命令入队
127.0.0.1:6379> set k2 v2 # …
127.0.0.1:6379> get k1
127.0.0.1:6379> set k3 v3
127.0.0.1:6379> keys *
127.0.0.1:6379> exec # 事务执行

取消事务(discurd)

127.0.0.1:6379> multi
127.0.0.1:6379> set k1 v1
127.0.0.1:6379> set k2 v2
127.0.0.1:6379> set k4 v4
127.0.0.1:6379> discard # 放弃事务
127.0.0.1:6379> exec
(error) ERR EXEC without MULTI # 当前未开启事务
127.0.0.1:6379> get k4 # 被放弃事务中命令并未执行
(nil)

1.4 错误

事务错误:
编译型异常（代码有问题！ 命令有错！） ，事务中所有的命令都不会被执行！
运行时异常（1/0）， 如果事务队列中存在语法性，那么执行命令的时候，其他命令是可以正常执行的，错误命令抛出异常！

事务错误:代码语法错误（编译时异常）所有的命令都不执行

127.0.0.1:6379> multi
127.0.0.1:6379> set k1 v1
127.0.0.1:6379> set k2 v2
127.0.0.1:6379> error k1 # 这是一条语法错误命令
(error) ERR unknown command error, with args beginning with: k1, # 会报错但是不影响后续命令入队
127.0.0.1:6379> get k2
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors. # 执行报错
127.0.0.1:6379> get k1
(nil) # 其他命令并没有被执行

运行时异常（1/0）执行命令的时候，其他命令是可以正常执行的，错误命令抛出异常！

127.0.0.1:6379> set k1 “v1”
127.0.0.1:6379> multi
127.0.0.1:6379> incr k1 # 会执行的时候失败！
127.0.0.1:6379> set k2 v2
127.0.0.1:6379> set k3 v3
127.0.0.1:6379> get k3
127.0.0.1:6379> exec

1. (error) ERR value is not an integer or out of range # 虽然第一条命令报错了，但是 依旧正常执行成功了！ 2) OK 3) OK 4) “v3”
   127.0.0.1:6379> get k2
   127.0.0.1:6379> get k3

1.5 锁

悲观锁：
很悲观，认为什么时候都会出现问题，无论做什么都会加锁
乐观锁：
很乐观，认为什么时候都不会出现问题，所以不会上锁！更新数据的时候去判断一下，在此期间是否有人修改过这个数据

使用watch key监控指定数据，相当于乐观锁加锁。

192.168.136.102:6379> set money 100 # 设置余额:100
192.168.136.102:6379> set use 0 # 支出使用:0
192.168.136.102:6379> watch money # 监视money (上锁)
192.168.136.102:6379> multi
192.168.136.102:6379> DECRBY money 20
192.168.136.102:6379> INCRBY use 20
192.168.136.102:6379> exec # 监视值没有被中途修去改，事务正常执行

1. (integer) 80
2. (integer) 20

测试多线程修改值，使用watch可以当做redis的乐观锁操作

2.持久化

Redis（Remote Dictionary Server）是一个可持久化的内存、Key-Value数据库。
作为内存数据库，为了防止因服务器断电或系统宕机而引起的数据丢失问题，Redis自带了持久化功能，就是将内存中的数据同步到磁盘来保证持久化（防止数据丢失）。
Redis支持两种持久化方式：

• RDB（redis database）
• AOF（append only file）

2.1 RDB

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

1、Redis调用forks. 同时拥有父进程和子进程。
2、子进程将数据集写入到一个临时RDB 文件中。
3、当子进程完成对新RDB文件的写入时，Redis用新RDB文件替换原来的RDB文件，并删除旧的RDB文件。

在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。
触发机制
1、save的规则满足的情况下，会自动触发rdb规则
2、执行 flushall 命令，也会触发我们的rdb规则！
3、退出redis，也会产生 rdb 文件！
备份就自动生成一个 dump.rdb
如果恢复rdb文件！
1、只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb 恢复其中的数据！
2、查看需要存在的位置

RDB的优点
RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.
RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心，非常适用于灾难恢复.
RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.
RDB的缺点
如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据。
RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒。

2.2 AOF

AOF（Append Only File）
将我们的所有命令都记录下来，恢复的时候就把这个文件全部再执行一遍！

配置AOF（redis.conf）
appendonly no # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分的情况下， rdb完全够用！

每当 Redis 执行一个改变数据集的命令时（比如 SET）， 这个命令就会被追加到 AOF 文件的末尾。这样的话， 当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。
appendfilename “appendonly.aof” # 持久化的文件的名字
#appendfsync always # 每次修改都会 sync。消耗性能
#appendfsync everysec # 每秒执行一次 sync，可能会丢失这1s的数据！ # appendfsync no # 不执行 sync，这个时候操作系统自己同步数据，速度最快！

AOF 优点
使用AOF 会让你的Redis更加耐久,一旦出现故障，你最多丢失1秒的数据.
AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用工具修复这些问题.
Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写。
AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
AOF 缺点
对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

如何选择使用哪种持久化方式？
如果想达到足够多的数据安全性， 你应该同时使用两种持久化功能。
如果可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。
使用RDB和AOF结合一起做持久化，RDB做冷备，可以在不同时期对不同版本做恢复，AOF做热备，保证数据仅仅只有1秒的损失。当AOF破损不可用了，那么再用RDB恢复，这样就做到了两者的相互结合，也就是说Redis恢复会先加载AOF，如果AOF有问题会再加载RDB，这样就达到冷热备份的目的了。