3.4 高并发抢购数据一致性解决方案

一：优惠券抢券的情况
比如有：15000请求 10000优惠券
1.如果在单体架构上这种情况就有可能是无锁的状态 - 发生超发
解决方案加锁：synchronize
2.如果是在分布式架构的业务加锁就锁不住了
解决方案：redis分布式锁
---------------数据库锁的方案：
悲观锁：（每次读取数据的时候都默认其他线程会更改数据，因此需要进行加锁操作，当其他线程想要访问数据时，都需要阻塞挂起）
实现：
1.Java 里面的同步 synchronized 关键字的实现
2. 表锁 - 锁表
3. 行锁 - 锁行
共享锁：（读锁）A事务对某一行添加了共享锁，其他事务就不能再对该行添加排它锁了，但是任然可以添加共享锁
使用排它锁（方案）：（写锁 ）A事务对某一行添加了排他锁，其他事务就不能再对该行添加排它锁和共享锁了。
注意：insert，update，delete 自带排它锁，select 没有锁
select 加排它锁的语法：select … fro update
乐观锁：（乐观锁假设数据一般情况不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测）
（方案 1）：数据库中带一个版本号，每次操作时，判断版本是否变化。如果变化说明有其他线程操作了该数据。如果没有变化就结束本次操作，并且修改版本号。version 实现版本
（方案 2）：时间戳
比较适合读多写少的业务
3.Redis 的Lua脚步