按关键词阅读：
这就是 “生产者-消费者” 模式 。
【实战分布式之电商高并发秒杀方案设计】“生产者-消费者”模式 在进程内 ， 常常通过 阻塞队列 或者 “等待-通知” 等机制实现 ， 在服务之间则往往通过消息队列实现 ， 这也是本次实战所采用的技术实现手段 。 在后续的实战中 ， 我将通过RocketMQ消息队列 ， 对秒杀下单进行解耦 ， 实现削峰填谷、提高系统吞吐量的目的 。 此处就不多赘述 ， 到编码部分再详细展开 。
秒杀业务流程图解
文章插图详细细节在上文中的描述部分已经做过阐述 ， 读者朋友可以配合一起看 ， 这里只对图示流程进行简略总结：
1：用户访问秒杀网关seckill-gateway-service ， 对感兴趣的商品发起秒杀操作 。 特别的 ， 对于商品信息 ， 在系统初始化的时候已经加载到seckill-gateway-service 。 在进行前置库存校验的时候 ， 依据缓存已经做了一次用户下单流量的过滤 。
2：网关对秒杀订单进行充分的预校验之后 ， 将秒杀下单消息投递到RocketMQ中 ， 同步向用户返回排队中
3：秒杀订单平台seckill-order-service订阅秒杀下单消息 ， 对消息进行幂等处理 ， 并对商品库存进行真实校验后 ， 进行真实下单操作
文章插图本流程为用户通过秒杀网关seckill-gateway-service提供的查单接口对自己下的秒杀订单进行查询跟踪 。
总结由于重点在于秒杀的核心场景 ， 因此上文还是存在有待优化的细节 。 提出以下建议供大家参考：
1:推荐采用分布式减库存策略：如：使用Redis的decr进行原子减库存 。
2:预热库存时 ， 将库存适当调大 ， 防止恶意刷库存导致正常用户不能进行秒杀下单请求 。 这里要注意只调整缓存中的库存 ， 不能调整商品库中的真实库存 ， 否则会出现 “超卖” 从而导致损失 。
3:秒杀接口需要做防刷处理 ， 可以在前端页面通过倒计时方式定时开放接口；通过增加验证码减少下单频率；通过增加下单前收货地址校验、实名认证等方式对僵尸用户进行拦截 。
版权声明：本文为博主原创文章 ， 遵循 CC 4.0 BY-SA 版权协议 ， 转载请附上原文出处链接和本声明 。
本文链接：
稿源：(未知)
【傻大方】网址：http://www.shadafang.com/c/111J304212020.html
标题：实战分布式之电商高并发秒杀方案设计( 二 )