事务是众所周知的，在关系数据库中，事务时并发控制的基本单元，他是一个操作序列，可以包含多个指令。 另外，对于一个事务，内部指令不可分割，要么全部执行，要么全部不执行。
关系数据库事务具有以下四个特性：
1 .原子性
2 .一致性
3 .隔离性
4 .可持续性
在redis数据库中，事务是怎么回事？
首先，redis事务一次执行多个命令。 本质是一组命令的集合，一个事务中的所有命令都是序列化的。 这意味着它将按顺序执行，而不插入到其他命令中
在redis中，事务的作用是在一个队列中一次、按顺序、独占地执行一组指令。
事务的生命周期：
1 .创建事务：使用MULTI打开事务
2 .排队：启动事务时，每个操作的命令都会排队，但不会实际执行
3 .使用3. EXEC命令提交事务
有关典型事务的命令如下。
1. MULTI :使用此命令标记事务块的开始。 通常在执行后返回OK。 (但是，不一定真的可以。 )此时，用户可以输入多个操作来代替项目符号。 redis对这些操作进行排队。
2. EXEC :执行此事务中的所有命令
3. DISCARD :丢弃事务。 这意味着事务中的所有命令都将被取消
4 .监视4. WATCH或多个密钥。 如果这些key在提交事务(EXEC )之前被其他用户修改，则事务将失败，必须重新获取最新数据。 就像乐观摇滚。
5.unwatch :通过watch命令取消对许多key的监视会解除所有监视锁定。
注意：关于乐观摇滚等概念：
乐观摇滚：就像他的名字一样，我不认为数据没错。 他不会锁定数据。 但是，为了保证数据的完整性，在每条记录的后面添加标签(类似版本号)。 假设a获得了K1的标签，K1的版本号是1，则将其修正。 此时，b也取得了K1这个数据。 当然，b取得的版本号也是1，同样也对K1进行处理。如果b先提交的话，K1的版本号会变更为2。 此时，如果a提交数据，就会知道自己的版本号与最新的版本号不一致。 此时，a的提交不会成功。 A的做法是重新获取最新的k1数据，反复修改数据、提交数据。
悲观锁定：由于该模型确定数据有错误，她的做法是锁定整个表，从而提高一致性，但同时具有非常低的并发性。 (类似表格锁定的普通话数据库备份工作)。
现在，我们来具体看看redis的事务机制。
首先打开事务，在数据库中保存四个数据。 请注意，当没有一个命令运行时，它将入队，并且不会返回任何运行结果。 这表示在redis中提交事务之前，不会执行所有内部命令。
那么，如果中途命令有误会怎么样呢？ 现在我试着打几个字：
在第三个命令中我随便打了几个字，就知道提交事务时没有成功。 这也很符合对事务的理解。 啊~有原子性。 但是，有一个细节。 也就是说，错误的命令在我输入的时候已经被错误地报告了。 也就是说，这个错误的指令在排队的时候redis已经知道那是错误的指令。 这样，整个事务的指令都会失败。 那么，当某个错误的命令排队时，redis有可能还没有注意到他的错误吗？ 试试下面的例子。
发生了问题。 name 1这个指令其实是错误的，但是提交事务后，这个错误的指令确实没有被执行，但是其他正确的指令会被执行。 这是为什么？
这是因为，如果问题命令在入队时出现错误，redis将不会执行整个事务的命令。 后续命令可以入队。 如果此错误命令在入队时不报告错误，并且在运行时出现错误，则缺省情况下，redis将跳过此命令并执行后续命令。 也就是说，redis只实现了一部分事务。
看看刚才提到的摇滚问题吧。 他说，redis的摇滚CAS(checkandset )类似于乐观摇滚。 redis的实现原理是使用watch监视一个以上的数据。 如果在提交事务之前数据发生了更改，)则估计使用了类似乐观锁的标记。 整个事务提交失败。 举个例子。模拟两个人的操作，将一个数据作为count，初期为100，现在a监视它，在count上加20
在提交之前，b也得到了这个count，减少了50。
那么，这个时候A提出事务的话，会出现失败的提示。
如您所见，在a修改数据的同时，如果b修改了数据，则该数据的“标记”会发生变化，不再是当初a取出数据时的标记。 这样，a的事务也将提交失败。
最后，通过上述实验，总结了redis事务的三个性质。
1 .独立隔离操作：事务中的所有命令都是序列化的、按顺序执行的，在执行过程中不会被其他客户端发送的命令中断
2 .没有隔离级别的概念：在提交事务之前，队列中的命令不会实际执行
3 .不保证原子性：如果在redis中的一个事务中命令执行失败，其他命令将在没有回滚机制的情况下执行