电商项目-交易 | Notion Blog

type

status

date

slug

summary

业务场景介绍

正常电商流程

秒杀系统设计

秒杀业务特性

秒杀业务设计

营销商品相关

商品优惠

限时促销

限时抢购

秒杀

商品包邮

订单优惠

满赠

满减

送优惠券

打折扣

vip折扣

订单包邮

全站级别

优惠券

银行促销

支付宝红包

微信砍价

商品限时秒杀

是一款用于常规的营销活动，在限时促销上增加“排除参与活动”、“限制用户购买次数”、“限购种类”、“未付款取消时间”、“活动商品限制库存”等功能，是限时促销促销的增强版，常用于用户拉新、日常的秒杀、日常活动。促销渠道(app，pc，wap，global_app， fresh_app)等

订单满额减

常用促销工具，有满X元减Y元、满X件减Y元，支持叠加满减，订单商品满减金额，支持限制用户参与次数，可设置包括享受优惠的商品分类，商品品牌，商品、促销会员等级，会员标签，促销渠道(app，pc，wap，global_app，fresh_app)，订单可享受满减的支付门槛金额等，如购买全场商品，订单满100元优惠20元

银行促销

常用促销工具，与银行合作在一段时间内每周固定几天进行优惠，可设置用户总参与次数，每天总活动次数，在用户进行支付时进行减免。当前只有光大银行每周二、周六有活动，参与渠道只有pc、h5端，支持排除部分商品，通常是虚拟商品

秒杀技术

单一职责

独立部署，与其他业务分开，互不影响，方便扩容

防止超卖

10个库存，1000人买，如何保证只有10个人买到

限流，熔断，降级

防止程序崩溃，核心就是限制次数，总量，快速失败，降级运行

队列晓峰

下单请求，加入队列

流量错峰

使用各种手段，将流量分担到更多的时间，比如验证码

预热，快速扣减

秒杀读多写少，活动和库存都可以提前预热，把数据放缓存中

下单流程

确认下单流程

检查

检查本地缓存售罄状态
校验是否有权限购买
redis库存是否狗
是否正在队列当中

调用会员服务获取会员信息

产品服务获取产品信息

验证秒杀是否超时

获取用户收货列表

构建商品信息

计算金额

会员积分

下单提交

0——同步下单 1异步下单排队 -1 秒杀失败 1 秒杀成功(返回订单号)

主要流程

检查

产品服务获取产品信息

验证秒杀是否超时

获取会员服务会员信息

会员地址服务

预减库存（异步流程需要，数据库锁不需要）

生成下单商品信息

库存处理

秒杀核心点

价格计算 2.库存处理

商品级别价格优惠计算

订单级别计算优惠

库存问题

高并发下超卖问题

何时扣减库存

下单时扣减

支付时扣减

库存解决

悲观锁操作

其中for update 需要走索引不然会锁表

乐观锁

select 查询还更新库存，其实还需要插入订单和订单详情等数据,不在同1个库根本无法在本地事务来解决

问题：

1.性能问题

无论是悲观锁还是乐观锁对需要对数据库进行上锁，而我们数据库的资源是非常有限的。

2.个数问题

如果库存数量只有1个了，但是现在小明下单这时要买两个，那这条sql语句就有问题了，我们库存只有一个，很明显不够卖了吧。

3架构问题

1000人请求，库存只有10个，实际990个请求没有意义

优化性能问题

秒杀场景大量请求落到数据库，数据库肯定承受不了

预下单

这种情况可以把库存放到redis里面，秒杀下单先从redis里面获取库存数量

预售库存

库存不从数据库里面扣减，而是从redis里面获取，那么redis扣减库存的数量从哪儿获取

初始化（全量）

RedisConfig#afterPropertiesSet

问题

本地缓存是jvm级别，而各自jvm 售罄状态不一样

解决方案

zookeeper

可以用zookeeper的watch机制来实现，给毎个jvm都监听zk的某个就节点，一旦数据有改变之后通知到其他节点上

Redis

利用redis的channel机制实现

异步下单：

秒杀下单

处理订单

实际生产订单

订单超时取消

定时任务问题

11点启动定时任务，毎半个小时扫码数据库一次，我们发现在11:01分下的单并不能30分钟之后失效，而是要到12点也就是定时任务第三次扫码数据库才能让订单失效。
定时扫数据库的话消耗性能也很大，自然效率也会很低。对数据库压力太大。
定时任务的话，集群还需要保证处理的幂等性和分布式问题。这也给系统带来了很多的负担。

创建订单发送延时消息取消订单