悲观锁 vs 乐观锁 vs Redis

企业面对高并发场景采用的方案.

比如 产品抢购高并发时的超发现象.

 

1 悲观锁
悲观锁 需要数据库本身提供支持(Oracle和MySQL都是支持的).
实现细节:
当前 数据库事务 读取到产品后, 就将目标数据直接锁定(select ... for update), 不允许别的线程进行读写操作, 知道 当前数据库事务完成自动释放锁.
悲观锁中, 资源只能被一个事务锁持有, 所以也被称为 独占锁 or 排它锁.

悲观锁的优点是实现简单好理解, 缺点是过多的等待和响应的事务切换导致性能问题.
为提高运行效率, 可以采用 乐观锁.

 

2 乐观锁
乐观锁 是一种 不使用数据库锁 和 不阻塞线程并发 的方案.
著名的 CAS(Compare and Swap): 线程在修改目标数据时, 会将目标数据的当前状态和旧状态进行比较(Compare), 如果状态一直, 就可以认为 数据木有被修改过, 否则就认为数据已经不同步了, 当前计算作废, 不做任何修改操作(回滚).
CAS方案却会引发 ABA问题, 就是共享值回退导致数据的不一致问题, 有点像脏读.
采用 带版本号(version)的乐观锁方案, 再配合CAS, 就可以解决 ABA问题了.
实现细节:
给产品表添加 version字段, 只要操作过程中有修改产品状态(比如减少库存), 无论是业务正常 回退 还是异常, 版本号只增不减. 即
update t_product set stock=stock-#{quantity}, version=version+1
where id=#{id} and version=#{version}
乐观锁没有独占资源和阻塞任何线程, 所以乐观锁也称为 非独占锁 or 无阻塞锁.
在实际使用乐观锁时, 会发现线程的业务失败率会很高, 针对这点可以对 乐观锁 引入重入机制. 也就是一旦业务失败, 不是立即结束请求, 而是重新做一次乐观锁流程, 可限制重入时间or重入次数.

乐观锁优点是不独占不阻塞, 缺点是实现相对复杂.

 

3 Redis
有些企业已经开始使用 NoSQL 来处理高并发问题, 代表就是 Redis(内存数据库).
首先, Redis 是内存数据库, 所以性能是没的说的. 其次, Redis Lua 在 Redis 的执行中是具备原子性的, 所以不会发送超发现象.
两步设计:
1) 使用 Redis 响应高并发用户请求
即用 Redis 代替原来的磁盘数据库 读写, 保证性能和数据一致性.
2) 定时持久化 Redis 数据
内存数据存储是不稳定的, 我们需要及时将保存在内存中的数据持久化到磁盘数据库中.

使用 Redis 效率要比悲观锁和乐观锁机制快上数倍, 但是千万记住 Redis 的存储基于内存, 如果操作不当容易引发数据的丢失, 所以使用 Redis 时建议使用独立的 Redis 服务器, 而且要做好备份和容灾等手段.

 

参考:
https://www.cnblogs.com/zhiqian-ali/p/6200874.html
<<深入浅出 Spring Boot 2.x>> 杨开振