Redis 解决事务冲突之乐观锁和悲观锁

一、Redis的事务冲突问题

例子：
比如说，3个人有你的账户：你有10000元
一个人请求想给金额减 8000
一个人请求想给金额减 5000
一个人请求想给金额减 1000

二、悲观锁

悲观锁(Pessimistic Lock)，顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁（上锁后不允许其他事务操作），这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁

缺点是效率低，只能串行操作

三、悲观锁

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，所以所有人都可以拿到数据，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。

读数据的时候畅通无阻，更新数据的时候需要匹配读出来的数据的版本号和数据库内数据的版本号，一致则可修改，修改后写回数据库；若更新数据时，和数据库内数据的版本号不一致，就不允许更新，需要读出新版本号的数据继续操作

乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

四、乐观锁的使用

在执行 multi 开启事务之前，先执行 watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断

unwatch 取消 WATCH 命令对所有 key 的监视：如果在执行 WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了

watch监视功能通过乐观锁实现

两个终端都监视balance并开启事务


终端1对balance加10

终端1对balance加20

终端1 exec执行事务成功

终端2 exec执行事务失败

分析： 乐观锁导致终端2事务执行失败；2个终端都得到balance这个数据，都对它监视，第一个终端先加10，然后就更新了版本号了，第二个终端执行加20，判断读取出来的balance的版本号和数据库里balance版本号，发现不一样了，就不能执行操作了

五、Redis 事务三特性

• 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断

• 没有隔离级别的概念：开启事务后，没有exec提交之前命令只是存放在队列中，都不会实际被执行

• 不保证原子性：事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚（这点和MySQL的原子性不一样）