这几年O2O火爆，10个创业公司里就有9个是O2O的电商，相信支付抢购什么的以前听起来高大上的东西现在很多码农都会需要自己去实现。
说到支付，就一定会涉及到事务。说到事务，肯定很多码农泪千行。
在原来的数据库单机时代，你写一个事务并没有什么关系，我的支付逻辑涉及的所有表可能都在同一个数据库里，MySQL原生支持这些东西，学校里的老师也会跟你讲，事务是保证数据完整性的重要手段。
然而到了SOA时代，网站服务化，可能你的账户表和流水表都不在一个数据库里了(只是举例，不要太较真)。这种时候就有了分布式事务的概念。然后就有了各种二阶段提交，分布式CAP的取舍，基于消息队列实现的分布式事务等等等等。
扯远了，本文并不是想讲这些东西。
在大厨工作的时候听同事介绍过乐观锁这个概念，一开始以为是Java还是什么语言的语言特性，后来发现其实是一种写入、更新数据库时的逻辑特性。。
具体是这样的：
1.在需要加乐观锁的表中加入version字段
2.update时，在where条件后加入version = [select出来的之前的版本号]
那么乐观锁解决的是什么问题呢？
是并发更新时的数据覆盖问题，诚然，我们可以用悲观锁来避免这种事情的发生，那么可以直接用select for来对多条记录上行锁，之后再对这些数据进行update，这样后面的事务在select时就不会拿到错误的数据。但是悲观锁对数据库的性能影响比较大。而乐观锁可以实现同样的功能。
其原理是这样的：
单条记录
1.select阶段得到该条记录，带有版本号
2.update时将该条记录与其版本号进行对比，如果版本号与select得到的不一致，那么更新失败，affect_rows应该是0，否则更新成功
sql比较好写，例子：
select * from [table] where [业务逻辑];
update [table] set [业务逻辑] where id = [上面的id] and version = [上面的version]
多条记录
多条记录的乐观锁法，想了半天还真是很难写SQL，我们可以从业务上来限制这件事情。
比如在进行“订单状态”转移这个批量更新时，我们可以在where条件里加上订单状态的限制，如：
订单批量审核要求其前置状态必须是待审核，所以where status=[待审核]
实际上实现的也是乐观锁的效果
很简单吧~
说起来乐观锁一般情况下也不会在批量更新的时候被用到呢，如果想要批量更新时的更通用的乐观锁，看起来不是很好实现。。
