【Redis】redis事务和锁、持久化、RDB、AOF、主从复制、集群、缓存穿透、缓存击穿、缓存雪崩、分布式锁和ACL机制

Redis事务和锁机制

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

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

Multi、exec、discard

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

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

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1 
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> exec
1）OK
2）OK
127.0.0.1:6379> 

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set a1 b1
QUEUED
127.0.0.1:6379(TX)> set a2 b2
QUEUED
127.0.0.1:6379(TX)> discard
OK
127.0.0.1:6379> 

错误示范：

​ 在组队过程中出现了错误：

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 b2
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> 

​ 在执行过程中出现了错误：

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
127.0.0.1:6379> 

事务的冲突问题

悲观锁

先上锁，后操作，操作完解锁。

1000 ——> if 1000>800 then -800 ——>剩200——>if 200 > 500 then -500 ——>200

上锁 解锁 /上锁 不操作

乐观锁

加上数据的版本号(v1.0)，2个请求可以同时进行，当一个请求结束后，会更改当前的版本号(v1.1)，另一个请求改数据之前检查数据的版本号 (check-and-set v1.0!=v1.1)

WATCH key [key…] 乐观锁

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

主机1：

127.0.0.1:6379> watch 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) 10
127.0.0.1:6379> 

主机2：

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
(nil)
127.0.0.1:6379> 

Redis事务三特性

单独的隔离操作

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

没有隔离级别的概念

• 队列的命令没有提交之前都不会实际被执行，因为事务提交前任何执行都不会被实际执行。

不保证原子性

• 事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。

Redis持久化

两种持久化方式

1. RDB
2. AOF

RDB

​ 含义：在指定的时间间隔内将内存中的数据集快照写入磁盘

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

​ 优势：

1. 适合大规模的数据恢复
2. 对数据完整性和一致性要求不高更适合使用
3. 节省磁盘空间
4. 恢复速度快

​ 缺点：

1. fork的时候，在内存中的数据被克隆了一份，大致2倍的膨胀需要考虑
2. 虽然Redis在fork时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能。
3. 在备份周期内一定间隔时间做一次备份，如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

fork

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

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

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

RDB的备份

# Unless specified otherwise, by default Redis will save the DB:
#   * After 3600 seconds (an hour) if at least 1 key changed
#   * After 300 seconds (5 minutes) if at least 100 keys changed
#   * After 60 seconds if at least 10000 keys changed
#
# You can set these explicitly by uncommenting the three following lines.
#
# save 3600 1
# save 300 100
save 20 3
#20秒内有三次数据写入就会触发持久化操作，保存到当前路径下，名称为dump.rdb

AOF备份

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

如果AOF和rdb同时开启，则默认启动AOF

AOF启动/修复/恢复

• 正常恢复：

​ 修改redis里面的这一处内容：appendonly由no改为yes：

appendonly yes

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

​ 恢复：重启redis然后重新加载

• 异常恢复：

  1. 修改默认的appendonly no，改为yes
  2. 如果遇到AOF文件损坏，通过redis-check-aof --fix appendonly.aof进行恢复
  3. 备份被写坏的AOF文件
  4. 恢复：重启redis，然后重新加载

  AOF同步频率设置

  appendfsync always

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

  appendfsync everysec

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

  appendfsync no

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

Rewrite压缩

含义：

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

原理：

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

触发条件：

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

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

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

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

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

重写过程：

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

AOF持久化流程

1. 客户端的请求写命令会被append追加到AOF缓冲区内；
2. AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
3. AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
4. redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

AOF优势