MYSQL 锁

乐观锁

  使用数据版本（Version或更新时间时间戳）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的时间戳字段来实现。当读取数据时，将时间戳字段的值一同读出，数据每更新一次，对此时间戳值会变。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的时间戳值进行比对，如果数据库表当前版本号与第一次取出来的时间戳值相等，则予以更新，否则认为是过期数据

1.查询出商品信息
select (status,updata_tm) from t_goods where id=#{id}
2.根据商品信息生成订单
3.修改商品status为2
update t_goods 
set status=2,updata_tm=time()
where id=#{id} and updata_tm=#{updata_tm};//updata_tm这里的updata_tm是之前查询出的时间

优缺点：
乐观锁认为数据竞争的概率是很小的，因此，尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。
乐观锁存在失效的情况，属小概率事件，需要多个条件共同配合才会出现。如：

• 应用采用自己的策略管理主键ID。如，常见的取当前ID字段的最大值＋1作为新ID。

• 版本号字段 version 默认值为 0 。

• 用户A读取了某个记录准备修改它。该记录正好是ID最大的记录，且之前没被修改过，version 为默认值 0。

• 在用户A读取完成后，用户B恰好删除了该记录。之后，用户C又插入了一个新记录。

• 此时，阴差阳错的，新插入的记录的ID与用户A读取的记录的ID是一致的， 而版本号两者又都是默认值 0。

• 用户A在用户C操作完成后，修改完成记录并保存。由于ID、version均可以匹配上，因此用户A成功保存。但是，却把用户C插入的记录覆盖掉了。
  乐观锁此时的失效，根本原因在于应用所使用的主键ID管理策略， 正好与乐观锁存在极小程度上的不兼容。

悲观锁

现项目中用的比较多的，都用的文件锁和缓存锁，比如reids setnx，这个只限redis2.26版本之前，之后已经完全用set多参数了，因为之前的不支持配置过期时间，要进行绑定

set(key,val,[ex,px],time,[nx,xx])

悲观锁当然是set(key,val,[ex,px],time,[nx])

• EX second ：设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。
• PX millisecond ：设置键的过期时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。
• NX ：只在键不存在时，才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 。
• XX ：只在键已经存在时，才对键进行设置操作。

链表

其实redis list就是一个双向链表，可以从在首和尾操作~