redis事务冲突问题 - 乐观锁和悲观锁

事务冲突很容易就想到是并发带来的问题。

例子

马上618了、假如一个场景：有很多人有你的账户并且该账户只有10000,同时去参加618抢购,同时发送了三个请求

一个请求想给金额减8000
一个请求想给金额减5000
一个请求想给金额减1000

这三个请求同时发出，假如都执行成功了，那么此时账户的余额就变成了10000-8000-5000-1000 = -4000，此时账户余额变成负的了，显然这在实际生活中是很不合理的。

这时我们能想到的就是加锁了。

悲观锁和乐观锁

1. 悲观锁

顾名思义，就是很悲观的那种，喜欢胡思乱想每次去拿数据的时候总认为别人会改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

2. 乐观锁

和悲观锁相反在拿到数据时不会加锁，因为他相信这世界是美好的，别人不会修改，但出于严谨还是会在改数据的那一刻会检查一下有没有被人修改。可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

乐观锁比悲观锁的效率要高，因为悲观锁每次都会加锁而乐观锁只是在修改数据时检查一下版本号是不是刚拿到的版本号不是就不能执行，是就执行。

redis中WATCH

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

实例：
设置一个键为balance 值为10的字符串类型数据。
使用watch监控
开启两个客户端，分别监控后再开启事务对balance进行+100操作，客户端一先提交会成功，客户端二提交会失败，这就是WAYCH对事务监控，防止事务冲突。

客户端一：执行事务成功

客户端二：执行事务失败

总结

• 在实际应用中很容易出现并发问题、所以我们要在redis事务中加锁解决事务的冲突问题
• 在redis中使用的check-and-set乐观锁机制实现事务的
• redis中的乐观锁使用watch命令来实现的