1. 事务

1. 定义

1. 单独的隔离操作，事务所有命令都会序列化，按顺序执行，执行过程中不会被打断
2. 串联多个命令，防止被打断

2. 基本命令

1. Multi：命令进入到命令队列，不会执行

2. Exec：执行命令

3. 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 v3
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) OK
127.0.0.1:6379> keys *
1) "k2"
2) "k1"

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> set k4 v4
QUEUED
127.0.0.1:6379(TX)> discard
OK
127.0.0.1:6379> keys *
1) "k2"
2) "k1"

3. 事务错误处理

1. 组队过程中，出现命令错误，则都不会执行
2. 执行过程中，出现命令错误，则只有错误指令不会执行

4. 事务的冲突问题

1. 悲观锁：对共享变量操作前先进行上锁

2. 乐观锁：都可以访问，迭代版本号，版本号判断后再更新数据

3. watch key [key2 ...]

   1. 每个事务执行multi前，可以先执行watch key1 [key2],监视一个或多个key，如果事务执行前key被其他命令所改动，事务将被打断

4. unwatch key ：取消监视

5. 事务三特性

1. 单独的隔离操作：所有命令序列化执行，不会被其他命令打断

2. 没有隔离级别的概念：队列中的命令没有提交前都不会被执行

3. 不保证原子性：执行过程一条命令执行失败，其他命令仍会进行，没有回滚

持久化操作

1. Redis是基于内存的数据库，数据也可以写入硬盘中，这个过程就叫持久化操作
2. 提供了两种持久化方式
   • RDB (Redis DataBase)
   • AOF (Append Of File)

1. RDB

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

1. 实现方式（写时复制技术）
   • 单独创建一个子进程（fork）进行持久化
   • 现将数据写入到一个临时文件
   • 再用临时文件替换上次持久化好的文件
   • 最后一次持久化后的数据可能丢失
2. fork
   1. 复制一个和当前线程一样的进程，新进程所有数据和原进程一样，并作为原进程的子进程
   2. 一般父子进程共用一段物理内存，只有进程空间的各段内容要发生变化时，才会将父进程的内容复制一份给子进程

3. dump.rdb文件配置
   • 可以在redis.conf修改配置文件名称，默认为dump.rdb，
   • 修改配置位置，默认为Redis启动时命令行所在的目录下dir ./
4. 如何触发RDB快照
   • 修改持久化save 300 100,300秒内改变100个key，触发持有化存储
   • save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。
   • bgsave：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。
   • 可以通过lastsave 命令获取最后一次成功执行快照的时间
   • 执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义
5. 其他配置
   • stop-writes-on-bgsave-error：当Redis无法写入磁盘的话，直接关掉Redis的写操作。推荐yes.
   • rdbcompression：对于存储到磁盘中的快照是否进行压缩，会CPU消耗性能，默认采用redis会采用LZF算法进行压缩。推荐yes.
   • rdbchecksum ：使用CRC64算法来进行数据校验，检查完整性，会增加大约10%的性能消耗。推荐yes.
6. RDB备份
   1. 将备份的文件放到工作目录下，redis.conf的配置位置，并将名字修改为配置文件名字
   2. 启动redis,备份文件会直接加载
7. 优势
   • 适合大规模的数据恢复
   • 对数据完整性和一致性要求不高更适合使用
   • 节省磁盘空间
   • 恢复速度快
8. 缺点
   • Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
   • 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
   • 在备份周期在一定间隔时间做一次备份，如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

2. AOF

1. 特点

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

2. 配置AOF（默认不开启）

   • 修改默认的appendonly no，改为yes
   • 可以在redis.conf中配置文件名称，默认为appendfilename "appendonly.aof"
   • AOF文件的保存路径，和RDB的路径一致
   • AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）
   • no-appendfsync-on-rewrite：如果 yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但如果宕机会丢失这段时间的缓存数据。

3. 备份恢复AOF

   • 正常恢复过程同RDB
   • 异常恢复（AOF文件存在损坏)，在启动之前，通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复

4. AOF同步频率设置

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

5. Rewrite压缩

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

触发条件
auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）
auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。
系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,
如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。 

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

7. 重写流程
   
8. 优势
   • 备份机制更稳健，丢失数据概率
   • 可读的日志文本，通过操作AOF稳健，可以处理误操作
9. 缺点
   • 比起RDB占用更多的磁盘空间。
   • 恢复备份速度要慢。
   • 每次读写都同步的话，有一定的性能压力。
   • 存在个别Bug，造成恢复不能。

选择存储文件

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

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

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

4. 官网建议

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

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

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

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

   • 同时开启两种持久化方式：在这种情况下，当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。

   • RDB 的数据不实时，同时使用两者时服务器重启也只会找 AOF 文件。那要不要只使用 AOF 呢？

   • 建议不要，因为 RDB 更适合用于备份数据库 (AOF 在不断变化不好备份)，快速重启，而且不会有 AOF 可能潜在的 bug，留着作为一个万一的手段。

5. 性能建议：

   • 因为 RDB 文件只用作后备用途，建议只在 Slave 上持久化 RDB 文件，而且只要 15 分钟备份一次就够了，只保留 save 9001 这条规则。
   • 如果使用 AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单，只 load 自己的 AOF 文件就可以了。
   • aof 代价：一是带来了持续的 IO，二是 AOF rewrite 的最后，将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
   • 只要硬盘许可，应该尽量减少 AOF rewrite 的频率，AOF 重写的基础大小默认值 64M 太小了，可以设到 5G 以上。默认超过原大小 100% 大小时重写可以改到适当的数值。