Redis事务是一个单独的隔离操作：事务中的所有的命令都会序列化，按顺序执行。事务在执行的过程中，不会被其其他客户端发送来的命令请求所打断。Redis事务的主要作用就是串联多个命令防止别的命令插队
特点：
1.Redis事务没有隔离级别的概念
2.所有的命令在事务中，并没有直接被执行，只有发起执行命令的时候才会执行！Exec
3.Redis单条命令式保存原子性的，但是事务不保证原子性！
|-----------|---------------------------------------------------|
| 命令 | 描述 |
| multi | 标记一个事务的开始 |
| exec | 执行所有事务块内的命令 |
| watch key | 监视一个或者多个key,如果在事务执行之前这个或者这些key被其他命令那么事务将被打断。类似乐观锁 |
| discard | 取消事务，放弃执行事务块内的所有命令 |
| unwatch | 取消watch命令所有key的监视 |
悲观锁
悲观锁 (Pessimistic Lock) , 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每 次在拿数据的时候都会上锁，这样别人想拿这个数据就会block 直到它拿到锁。 传统的关系型数据库里 边就用到了很多这种锁机制 ，比如 行锁 ， 表锁 等， 读锁 ， 写锁 等，都是在做操作之前先上锁
乐观锁
乐观锁 (Optimistic Lock) 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不 会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。 乐观锁适用于多读的应用类型，这样可以提高吞吐量 。 Redis 就是利用这种 check-and-set 机制实现事务的
redis持久化
Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中
的数据库状态也会消失。所以 Redis 提供了持久化功能！
持久化过程保存什么
- 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据 （ RDB ）
- 将数据的操作过程进行保存 , 日志形式，存储操作过程，关注点在数据的操作过程 （
AOF ）
RDB方式
在指定的时间间隔内将内存中的数据集 快照 写入磁盘， 也就是行话讲的 Snapshot 快照，它恢复时是将快照文件直接读到内存里
RDB手动
save指令
命令：save
作用：手动执行一次保存操作
save指令相关配置
dbfifilename dump.rdb
说明：设置本地数据库文件名，默认值为 dump.rdb
经验：通常设置为 dump- 端口号 .rdb
dir
说明：设置存储 .rdb 文件的路径
经验：通常设置成存储空间较大的目录中，目录名称 data
rdbcompression yes
说明：设置存储至本地数据库时是否压缩数据，默认为 yes ，采用 LZF 算法 压缩
经验：通常默认为开启状态，如果设置为 no ，可以节省 CPU 运行时间，但会使存储的文件变大（巨 大）
rdbchecksum yes
说明：设置是否进行 CRC64 算法 RDB 文件格式校验， 该校验过程在写文件和读文件过程均进行
经验：通常默认为开启状态，如果设置为 no ，可以节约读写性过程约 10% 时间消耗，但是存储一定的数据损坏风险
save 指令工作原理 ( 单线程任务执行序列 )
客户端 1 127.0.0.1:6379>set key1 value1
客户端 2 127.0.0.1:6379>set key2 value2
客户端 3 127.0.0.1:6379>save
客户端 4 127.0.0.1:6379>get key
对 redis 数据库执行 4 此指令顺序 ===> set set save get
注意： save 指令的执行会阻塞当前 Redis 服务器，直到当前 RDB 过程完成为止，有可能会造成长时间阻 塞，线上环境不建议使用
bgsave 指令
命令 ： bgsave
作用 ：手动启动后台保存操作，但不是立即执行
bgsave 指令工作原理
注意： bgsave 命令是针对 save 阻塞问题做的优化。 Redis 内部所有涉及到 RDB 操作都采用 bgsave 的方式，save 命令可以放弃使用
Fork
Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
RDB自动
配置 ： save second changes
作用 : 满足限定时间范围内 key 的变化数量达到指定数量即进行持久化
参数 :
second：监控时间范围
changes：监控key 的变化量
位置 : 在 conf 文件中进行配置
注意：
save 配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的
save 配置中对于 second 与 changes 设置通常具有互补对应关系，尽量不要设置成包含性关系 save配置启动后执行的是 bgsave 操作
RDB 优点
RDB 是一个紧凑压缩的二进制文件，存储效率较高
RDB 内部存储的是 redis 在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
RDB 恢复数据的速度要比 AOF 快很多
RDB 节省磁盘空间
RDB 缺点
Fork 的时候，内存中的数据被克隆了一份，大致 2 倍的膨胀性需要考虑
虽然 Redis 在 fork 时使用了 写时拷贝技术 , 但是如果数据庞大时还是比较消耗性能
RDB 方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
Redis 的众多版本中未进行 RDB 文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象