前言之前一直有小伙伴私信我问我高并发场景下的订单和库存处理方案我最近也是因为加班的原因比较忙就一直没来得及回复。今天好不容易闲了下来想了想不如写篇文章把这些都列出来的让大家都能学习到说一千道一万都不如满满的干货来的实在干货都下面了介绍前提分布式系统高并发场景商品A只有100库存现在有1000或者更多的用户购买。如何保证库存在高并发的场景下是安全的。预期结果1.不超卖 2.不少卖 3.下单响应快 4.用户体验好下单思路下单时生成订单减库存同时记录库存流水在这里需要先进行库存操作再生成订单数据这样库存修改成功响应超时的特殊情况也可以通过第四步定时校验库存流水来完成最终一致性。支付成功删除库存流水处理完成删除可以让库存流水数据表数据量少易于维护。未支付取消订单还库存删除库存流水定时校验库存流水结合订单状态进行响应处理保证最终一致性退单有单独的库存流水申请退单插入流水退单完成删除流水还库存什么时候进行减库存方案一加购时减库存。方案二确认订单页减库存。方案三提交订单时减库存。方案四支付时减库存。分析方案一在这个时间内加入购物车并不代表用户一定会购买,如果这个时候处理库存会导致想购买的用户显示无货。而不想购买的人一直占着库存。显然这种做法是不可取的。唯品会购物车锁库存但是他们是另一种做法加入购物车后会有一定时效超时会从购物车清除。方案二确认订单页用户有购买欲望但是此时没有提交订单减库存会增加很大的复杂性而且确认订单页的功能是让用户确认信息减库存不合理希望大家对该方案发表一下观点本人暂时只想到这么多。方案三提交订单时减库存。用户选择提交订单说明用户有强烈的购买欲望。生成订单会有一个支付时效例如半个小时。超过半个小时后系统自动取消订单还库存。方案四支付时去减库存。比如只有100个用户可以支付900个用户不能支付。用户体验太差同时生成了900个无效订单数据。所以综上所述选择方案三比较合理。重复下单问题用户点击过快重复提交。网络延时用户重复提交。网络延时高的情况下某些框架自动重试导致重复请求。用户恶意行为。解决办法前端拦截点击后按钮置灰。后台(1redis 防重复点击在下单前获取用户token下单的时候后台系统校验这个 token是否有效导致的问题是一个用户多个设备不能同时下单。//key , 等待获取锁的时间 锁的时间 redis.lock(shop-oms-submit token, 1L, 10L);redis的key用token 设备编号 一个用户多个设备可以同时下单。//key , 等待获取锁的时间 锁的时间 redis.lock(shop-oms-submit token deviceType, 1L, 10L);2防止恶意用户恶意攻击 一分钟调用下单超过50次 加入临时黑名单 10分钟后才可继续操作一小时允许一次跨时段弱校验。使用reids的list结构过期时间一小时/** * param token * return true 可下单 */ public boolean judgeUserToken(String token) { //获取用户下单次数 1分钟50次 String blackUser shop-oms-submit-black- token; if (redis.get(blackUser) ! null) { return false; } String keyCount shop-oms-submit-count- token; Long nowSecond LocalDateTime.now().toEpochSecond(ZoneOffset.of(8)); //每一小时清一次key 过期时间1小时 Long count redis.rpush(keyCount, String.valueOf(nowSecond), 60 * 60); if (count 50) { return true; } //获取第50次的时间 ListString secondString redis.lrange(keyCount, count - 50, count - 49); Long oldSecond Long.valueOf(secondString.get(0)); //now oldSecond 60 用户可下单 boolean result nowSecond.compareTo(oldSecond 60) 0; if (!result) { //触发限制加入黑名单过期时间10分钟 redis.set(blackUser, String.valueOf(nowSecond), 10 * 60); } return result; }如何安全的减库存多用户抢购时如何做到并发安全减库存方案1 数据库操作商品库存采用乐观锁防止超卖sql:update sku_stock set stock stock - num where sku_code and stock - num 0;分析高并发场景下假设库存只有 1件 两个请求同时进来抢购该商品.数据库层面会限制只有一个用户扣库存成功。在并发量不是很大的情况下可以这么做。但是如果是秒杀抢购瞬时流量很高的话压力会都到数据库可能拖垮数据库。方案2利用Redis单线程 强制串行处理/** * 缺点并发不高,同时只能一个用户抢占操作,用户体验不好 * * param orderSkuAo */ public boolean subtractStock(OrderSkuAo orderSkuAo) { String lockKey shop-product-stock-subtract orderSkuAo.getOrderCode(); if(redis.get(lockKey)){ return false; } try { lock.lock(lockKey, 1L, 10L); //处理逻辑 }catch (Exception e){ LogUtil.error(e,e); }finally { lock.unLock(lockKey); } return true; }分析利用Redis 分布式锁,强制控制同一个商品处理请求串行化缺点并发不高 处理比较慢不适合抢购高并发场景。用户体验差但是减轻了数据库的压力。方案3 redis mq mysql 保证库存安全满足高并发处理但相对复杂。/** * 扣库存操作,秒杀的处理方案 * param orderCode * param skuCode * param num * return */ public boolean subtractStock(String orderCode,String skuCode, Integer num) { String key shop-product-stock skuCode; Object value redis.get(key); if (value null) { //前提 提前将商品库存放入缓存 ,如果缓存不存在视为没有该商品 return false; } //先检查 库存是否充足 Integer stock (Integer) value; if (stock num) { LogUtil.info(库存不足); return false; } //不可在这里直接操作数据库减库存否则导致数据不安全 //因为此时可能有其他线程已经将redis的key修改了 //redis 减少库存然后才能操作数据库 Long newStock redis.increment(key, -num.longValue()); //库存充足 if (newStock 0) { LogUtil.info(成功抢购); //TODO 真正扣库存操作 可用MQ 进行 redis 和 mysql 的数据同步减少响应时间 } else { //库存不足需要增加刚刚减去的库存 redis.increment(key, num.longValue()); LogUtil.info(库存不足,并发); return false; } return true; }分析利用Redis increment 的原子操作保证库存安全利用MQ保证高并发响应时间。但是事需要把库存的信息保存到Redis并保证Redis 和 Mysql 数据同步。缺点是redis宕机后不能下单。increment 是个原子操作。综上所述方案三满足秒杀、高并发抢购等热点商品的处理真正减扣库存和下单可以异步执行。在并发情况不高平常商品或者正常购买流程可以采用方案一数据库乐观锁的处理或者对方案三进行重新设计设计成支持单订单多商品即可但复杂性提高同时redis和mysql数据一致性需要定期检查。订单时效问题超过订单有效时间订单取消可利用MQ或其他方案回退库存。设置定时检查Spring task 的cron表达式定时任务MQ消息延时队列订单与库存涉及的几个重要知识TCC 模型Try/Confirm/Cancel不使用强一致性的处理方案最终一致性即可下单减库存成功后生成订单数据如果此时由于超时导致库存扣成功但是返回失败则通过定时任务检查进行数据恢复如果本条数据执行次数超过某个限制人工回滚。还库存也是这样。幂等性分布式高并发系统如何保证对外接口的幂等性记录库存流水是实现库存回滚支持幂等性的一个解决方案订单号skuCode为唯一主键该表修改频次高少建索引乐观锁where stock num0消息队列实现分布式事务 和 异步处理(提升响应速度)redis限制请求频次高并发解决方案提升响应速度分布式锁防止重复提交防止高并发强制串行化分布式事务最终一致性同步处理(Dubbo)/异步处理MQ修改 补偿机制