Redis中的事务不像MySQL中的事务那么完整，Redis最大的特征就是速度快，也正是因为Redis无脑快，所以才会选用它。所以Redis的作者在开发任何功能的时候，他也是按照这个特性去做的。关系型数据库的事务其实实现起来非常的复杂，所以Redis为了追求最快的速度，从而在事务的实现上有很多妥协的地方。
Redis 事务的命令其实就那么几个，老规矩，先看一眼Redis中事务命令的相关说明：
multi就是标记要开启事务， 在开启事务之后，就可以将一股脑的将想要执行的命令全部发送给Redis，但是并不会执行，直到执行exec命令，Redis才会在服务端按照刚刚发送的顺序，将整个事务内的命令全部执行。
假设现在有两个客户端client1和client2，client1的发起事务命令先到达Redis，然后在事务中查询key的值；client2的发起事务命令后到达， 在事务中删除key的值。但是client2的exec命令比client1的exec命令先到达，那么从标记开始，对于同一个客户端所发来的所有命令都放在一个缓冲区里面，谁先出现了exec命令，哪个缓冲区中的所有所有命令都一起执行。
所以肯定是client2先将key删除了，client1就查询不到key的值了。得益于Redis是单进程的，所以事务相关的事还算是比较好处理的，谁的exec先到达，就先执行谁的事务。
至于watch命令呢，可以通过乐观锁实现CAS（check and set）操作。就是在事务前先加一个监控，监控某个key，后续如果有更先到达的事务将key的值改掉，发现key的值被改了，那么事务中的命令就没有执行的必要了。这已经Redis帮你的极限了，至于key被改变了以后具体还要做哪些处理，客户端自己去处理。
client2先执行的exec，将k1删除，client1取k1就取不到了。
再来看看watch的情况
client1先监控k2，然后开启事务，client2的事务比client1先执行，那么client1再get的时候就无法取到k2的值了。
为什么Redis不支持回滚？
很多时候我们认为的失败，其实并不是Redis所导致的失败，而是因为编程的时候人为犯下的一些错误。企业中开发完不可能直接上线，而是肯定会在测试环境中进行测试，这些人为的错误肯定是会被测试出来并被修正。也正是不需要对事物进行回滚处理，所以能保证极快的速度。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/111958.html
