简介
上一篇文章我们介绍了Redis的事务的基本概念，基本操作以及基本特性。这篇文章我们接着来学习Redis的事务，本文主要介绍何为事务冲突，以及如何处理事务冲突，从而引入锁机制的概念，最后就是说下Redis中采用的是何种锁机制。
何为事务冲突
在电商场景中经常有的一个场景就是秒杀抢购。秒杀场景就是将拿出少量的某个商品以特价的方式，在极短的时间内销售，在该场景下会出现很多人抢非常少的商品的情况。
举个例子：比如现在有2个特价电冰箱销售，现在同时有三个人进行抢购，每个人限抢1件，如果不做控制的话就会出现超卖的情况。那么如何进行控制呢？这里就需要用到锁机制，锁分为悲观锁和乐观锁。
悲观锁
悲观锁（Pessimistic Lock）,顾名思义，就是很悲观，每次去拿数据的时候都会认为别人会修改，所有每次在拿数据的时候都会上锁，这样别人想拿这个数据就会被阻塞直到它拿到锁。（换句话说就是对数据加锁，每个人之后获得锁了，才能操作该数据）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
乐观锁
乐观锁（Optimistic Lock）,顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种 check-and-set 机制实现事务的。
WATCH命令
WATCH命令是一个乐观锁，它可以在EXEC命令执行之前，监视任意数量的数据库键，并在EXEC命令执行时，检查被监视的键是否至少有一个已经被修改过了，如果是的话，服务器将拒绝执行事务，并向客户端返回代表事务执行失败的空回复。WATCH命令的格式是：watch key1 [key ....] 可以监视一个（或多个）key。如下图所示：
unwatch
取消WATCH命令对所有key的监视。
如果在执行WATCH命令之后，EXEC命令或DISCARD命令先被执行了的话，那么就不需要再执行UNWATCH了。
Redis事务的三特性
1.单独的隔离操作
事务中的所有命令都会被序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
2.没有隔离级别的概念
队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行。
3.不保证原子性
事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。
总结
本文详细介绍了悲观锁和乐观锁。Redis就是利用这种 check-and-set 机制实现事务的。
