Redis事务控制
1、Redis事务控制的相关命令汇总
| 命令名 | 作用 |
|---|---|
| MULTI | 表示开始收集命令，后面所有命令都不是马上执行，而是加入到一个队列中。 |
| EXEC | 执行MULTI后面命令队列中的所有命令。 |
| DISCARD | 放弃执行队列中的命令。 |
| WATCH | “观察”、“监控”一个KEY,在当前队列外的其他命令操作这个KEY时，放弃执行自己队列的命令 |
| UNWATCH | 放弃监控一个KEY |
我们先测试一下
MULTI
SET number 100
INCR number
EXEC
执行效果如下所示：
当我们执行中间出错时，整个事务都会失败而且回滚。
这里如果我们之前学过数据库的话，应该觉得很正常
但是当我们执行以下命令时
MULTI
SET number 1000
incr number
incr number
incriby number aaa
exec
运行结果如下
我们会发现整个事务并没有回滚
对于此官方解释了：
如果你有使用关系式数据库的经验， 那么 “Redis 在事务失败时不进行回滚，而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。以下是这种做法的优点：
Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。
有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。 举个例子， 如果你本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这些情况的。
因我我们需要加强对生产环境中的错误异常处理
2、Redis乐观锁的体现
我们先来执行以下代码
set num 100
get num
watch num
MULTI
incr num
incr num
get num
然后我们新开一个客户端，设置了一下num的值
然后在刚才的界面执行EXEC
这时候我们会发现命令执行失败了，整个事务回滚了。
这就是一个乐观锁的体现，
简而言之就是、如果别人在我的队列命令执行之前，修改了我的数据，那我就直接放弃了。
乐观锁和悲观锁需要依据具体的实现进行使用
- 悲观锁（数据库中的行锁和表锁）
- 认为当前环境非常容易发生碰撞，所以执行操作前需要把数据锁定，操作完成后释放锁其他操作才能继续进行操作。
- 乐观锁
- 认为当前环境不容易发生碰撞，所以执行操作前不锁定数据，万一碰撞真的发生了，那么放弃自己的操作
Redis 内只有乐观锁，并无悲观锁，因为Redis对性能的要求很高。