Springboot实战——黑马点评之互斥锁
Springboot黑马点评(3)——优惠券秒杀【还剩Redisson的最后两节没测试 后续补上】
另外，后期单独整理一份关于分布式锁笔记
1 优惠券秒杀实现
1.1 用户-优惠券订单计划
1.1.1 全局ID生成器
使用数据库自增ID作为订单ID存在题目
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240826151049789-1199655273.png
1.1.2 考虑全局唯一ID生成逻辑
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240826151258209-1682410329.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240826151555338-900300974.png
[*]时间戳(Long类型 31bit):采取将当前时间与标定时间(自设定一个汗青时间)相减,将其秒数相减，采用纪元秒数方法（不可时间节点之间直接相减）
long timeInSeconds = localDateTime.toEpochSecond(ZoneOffset.UTC);
当我们把当地日期时间localDateTime如2019-11-15T13:15:30转换为纪元秒时，那么效果将是1970-01-01T00:00:00Z到2019-11-15T13:15:30的时间差距，单元为秒，这也是我们平时说的时间戳
[*]序列号(直接调用StringRedisTemplate中针对value值的自增长 即opsValueFor().increment())
对于该部分id的生成，对应的key需要特别考虑：
1）考虑到不同业务对应的下单序列值 要拼接keyPrefix作为业务区分
2）考虑到使用类似key对该业务的id无限制地自增，将超出Redis中对于键值的最大数量限制，且不同时间批次下单的用户没有区分度，会造成冗余，使用用户下单的当天日期作为key拼接进去，便于统计当日下单订单数
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240826161142002-929811325.png
[*]拼接得到总id
总id值 = 时间戳值左移32位（空余出序列号的位数）再和序列号作 “或” 运算
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240826161559048-1310970404.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240826164447479-1571689297.png
1.2 简单的秒杀券下单逻辑
数据库表中维护普通优惠券voucher以及秒杀优惠券killVoucher，秒杀优惠券除了具备普通优惠券的一般属性外，还具备库存、秒杀开始时间、秒杀结束时间。
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827104540549-1277055678.png
1.2.1 用户下单秒杀券的逻辑：
（秒杀的前提是查验该用户是否登录状态，通用拦截器首先在该接口的最前端取到哀求头的用户信息，添加到该哀求对应的threadlocal中，同一刷新所有哀求登任命户/非登任命户的ttl，再经过前置登录拦截器查验threadlocal中用户是否为空即验证某些必须登录才气访问的接口）
鉴权后，接口首先检查当前时间是否在秒杀时间段内，其次检查该秒杀券的库存是否为0，两层逻辑检查完之后，即可扣减该秒杀券的库存-1
创建用户-秒杀券的订单记录
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827104609173-82176770.png
1.2.2 超卖题目
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827105625999-970513881.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827105656732-871181901.png
聚合报告显示并没有让100个线程生成100个订单，即成功率100/200
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827105828563-211878835.png
即 多线程并发安全题目
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827110447544-1822867208.png
1.2.3 超卖题目的解决方案
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827111103174-950925232.png
[*]乐观锁：
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827111740698-848475611.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827112107333-1085231652.png
【乐观锁存在的弊端】
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827112954560-1217865389.png
乐观锁轻易在短时间内拦阻多线程争取足够库存 导致成功率极低
以是 改变束缚条件：stock>0 提高并发的成功率
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827145325598-1924727768.png
（还有分段加锁方案）
1.3 一人一单逻辑实现
在创建订单时查询该用户id和该优惠券id的订单是否存在，需要保证类似优惠券 一人只能下一单，如果存在则扣除库存失败且不创建该订单。
但是该逻辑存在线程并发的题目，当同一用户的多线程并发访问时，将同时查询到订单不存在而创建新的订单，还是会存在一人多单。
1.3.1 解决一人多单题目
[*]单机模式下解决方法：灰心锁
（由于该业务是在查询数据而非修改数据，无法作类似乐观锁似的修改检查）
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827154855065-2039337587.png
由于Transaction注解(事务注解)要处理的表单数据处理是在该代码块结束的时候提交事务，以是要保证加锁在提交事务之后释放锁，保证该事务处理已完成。（难点）
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827155636148-459186085.png
[*]集群模式下解决方法：分布式锁
但synchronized()互斥锁 在多实例分布式部署到多台机器上 形成负载均衡的集群时存在题目
模拟多机部署情况
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827163547954-1226500872.png
调用nginx(8080)ip来访问模拟集群，在nginx端下同一用户哀求该集群，由于负载均衡，哀求会在集群中平均传到各个服务实例上，然而互斥锁只在同一实例中生效
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827165634795-227090430.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827165712306-1122490196.png
(1) 集群模式下采用synchronized()存在的题目
不加锁的正常查询创建订单逻辑：
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827165756299-868613387.png
加锁后
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827165824643-583510458.png
加锁存在于集群模式中：
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240827170043631-1931713956.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240829145641339-1449853719.png
(2) 考虑使用“分布式”锁
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240829145826364-1410527897.png
引出“分布式锁”：在分布式系统或者集群模式下，多线程可见且互斥的锁
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240829150652600-1529747339.png
(3) Redis实现“互斥”锁
对于Redis实现互斥锁的题目，如果系统中的某个机器或微服务宕机了，其申请的setnx键值对将持续保留在系统中（即 持续加锁中），其他服务无法实现哀求，将出现死锁的局面。
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240829151324680-1503748717.png
实现Redis分布式锁低级版本
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240829151456031-1873046632.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240830101824525-1542859546.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240830110502496-722810057.png
低级版本存在的题目：
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240830163328962-2078300536.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240830170130695-503840547.png
改造分布式锁低级版本
之前用的是 线程id（自动递增）
集群模式下 每个jvm都维护一列递增的线程id 轻易存在重复的线程标识
因此 借助UUID+线程ID来制止重复
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240830170319102-1294840610.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240830171716199-594711990.png
模拟当其一使命未结束的线程的key过期时，该并发使命解锁，其他线程获得锁之后，该使命尝试解锁时，核对了键值对中包含的线程信息，发现与自己的线程标识并不匹配，制止了误删其他线程锁的情况
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240830172939800-2008125699.png
判断完 释放前阻塞
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240830173640514-156652154.png
Redis的事务和mysql的事务Transaction不同：
编写lua脚本
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240831144955941-1503527268.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240831145530856-1435213347.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240831150721523-1531408979.png
基于Redis实现的弊端
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240831155305928-266737258.png
[*]可重入锁
在Redis实现基础上的改造方法：
改变之前字符串存储的方式，value存入类型改为HashMap，用来存储该线程方法嵌套加锁放锁时，每一层嵌套作各自的标记。
每一层嵌套加锁时，判断该key是否存在，进一步判断key内部存储的线程标识是否嵌套调用该方法的线程标识，修改其嵌套加锁标记+1
每一层嵌套放锁时，判断该key存储的线程标识是否嵌套调用该方法的线程标识，修改其嵌套加锁标记-1，若修改效果为0则意味着该嵌套是最后一层，放锁即结束线程所有的使命，这时便可删除该键值了。
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240831164040103-1556895671.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240831170951319-1156079683.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240831171206574-723662414.png
https://img2024.cnblogs.com/blog/3420577/202408/3420577-20240831171317777-719603407.png
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]