在开发过程中，我们经常面对这种情况：
1、点击一个按钮无反应时，会不停的重复点击，如果前端代码未做限制，则会多次调用controller接口，如果controller不做特殊处理，往往会导致系统数据异常。
2、当多个用户同时做一项操作时，也会面临同样的问题。
经过分析，我们发现以上两种情况都是资源争夺的问题，第一种情况是资源浪费，第二种情况是资源竞争，如何解决这种幂等性的问题呢？那么大家首先想到的是加锁。
锁分为乐观锁和悲观锁。
悲观锁：select * from table where id=xx for update // 这条 sql 语句锁定了表中所有符合检索条件（ id=xx ）的记录。（需要注意的是for update要放到事务中，即begin和commit中，否者不起作用，当事务提交后，锁会释放）。
乐观锁：select * from table where id=xxx ；update table set ......//乐观锁在数据进行提交更新时，才会对数据的冲突与否进行检测，如果冲突了，则让返回用户错误信息，即只在更新的那一刻锁表，其他时间不锁表。
悲观锁简单，主要处理写多读少的问题，保证数据安全，乐观锁相对复杂，主要处理读多写少的问题，提交系统吞吐量。相对来说，乐观锁效率更高。
我们通过乐观锁解决以上问题，以下三种方式实现乐观锁：
1、通过增加版本号实现，我在很多项目上都是通过版本号来实现乐观锁的，但是加版本号毕竟对代码造成了侵入性，而且数据库会增加版本号字段。在很多场景尤其是系统升级时，并不方便。
例子： update table set col =#{col},version =version +1
where id =#{id} and version =#{version }
2、基于状态控制或时间戳实现乐观锁，状态控制实现乐观锁在部分场景可以用到
如：购物下单，逻辑是当订单状态为已付款，才允许发货：
核心SQL update table set status=下一种状态
where id =#{id} and status=#{status}
时间戳同版本号类似。
还有一种场景，我们可以判断当库存 - 下单数量>0 实现。如：
update table set amout=amout-#{buys}
where id=#{id} and amout-#{buys}>0
3、redis缓存实现乐观锁：
原理同方案 1，只是在缓存中实现。
实例演示：
1) 版本号实现乐观锁，以商品下单逻辑实例：
Integer amout =info.getAmout();获取库存
If(amout <bugs)
{//库存不够，直接返回false
return false;
}
//获取版本号
Integer version=info.getVersio()
if(object.updateAmoutByVersion(id,version)>0)
{//带版本号更新库存
return true;
}
2）通过状态机实现乐观锁
其他代码不变
if(object.updateAmoutBystate(id,buys)>0)
{//状态机实现乐观锁
return true;
}
核心SQL:update table set amout=amout-#{buys}
where id=#{id} and amout-#{buys}>0
条件加上 库存-购买数>0 即可以保证数据一致性
