Redis 6.2.6（事务、持久化）

一、事务

1、概述

• redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序的执行。事务在执行过程中，不会被其他客户端发送的命令请求所打断。
• redis事务的主要作用就是串联多个命令防止别的命令插队

Multi开始事务
Exec执行事务
discard取消事务

从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec命令后，redis会将之前的命令队列中的命令依次执行。
组队的过程中可以通过discard命令来放弃组队。
组队中某个命令报告错误，执行时整个的所有队列会都被取消。
如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

2、锁机制

• 悲观锁 就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁、表锁、读锁、写锁等都是在做操作之前先上锁。
• 乐观锁 就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候回判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁使用于多读的应用类型，这样可以提高吞吐量，redis就是利用这种check-and-set机制实现事务的。
  

3、watch机制

在执行multi之前，先执行watch ，可以监视一个或多个key,如果事务执行之前这个key被其他命令所改动，那么事务将被打断。unwatch取消watch命令对所有key的监视，如果在执行watch命令之后，exec/discard命令被被执行的话，那么就不需要再执行unwatch命令了。

4、事务特性

• 单独的隔离操作 事务中的所有命令都会被序列化、按顺序的执行，事务在执行的过程中，不会被其他的客户端发送来的命令请求所打断。
• 没有隔离级别 队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在“事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头疼的问题。
• 不保证原子性redis同一事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。

二、秒杀案例

待更新。。。

三、持久化

1、RDB

• 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是snapshot快照，它恢复时是将快照文件直接读到内存中。
• redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那么RDB方式要比AOF方式更加的高效，RDB的缺点是最后一次持久化后的数据可能丢失。
• 在linux程序中，fork()会产生一个和父进程完全相同的子进程，但是子进程多会在exec系统调用，出于效率考虑，linux中引入了“写时复制技术”，一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时才会将父进程的内容复制一份给子进程。

#配置文件
dbfilename dump.rdb  --文件名

dir ./    --路径，哪里开启redis就是那个位置 /opt/myredis

save 900 1  --保存策略，规定内数据修改一定次数就会进行备份
save 300 10
save 60 10000

stop-writes-on-bgsave-error yes --当redis无法写入磁盘的话，直接关掉redis的写操作。
rdbcompression yes --进行rbd保存时，将文件压缩
rdbchecksum yes --在存储快照后，还可以让redis使用crc64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

#指令
手动保存指令:只管保存，其他不管，全部阻塞。
save vs bgsave

db备份

将产生的rdb文件复制到其他目录下保存

rdb恢复

• 关闭redis
• 先把备份的文件拷贝到工作目录下
• 启动redis,备份数据会直接加载

rdb的优点

• 节省磁盘空间
• 恢复速度快

rdb的缺点

• 虽然redis在fork时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能。
• 在备份周期在一定间隔时间做一次备份，所以如果reids意外down掉的话，就会丢失最后一次快照后的所有修改。

rdb正常备份

• 满足备份策略
• redis正常关闭

2、AOF

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

aof 默认不开启，需要手动在配置文件中配置                            
appendonly no

appendfilename "appendonly.aof"  --备份文件名称

aof文件的保存路径，同rdb的路径一致

aof 文件故障备份

• aof的备份机制和性能虽然和rdb不同，但是备份和恢复的操作同rdb一样，都是拷贝备份文件，需要恢复时再拷贝到redis工作目录下，启动系统即加载。
• aof和rdb同时开启，系统默认取aof的数据

aof文件故障恢复

• aof文件的保存路径，同rdb的路径一致。
• 如遇到aof文件损坏，可通过redis-check-aof–fix appendonly.aof 进行恢复

aof同步频率设置

• 始终同步，每次redis的写入都会立刻写入日志。
• 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
• 不主动进行同步，把同步时机交给操作系统。
  appendfsync always
  appendsync everysec
  appendfsnc no

rewrite

• aof采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当aof文件的大小所设定的阈值时，reids就会启动aof文件的内容压缩机制，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof。

redis如何实现重写？

• aof文件持续增长而过大时，会fork出来一条新进程来将文件重写（也是先写临时文件最后再rename）,遍历新进程的内存中数据，每条记录有一条的set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

何时重写？

• 重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担，因此设定redis要满足一定条件才会进行重写。
  auto-aof-rewrite-percentage 100
  auto-aof-rewrite-min-size 64m
• 系统载入时或者上次重写完毕时，redis会记录此时aof大小，设为bese_size,如果redis的aof当前大小大于等于base_size的2倍且当前大小大于等于64m的情况下，redis会对aof进行重写。

aof优点

• 备份机制更加稳健，丢失数据概率更低。
• 可读的日志文件，通过操作aof文件，可以处理误操作。

aof缺点

• 比rdb占用更多的磁盘空间
• 恢复备份速度要慢
• 每次读写都要同步的话，有一定的性能压力。
• 存在个别bug，数据不能恢复。

用那个？

• 官方推荐两个都启用
• 如果对数据不敏感，可以选单独使用rdb。
• 不建议单独用aof,因为可能会出现bug。
• 如果只是做纯内存缓存，可以都不用。