秒杀场景下订单中心的架构设计

服务划分

定州ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联建站的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:18980820575(备注:SSL证书合作)期待与您的合作!

服务说明

我不希望整个订单中心就是一个巨大的单体服务,也不希望是太细的微服务,我希望订单中心是合理的“中服务”的组合。

可针对不同场景对服务进行扩容,比如订单搜索请求量比较大,就适当增加订单搜索服务的实例数量;消费速度慢,可针对订单消费者服务进行优化,调整服务实例数量。

上面划分的每一个服务都是独立部署运行的服务。

服务

说明

order-core(订单核心服务)

负责订单的业务处理,直接和 DB 交互

order-search(订单搜索服务)

负责订单索引的维护和搜索,直接和 ES 交互

order-job(订单调度服务)

订单超时取消等调度任务

order-consumer(订单消费者服务)

消费订单相关消息,如下单消息、订单索引更新消息

order-manage(订单管理后台系统)

订单管理后台,数据来源于 ES 和从库

应用架构图

服务调用关系图

提交订单服务调用关系:

  • 链路 1.1 ~ 1.3 提交订单
  • 链路 2.1 ~ 2.4 消费下单消息(下单业务处理)
  • 链路 3.1 ~ 3.2 查询下单结果
  • BFF(小程序的后端,负责聚合和适配)

后台服务调用关系:

  • 后台连接独立的专有读库,与前台隔离,不能因为后台的查询影响前台的操作
  • 后台的订单查询可以调用搜索服务和读库来完成
  • 后台的增删改操作调用 order-core(订单核心服务)进行操作,不能直接操作数据库

订单搜索或查看订单详情服务调用关系:

  • 订单列表或者搜索订单可以调 order-search(订单搜索服务)来完成
  • 在订单列表店家订单明细,可以根据订单号由 order-core(订单核心服务)查询从库来完成

订单调度服务调用关系:

  • 订单调度服务查询专有的读库
  • 写操作调用 order-core(订单核心服务)查询来完成

下单流程

下单请求通过 MQ 异步化处理,下单处理结果存入 Redis,前端轮询下单结果。

步骤说明

步骤 1:提交订单说明

  • order-core(订单核心服务)提供提交订单接口(/order/submit)
  • 这个接口接收订单相关的参数,如商品 id、价格、数量等
  • 接收到请求后,做好基本参数校验
  • 生成唯一的订单号,组装基本的订单信息
  • 将订单号和订单创建中状态存入 Redis
  • 发送 MQ,然后将订单号返回给前端

步骤 2:消费下单请求说明

  • order-consumer(订单消费者服务)获取到下单请求消息后,调库存中心接口进行库存预占
  • 如果库存不足,预占失败,则将订单创建失败状态和失败信息更新到 Redis,流程终止
  • 如果库存充足,预占成功,则将订单创建成功状态更新到 Redis
  • 调用 order-core(订单核心服务)保存订单信息到数据库,调用 order-search(订单搜索服务)对订单进行索引
  • 发送创建订单结果消息,库存中心根据创单结果消息进行库存扣减或者释放

步骤 3:根据订单号查询轮询下单结果说明

  • order-core(订单核心服务)提供根据订单号查询订单是否已创建接口(/order/is-created)
  • 该接口返回报文应包括,订单号、订单创建状态(创建中,创建成功,创建失败)、创建失败原因
  • 前端定时轮询该接口,查询订单是否创建成功,轮询频率可根据实际情况进行调整,比如 20ms 一次
  • 轮询到订单创建成功,可直接唤起支付,失败则直接提示失败信息

核心表分库

  • 以订单主表和订单明细表为例进行分库设计,假如按 32 个库进行分库。
  • 订单主表和订单明细表通过订单号进行关联。
  • 分库要求:

某个用户的所有订单在同一个库,避免跨库查询(可根据用户 id——buyerId 定位到分库编号)

某个商家的所有订单在同一个库,避免跨库查询(可根据商家 id——sellerId 定位到分库编号)

可以根据订单号查询(可根据订单号定位到分库编号)

  • 按照以上分库要求,做出以下分库设计

订单主表进行冗余,订单主表分成用户订单主表(buyer_order)和商家订单主表(seller_order)

用户订单主表(buyer_order)按照 buyerId % 32 进行分库

商家订单主表(seller_order)按照 sellerId %32 进行分库

订单号末位带上分库编号,分库编号为 buyerId % 32

订单明细表(order_detail)按照订单号进行分库,确保同一个订单的明细在同一个库

用户订单主表(buyer_order)同步写入,因为订单是由用户发起的,需要保证实时性。

商家订单主表(seller_order)建议保证最终一致性即可,可根据实际业务选择同步双写或者通过 MQ 异步写入

  • 分库设计图:

库存扣减方案

  • 采用预占库存方案:创建订单时预占库存
  • 库存不足,预占失败,下单失败
  • 库存足够,预占成功,创建订单
  • 订单创建成功,扣减库存;创建订单失败或者取消订单,释放库存

库存扣减序列图

库存设置到 redis 中,已 skuId 为 key,变化的数量为值,如:

  • 将 skuId=10086 的库存值初始化为 100,redis.incrby(10086, 100)
  • 库存初始化后,只能对库存进行加减操作,不允许做覆盖操作

Redis 如何与数据库中的库存保持一致:

  • Redis 和数据库的库存保持最终一致性
  • 库存被预占时,生成库存预占流水,关键字段有,订单号、skuId、预占数量、流水状态有(预占中、已扣减、已释放),预占超时时间,同时可以在 Redis 或者数据库中维护一个 skuId 对应的总预占数量字段,总预占数量 + 预占数量
  • 订单中心发送库存扣减消息,库存中心消费消息时更新库存流水状态为已扣减,总预占数量 - 预占数量
  • 订单中心发送库存释放消息,库存中心消费消息时更新库存流水状态为已释放,返还库存到 Redis,总预占数量 - 预占数量
/**
* 预占库存 伪代码
* @param orderNo 订单号
* @param skuId sku 标识
* @param quantity 预占数量
*/
boolean preOccupy(String orderNo, String skuId, int quantity) {
boolean isPreOccupySuccess = false;
int value = redis.decrby(skuId, quantity);
if (value >= 0) {
// 库存充足
// 生成库存预占流水记录
//(关键字段:orderNo,skuId,quantity,state(0-预占中;1-已扣减;2-已释放),timeout(超时时间)
isPreOccupySuccess = true;
} else {
// 库存不足,返还刚才预占的库存
redis.incrby(skuId, qunatity);
}
return isPreOccupySuccess;
}

数据库的库存数量禁止覆盖更新!

数据库的库存数量禁止覆盖更新!
扣减库存伪 SQL:update stock set stock_num = stock_num - 变化的值 where sku_id = 10086

关于释放库存

对一些释放异常的情况,可由库存中心调度服务,找出库存预占流水状态为预占中且预占超时的记录,根据订单号向订单中心确认该订单号的库存是已扣减还是已释放,再进行相应业务处理。

其他

除了以上大的方面设计,分布式事务、幂等、补偿、压测……这些点是大家在设计系统时都需要考虑的,不在本文讨论范围。

新闻标题:秒杀场景下订单中心的架构设计
文章来源:http://www.shufengxianlan.com/qtweb/news16/218116.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联