事务的冲突场景：
买车票时，票只有一张，但是买票的人有1000个人，冲突就是一千个人都会买到票，但是真实的情况是只能有一个人能支付成功买到车票。
结局方案：
1、悲观锁：
结合场景理解，当一个人买票的时候，其他人都不能进行买票操作。这种锁的机制在传统的关系型数据库中常有体现，比如：行锁、表锁、读锁、写锁等，都是在操作之前先上锁。
2、乐观锁：
结合场景理解，大家都可以抢票，都可以进入付钱，但是只有一个人能支付成功。当一个人支付成功了之后，其他人就无法支付了，这里有一个版本号控制机制，类似于车站的【票已售空】的牌子，开始有一张票的时候，单价都可以去买票，那个时候牌子上面写的是有余票，但是当第一个人已经买了票之后，那个版本号就会更改，也就是牌子上面写票已售空，这时候大家就会检查一下这个版本号，如果和原来的版本号不一样，那么就无法执行买票操作了。
乐观锁不会像悲观锁一样在操作之前加锁，但是在操作之前回去检查一下这个数据是否被更新。
乐观锁适用于多读的类型，这样可以提高吞吐量。
Redis就是利用这种check-and-set机制实现事务的。
乐观锁在Redis中的使用：
命令：watch key [key ...]
在启动事务之前，也就是执行multi之前，先执行watch key [key...] ，可以监视一个或者多个key，如果事务在执行（exec）只之前，这些key被其它命令所改动，那么事务将会被打断。
模拟一个场景：两个事务去操作一个整型的数字k1，都加10，两个事务启动之前，各自都需要使用watch命令将k1监视起来，然后两个事务都可以进入命令队列，但是执行（exec）时，只能时先执行的那个事务可以执行成功，后执行的就会报错。