「这是我参与11月更文挑战的第5天，活动详情查看：2021最后一次更文挑战」
事务
- 在我们日常工作中，遇到的很多场景都需要介入事务去解决
- 如日常的转账，购买商品，退款等等一系列的操作
- 我们来看
redis中的事务 - 我们是存储了
a == 1，让a`自增两次，最后将事务执行
- 具体过程
-
首先当我们没执行
exec的时候，我们上面的操作都是在redis缓存的一个事务队列中， -
当我们执行每次命令的时候，
QUEUED就代表进入了队列中 -
当执行
exec才代表真正的执行了这条事务
-
模拟一次事务失败的过程
- 首先我们
MULTI表示是一个事务-
将
a置位1，然后将a自增加一，再将b置为字符串test -
将
b自增，这时是错误的，因为字符串是无法自增的 -
此时再将
a自增加一，最后执行exec是报错的
当所有的命令进入队列中的时候，如果有错误其实是不会回滚的，当
get a的时候a的值仍然是自增后的结果为3 -
乐观锁-watch
- 当我们的业务是对数据更改的复杂，那么我们只能在逻辑业务中进行更改
- 所以
redis提供了watch，会在MULTI之前使用watch盯紧变量， - 如果在
watch一个变量以后，再对这个变量进行修改那么就会报错(执行事务以后返回的是nil) - 如下图所示
- 所以
- 在我们实际业务中，事务一般都放在代码中去维护
- 如使用springboot的注解去实现事务，而如果维护在redis中是不太稳妥的
- 因为在代码中我们可以清晰的将事务与业务场景融合，所以在做原子类的业务的时候，尽量都交给框架和逻辑代码去搞定
总结 redis 是支持事务的，但是事务中是没有回滚功能的，每次的命令都放到了队列中🦄
