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对性能的要求很高。