Redis提供了将多个命令请求打包，然后一次性，按顺序的执行多个命令的机制，这种机制叫事务，并且在事务执行的过程中，服务器不会中断事务去执行其他客户端的请求，而是将事务的所有命令都执行完毕在去执行其他客户端请求
一个事务会经历以下三个阶段：
Redis中multi命令标志着事务的开始
myRedis:0>multi
"OK"
multi命令将执行的客户端从非事务状态切换到事务的状态，通过客户端的flags属性中打开REDIS_MULTI标识来完成切换
客户端在非事务状态下，客户端发送的命令会被立即执行，而在事务状态下，客户端会判断不同的命令执行不同的操作
每个Redis客户端都有自己的事务状态，状态保存在mstate属性中，事务状态包含事务的队列和已入命令的计数器（事务队列的长度）
typedef struct multiState {
//存储命令的FIFO队列
multiCmd *commands;
//队列长度
int count;
} multiState;
事务队列是一个multiCmd类型的数组，数组中每个元素都保存了一个入队命令相关的信息，结构如下
typedef struct multiCmd {
//参数数组
robj **argv;
//参数数量
int argc;
//命令的指针
struct redisCommand *cmd;
} multiCmd;
事务队列multiCmd ，以先进先出的方式（FIFO）保存入队命令
图解分析
myRedis:0>multi
"OK"
myRedis:0>set name guohu
"QUEUED"
myRedis:0>set age 28
"QUEUED"
myRedis:0>get name
"QUEUED"
myRedis:0>get age
"QUEUED"
客户端处于事务状态时，向服务器发送exec命令，此时exec命令会被立即执行，并且服务器会遍历客户端的事务队列，执行队列中所有的命令，并将所有队列命令执行的结果返回给客户端（注意：命令是按顺序执行的，先进先出规则）
myRedis:0>exec
1) "OK"
2) "OK"
3) "guohu"
4) "28"
watch命令是一个乐观锁，它可以在exec命令执行之前，监视任意数量的数据库键，并在exec命令执行时，检查是否至少有一个被修改过，如果监视到有修改，则拒绝执行事务，并想客户端发送事务执行失败的回复
| 执行时间 | 客户端A | 客户端B |
|---|---|---|
| time1 | watch “name” | |
| time2 | multi | |
| time3 | set age 28 | |
| time4 | set 29 | |
| time5 | exec |
客户端A
myRedis:0>multi
"OK"
myRedis:0>set age 28
"QUEUED"
myRedis:0>get age
"QUEUED"
新起一个客户端B
myRedis:0>set age 29
"OK"
myRedis:0>get age
"29"
回到客户端A，执行事务提交
myRedis:0>exec
1) "OK"
2) "28"
按道理事务里面提交的set时29，但是当执行exec的时候，会发现数据被覆盖了
客户端A执行命令
myRedis:0>flushdb
"OK"
myRedis:0>watch age
"OK"
myRedis:0>multi
"OK"
myRedis:0>set age 28
"QUEUED"
myRedis:0>set name guohu
"QUEUED"
myRedis:0>set address yinshanhu
"QUEUED"
myRedis:0>get name
"QUEUED"
myRedis:0>get address
"QUEUED"
另起一个客户端B执行
myRedis:0>set age 18
"OK"
myRedis:0>get age
"18"
再次回到客户端A执行事务提交
myRedis:0>exec
(nil)
myRedis:0>get age
"18"
myRedis:0>get name
null
myRedis:0>get address
null
监视到age发生变化，整个事务拒绝执行name和address都没有保存
事务中的原子性是指多个操作被打包成一个整体执行，要么全部执行，要么都不执行，就Redis性质来说，符合原子性的描述，事务里面的命令会被一起执行
但是Redis不支持事务回滚，如果其中有命令出错了，其他命令还会继续执行直到队列命令执行完毕
myRedis:0>multi
"OK"
myRedis:0>set name guohu
"QUEUED"
myRedis:0>incr name
"QUEUED"
myRedis:0>get name
"QUEUED"
myRedis:0>exec
1) "OK"
2) "ERR value is not an integer or out of range"
3) "guohu"
一致性指是指数据库在执行事务之前数据是一致的，在执行事务之后无论事务是否成功数据也是一致的，这符合数据库本身的定义和要求
隔离性指的是，即使有多个事务并发的执行，各个事务之间页不会相互影响，并且在并发状态下执行的事务和串行执行的事务产生的结果完全相同，而在Redis中事务的所有命令都会按顺序执行，在执行Redis事务的过程中，另一个客户端发出的请求不会被处理，这保证了命令是作为单独的独立操作执行的
数据库持久性是指当一个事务执行完毕之后，所得到的结果已经被保存到永久性的存储介质中（例如：硬盘），事务执行完毕之后即使数据库宕机，也不会影响事务执行的结果，不过Redis中的持久性依赖其持久化机制和是否被开启持久化，如果没开启持久化就是纯内存运行，重启后数据会丢失，而Redis的持久化有两种模式RDB和AOF，下面会介绍具体的持久化机制
Redis是数据是存在内存里面的，同时Redis也提供了两种持久化机制RDB和AOF，将内存的数据刷到硬盘上，避免数据的意外丢失
RDB记录的是数据
RDB持久化既可以手动执行，也可以根据服务器的配置来定期执行，RDB文件时一个压缩的二进制文件（dump.rdb），通过RDB文件可以还原生成RDB时间节点的数据库状态，服务在重启的时候会自动加载RDB文件进行数据恢复，RDB文件时保存再硬盘上的，所以即使redis服务关闭了，仍然可以还原数据库恢复数据
在Redis服务启动时会自动检测是否存在RDB文件，如果存在则自动载入
刚介绍了手动执行的两个命令，save和bgsave，由于bgsave可以不阻塞进程，Redis允许用户设置每隔一段时间自动执行bgsave的命令：
优点：
缺点：
与RDB不同的是，AOF持久化机制记录的是写命令
开启AOF之后，AOF是采用日志方式将写命令记录到文件中
需要注意的是，AOF默认是关闭的，如果同时使用AOF和RDB，Redis会优先使用AOF作为持久化模式
appendonly no //默认是no表示关闭，修改为yes则表示开启
appendfilename "appendonly.aof" //文件名
还可以通过appendfsync参数来控制是否实时写入磁盘
AOF文件里包含了所有Redis的写命令，所以只要服务器读到所有命令并重新执行一遍即可还原数据库状态
虽然可以用命令还原数据库状态，但是此时暴漏了一个缺点，假设写命令很多，那文件岂不是越来越大，又或者针对一个key执行了N次操作，实际上有效操作只有最后一次，为了解决这个问题，Redis提供了AOF文件重写功能
备注：说是重写，但实际上是根据现有的键值对分析出写命令，与原文件没有操作关系
写文件一般都是子进程 ，此时父继承是不阻塞的，还可以继续接受处理请求，当AOF重写过程中，父进程又有新的请求，这时就需要保证数据的一致性了，在执行AOF重写的操作时，有个AOF 重写缓冲区的概念，如果在重写期间有新的命令进入，会同时写入AOF缓冲区和AOF重写缓冲区
假设子进程完成了文件重写，会向父进程发送一个信号量，父进程紧接着会进行阻塞，并完成重写的以下剩余工作，之后就可以正常处理请求了
优点