Reference: https://blog.csdn.net/u011692780/article/details/81213010
一、事务的四大特性
关系型数据库的事务具有四个特性：
-
原子性
-
一致性
-
隔离性
-
持久性
二、而在我们redis数据库中，事务回事什么样子的呢？
首先我们给出一个定义：redis的事务中，一次执行多条命令，本质是一组命令的集合，一个事务中所有的命令将被序列化，即按顺序执行而不会被其他命令插入
在redis中，事务的作用就是在一个队列中一次性、顺序性、排他性的执行一系列的命令。
事务的生命周期：
-
事务的创建：使用MULTI开启一个事务
-
加入队列：在开启事务的时候，每次操作的命令将会被插入到一个队列中，同时这个命令并不会被真的执行
-
EXEC命令进行提交事务
常用的关于事务的命令有：
-
MULTI：使用该命令，标记一个事务块的开始，通常在执行之后会回复OK，（但不一定真的OK），这个时候用户可以输入多个操作来代替逐条操作，redis会将这些操作放入队列中。
-
EXEC：执行这个事务内的所有命令
-
DISCARD：放弃事务，即该事务内的所有命令都将取消
-
WATCH：监控一个或者多个key，如果这些key在提交事务（EXEC）之前被其他用户修改过，那么事务将执行失败，需要重新获取最新数据重头操作（类似于乐观锁）。
-
UNWATCH：取消WATCH命令对多有key的监控，所有监控锁将会被取消。
注意：关于乐观锁等概念：
乐观锁：就像他的名字，不会认为数据不会出错，他不会为数据上锁，但是为了保证数据的一致性，他会在每条记录的后面添加一个标记（类似于版本号），假设A 获取K1这条标记，得到了k1的版本号是1，并对其进行修改，这个时候B也获取了k1这个数据，当然，B获取的版本号也是1，同样也对k1进行修改，这个时候，如果B先提交了，那么k1的版本号将会改变成2，这个时候，如果A提交数据，他会发现自己的版本号与最新的版本号不一致，这个时候A的提交将不会成功，A的做法是重新获取最新的k1的数据，重复修改数据、提交数据。
悲观锁：这个模式将认定数据一定会出错，所以她的做法是将整张表锁起来，这样会有很强的一致性，但是同时会有极低的并发性（常用语数据库备份工作，类似于表锁）。
那么，现在我们来执行一次具体看看redis的事务机制：
首先我会开启事务，并向数据库中存储4条数据，可以看到没执行一条命令的时候都会显示入队，并不会返回执行结果，说明redis中在事务提交之前，其内部的所有命令将不会被执行：
那么，如果中间有命令出错了会怎样呢？现在我随便打几个字符试一试：
可以看出，在第三条命令中我随便打了几个字符，提交事务的时候并没有成功，这也很符合我们对事务的理解，嗯~具有原子性。但是，有一个细节，那就是错误命令在我输入的时候就已经报错了，也就是说这个条错误命令在进入队列的时候redis就已经知道这是一条错误命令，这样，整个事务的命令将全部失败，那么，有没有一种可能某个错误指令在进入队列的时候redis还没有发现他的错误呢？我们试一试下面这个例子：
问题出现了，我们可以看到，name+1这条指令其实是错误的，但是提交事务的时候会发现，这条错误命令确实没有执行，但是其他正确的命令却执行，这是为什么的？
原因是在redis中，对于一个存在问题的命令，如果在入队的时候就已经出错，整个事务内的命令将都不会被执行（其后续的命令依然可以入队），如果这个错误命令在入队的时候并没有报错，而是在执行的时候出错了，那么redis默认跳过这个命令执行后续命令。也就是说，redis只实现了部分事务。
下面我们来看看刚刚提到的锁的问题，我们说过，redis的锁CAS(check and set)类似于乐观锁，redis的实现原理是使用watch进行监视一个（或多个）数据，如果在事务提交之前数据发生了变化（估计使用了类似于乐观锁的标记），那么整个事务将提交失败，我们可以举一个例子，我们开启两个终端，模拟两个人的操作，设置一条数据为count，初始时100，现在A对其进行监控，并且为count增加20
在没有提交之前，B也获取了这个count，为其减少50，
那么这个时候A如果提交事务，会出现失败提示：
可以看到，在A对数据的修改过程中，B对数据进行了修改，那么这条数据的”标记”就发生了变化，已经不是当初A取出数据的时候的标记了，这样，A的事务也就提交失败了。
最后通过上述的实验，我们总结redis事务的三条性质：
- 单独的隔离操作：事务中的所有命令会被序列化、按顺序执行，在执行的过程中不会被其他客户端发送来的命令打断
- 没有隔离级别的概念：队列中的命令在事务没有被提交之前不会被实际执行
- 不保证原子性：redis中的一个事务中如果存在命令执行失败，那么其他命令依然会被执行，没有回滚机制
三、Redis中的事务为什么没有原子性与watch锁
在传统的关系型数据中，只要有任意一条指令失败，则整个事务都会被撤销回滚，而在Redis中，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做，也因此得出 Redis 事务的执行并不是原子性的。
multi，代表一段事务的开始
exec，代表一个事务的提交
queued，代表某个指令在队列中
但是，也有例外，比如如下这种情况
discard,代表某个事务撤销
watch 锁 ，在事务中不能改变被锁的值 (exec提交后返回nil)
四、总结
在redis中，对于一个存在问题的命令，如果在入队的时候就已经出错，整个事务内的命令将都不会被执行（其后续的命令依然可以入队），如果这个错误命令在入队的时候并没有报错，而是在执行的时候出错了，那么redis默认跳过这个命令执行后续命令。也就是说，redis只实现了部分事务。
总结redis事务的三条性质：
- 单独的隔离操作：事务中的所有命令会被序列化、按顺序执行，在执行的过程中不会被其他客户端发送来的命令打断
- 没有隔离级别的概念：队列中的命令在事务没有被提交之前不会被实际执行
- 不保证原子性：redis中的一个事务中如果存在命令执行失败，那么其他命令依然会被执行，没有回滚机制
Original: https://www.cnblogs.com/skying555/p/10398724.html
Author: alex.shu
Title: redis的事务不是原子性
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/529246/
转载文章受原作者版权保护。转载请注明原作者出处！