为什么要持久化？
redis 如果仅仅只是将数据缓存在内存里面，如果 redis 宕机了再重启，内存里的数据就全部都弄丢了啊。你必须得用 redis 的持久化机制，将数据写入内存的同时，异步的慢慢的将数据写入磁盘文件里，进行持久化。
一、Redis持久化技术
1.1、redis 持久化的两种方式
- RDB（默认开启）：是对 redis 中数据执行周期性的持久化
- AOF：对每条写入命令作为日志，以 append-only的模式写入一个日志文件中，在 redis 重启的时候，可以通过回放 AOF 日志中的写入指令来重新构建整个数据集
RDB 或 AOF，都可以将 redis 内存中的数据给持久化到磁盘上面来，然后可以将这些数据备份到别的地方去，比如说阿里云等云服务。如果 redis 挂了，可从云服务上拷贝回来之前的数据。
如果同时使用 RDB 和 AOF 两种持久化机制，那么在 redis 重启的时候，会使用 AOF 来重新构建数据，因为 AOF 中的数据更加完整。
1.2、两种持久化方式优缺点（区别）
（1）RDB 优缺点：
优点：
RDB生成多个数据文件，每个数据文件都代表了某一个时刻中 redis 的数据，多个数据文件的方式，非常适合做冷备；RDB对redis读写服务影响小（读性能高），可让redis保持高性能；相对于 AOF恢复更快；
缺点：
RDB 数据快照文件，都是每隔 5 分钟或更久生成一次，AOF则是1秒，会比AOF丢失的数据多；RDB 每次在 fork 子进程来执行快照数据文件生成的时候数据量特大可能导致对客户端提供服务暂停
（2）AOF 优缺点：
优点：
（1）更好保护数据不丢失，最多丢失1秒数据；
（2）以append-only 模式写入，没有任何磁盘寻址开销，写性能高，文件易修复不易破损；
（3）日志文件即使过大，出现后台重写操作，也不会影响客户端的读写（因为在重写日志时会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来，在创建新日志文件的时候，老的日志文件还是照常写入。当新的交换后的日志文件准备好的时候，再交换新老日志文件即可）；
（4）通过非常可读的方式进行记录，适合做 灾难性的误删除的紧急恢复
缺点：
同一份数据来说，AOF 日志文件通常比 RDB 数据快照文件更大；AOF 开启后，支持的写 QPS（每秒查询率） 会比 RDB 支持的写 QPS 低；操作复杂更容易出现BUG
**
1.3、RDB 和 AOF 如何选择（最好两个一起用）
（1）不要仅仅使用 RDB，因为那样会导致你丢失很多数据；
（2）也不要仅仅使用 AOF，因为那样有两个问题：第一，你通过 AOF 做冷备，没有 RDB 做冷备来的恢复速度更快；第二，RDB 每次简单粗暴生成数据快照，更加健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug；
（3）redis 支持同时开启开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。
1.4、RDB和AOP相关配置
（1）RDB 默认开启，redis.conf 中的具体配置参数如下：
#dbfilename：持久化数据存储在本地的文件
dbfilename dump.rdb
#dir：持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下
dir ./
##snapshot触发的时机，save
##如下为900秒后，至少有一个变更操作，才会snapshot
##对于此值的设置，需要谨慎，评估系统的变更操作密集程度
##可以通过“save “””来关闭snapshot功能
#save时间，以下分别表示更改了1个key时间隔900s进行持久化存储；更改了10个key300s进行存储；更改10000个key60s进行存储。
save 900 1
save 300 10
save 60 10000
##当snapshot时出现错误无法继续时，是否阻塞客户端“变更操作”，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等
stop-writes-on-bgsave-error yes
##是否启用rdb文件压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的网络传输时间
rdbcompression yes
（2）AOF 默认关闭，开启方法，修改配置文件 reds.conf：appendonly yes：
实时以日志记录形式记录下操作，效率不高，会影响整体性能（但是比较安全）
##此选项为aof功能的开关，默认为“no”，可以通过“yes”来开启aof功能
##只有在“yes”下，aof重写/文件同步等特性才会生效
appendonly yes
##指定aof文件名称
appendfilename appendonly.aof
##指定aof操作中文件同步策略，有三个合法值：always everysec no,默认为everysec
appendfsync everysec
##在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不暂缓”，“yes”表示“暂缓”，默认为“no”
no-appendfsync-on-rewrite no
##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb”
auto-aof-rewrite-min-size 64mb
##相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。
##每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1 + p)之后
##触发下一次rewrite，每一次aof记录的添加，都会检测当前aof文件的尺寸。
auto-aof-rewrite-percentage 100
二、Redis事务
redis和数据库同步的话，写操作时也要ACID事务原则
2.1、Redis事务介绍
Redis 事务可以一次执行多个命令， 并且带有以下两个重要的保证：
（1）事务是一个单独的隔离操作：
事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
（2）事务是一个原子操作：
事务中的命令要么全部被执行，要么全部都不执行。
2.2、Redis设置事务示例
一个事务从开始到执行会经历以下三个阶段：开始事务、命令入队、执行事务
示例：先以 MULTI 开始一个事务， 然后将多个命令入队到事务中，最后由 EXEC 命令触发事务， 一并执行事务中的所有命令。
redis 127.0.0.1:6379> MULTI
OK
redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"
QUEUED
redis 127.0.0.1:6379> GET book-name
QUEUED
redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series"
QUEUED
redis 127.0.0.1:6379> SMEMBERS tag
QUEUED
redis 127.0.0.1:6379> EXEC
1) OK
2) "Mastering C++ in 21 days"
3) (integer) 3
4) 1) "Mastering Series"
2) "C++"
3) "Programming"(⊙o⊙)…
2.3、SpringBoot操作Redis事务
public void setString(String key, Object object) {
// 开启事务权限
stringRedisTemplate.setEnableTransactionSupport(true);
// 开启事务begin
stringRedisTemplate.multi();
try {
// 如果是String 类型
String value = (String) object;
stringRedisTemplate.opsForValue().set(key, value);
} catch (Exception e) {
// 回滚事务
stringRedisTemplate.discard();
} finally {
// 提交事务
stringRedisTemplate.exec();
}
}
