Redis事务_持久化

事务

Redis的事务定义

Redis事务是一个单独的隔离操作∶事务中的所有命令都会序列化、按顺序地执行事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

Redis事务的主要作用就是串联多个命令防止别的命令插队。

Multi.Exec.discard

从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis 会将之前的命令队列中的命令依次执行。

组队的过程中可以通过discard来放弃组队。

#案例
127.0.0.1:6379> multi #开启事务
OK
127.0.0.1:6379(TX)> set key1 value1
QUEUED                                #把命令放入queued的队列中还没有执行
127.0.0.1:6379(TX)> set key2 value2
QUEUED
127.0.0.1:6379(TX)> exec  #命令真正执行了
1) OK
2) OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set a1 v1
QUEUED
127.0.0.1:6379(TX)> set a2 v2
QUEUED
127.0.0.1:6379(TX)> discard  #放弃组队,不执行了
OK

事务的错误处理

组队只能某个命令出现了报告错误,执行时整个的所有队列都会被取消

 如果执行阶段某个命令报出了错误,则只有报错的命令不执行,而其他的命令都会执行,不会回滚

#实例
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set b1 v1
QUEUED
127.0.0.1:6379(TX)> set b2 v2
QUEUED
127.0.0.1:6379(TX)> set b3
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379(TX)> exec     #组队阶段,有一个命令错误所有都错误
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set c1 v1
QUEUED
127.0.0.1:6379(TX)> incr c1
QUEUED
127.0.0.1:6379(TX)> set c2 v2
QUEUED
127.0.0.1:6379(TX)> exec  #执行阶段,除了错误的命令都会执行
1) OK
2) (error) ERR value is not an integer or out of range
3) OK

为什么要做成事务?

想一个场景:很多人有你的账户,同时去参加双十一抢购

事务冲突的问题

悲观锁

 悲观锁(Pessimistic Lock)，顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

乐观锁 

 乐观锁(Optimistic Lock)，顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

 WATCH key [key...... ]

在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key被其他命令所改动，那么事务将被打断。

unwatch

取消WATCH 命令对所有key的监视。

如果在执行 WATCH 命令之后，EXEC命令或DISCARD命令先被执行了的话，那么就不需要再执行UNWATCH了。

#演示
#客户端1
127.0.0.1:6379> set balance 100
OK
127.0.0.1:6379> keys *
1) "a2"
2) "key2"
3) "balance"
127.0.0.1:6379> watch balance  #监视balance
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> incrby balance 10
QUEUED
127.0.0.1:6379(TX)> exec
1) (integer) 110

#客户端2
[root@localhost ~]#  /usr/local/bin/redis-cli
127.0.0.1:6379> watch balance
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> incrby balance 20
QUEUED
127.0.0.1:6379(TX)> exec   #因为balance被修改了所有无法成功,事务被打断
(nil)

Redis事务的三大特征

单独的隔离操作
事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

没有隔离级别的概念
队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行

不保证原子性
事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

---

Redis持久化

Redis提供了两个不同形式的持久化方法

RDB(Redis DataBase)

RDB介绍:

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

备份是如何执行的

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

Fork

Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux 中引入了“写时复制技术"

一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

RDB持久化流程

dump.rdb文件

在redis.conf中配置文件名称,默认为dump.rdb

优势:

适合大规模的数据恢复

对数据完整性和一致性要求不高更适合使用节省磁盘空间

恢复速度快

劣势:

 Fork 的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

虽然Redis.,在 fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

在备份周期在一定间隔时间做一次备份，所以如果Redis.意外down掉的话，就会丢失最后一次快照后的所有修改。

 如何停止

动态停止RDB :redis-cli config set Save "" #save后给空值,表示禁用保存策略

AOF(Append Of File)

是什么

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

AOF持久化流程

(1)客户端的请求写命令会被append追加到AOF缓冲区内;

(2)AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中

(3) AOF文件大小超过重写策略或手动重写时，会对 AOF文件rewrite重写，压缩AOF文件容量;

(4)Redis服务重启时，会重新load加载 AOF 文件中的写操作达到数据恢复的目的;

AOF默认不开启

可以在redis.conf 中配置文件名称，默认为appendonly.aof
AOF文件的保存路径，同RDB的路径一致。

AOF和 RDB同时开启，redis听谁的?

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失)

AOF启动/修复/恢复

AOF的备份机制和性能虽然和RDB不同,但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。·
      正常恢复
         修改默认的appendonly no，改为yese

         将有数据的aof文件复制一份保存到对应目录(查看目录: config get dir)

        恢复:重启redis然后重新加载·

   异常恢复
      修改默认的appendonly no，改为yes

      如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix

      备份被破坏的AOF文件

      恢复:重启redis,然后重新加载

AOF同步频率设置

appendfsync always.
始终同步，每次Redis的写入都会立刻记入日志;性能较差但数据完整性比较好

appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no
redis不主动进行同步，把同步时机交给操作系统。

Rewrite压缩

1是什么∶
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis 就会后启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof.

2重写原理，如何实现重写
AOF文件持续增长而过大时，会fork出—条新进程来将文件重写(也是先写临时文件最后再rename) , redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

no-appebdfsync-on-rewrite

如果no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能),

如果no-appendfsync-on-rewrite=no，还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阳塞。（数据安全，但是性能降低).
触发机制，何时重写

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

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-percentage:设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发)

auto-aof-rewrite-min-size :设置重写的基准值，最小文件64MB。达到这个值开始重写。v

例如︰文件达到70MB开始重写，降到50MB，下次什么时候开始重写?100MB.
系统载入时或者上次重写完毕时，Redis 会记录此时AOF大小，设为base_size,
如果Redis的 AOF当前大小>= base_size +base_size*100%(默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

3.重写流程

(1) bgrewriteaof触发重写，判断是否当前有bgsave或 bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
(2主进程fork出子进程执行重写操作，保证主进程不会阻塞。
(3)子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf 缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
(4)(1)子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。(2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
(5)使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

优势:

 劣势:

 小总结:

 总结(Which one)

用那个好?

官方推荐两个都启用.

如果对数据不敏感，可以选单独用RDB。

不建议单独用AOF，因为可能会出现Bug。

如果只是做纯内存缓存，可以都不用。

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

AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.

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

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

同时开启两种持久化方式

在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下 AOF文件保存的数据集要比RDB文件保存的数据集要完整.

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?,
建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

 性能建议
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。