电商系统-业务中台

业务中台

订单中心

1）异步化

场景：大促期间新增许多需要获取订单状态的服务，比如应对双11而临时增加的数据中台订单大屏展示等
解决：异步化，并对消息队列调优，多队列分流
问题：注意异步化引发的乱序问题，一是传输阶段，二是消费阶段

rabbitmq传输：队列级别顺序保障，单消费者消费一个队列可以严格保障顺序性，需要扩充队列数提
升性能

kafka传输：分区级别顺序保障，只能保障投放和传输阶段的顺序性

consumer：1对1消费存在性能问题，接收消息后对key做二次分发，放入多个内存队列，开启多线程
消费

2）过期订单

双11抢单是最常见的场景，抢单不支付会占据大批量资源，如商品库存。如何取消过期订单是架构师必须面对的问题。主要有以下几种方案：

扫表实现

原理：通过定时任务轮询扫描订单表，超时的批量修改状态
优点：实现非常简单
缺点:

• 大量数据集，对服务器内存消耗大。
• 数据库频繁查询，订单量大的情况下，IO是瓶颈。
• 存在延迟，间隔短则耗资源，间隔长则时效性差，两者是一对矛盾。
• 不易控制，随着定时业务的增多和细化，每个业务都要对订单重复扫描，引发查询浪费

java延迟队列实现

原理：通过DelayQueue，每下一单，放入一个订单元素并实现getDelay()方法，方法返回该元素距离失效还剩余的时间，当<=0时元素就失效，就可以从队列中获取到。启用线程池对数据监听，一旦捕获失效订单，取出之后，调用取消逻辑进行处理。

优点：基于jvm内存，效率高，任务触发时间延迟低。
缺点：

• 存在jvm内存中，服务器重启后，数据全部丢失。
• 依赖代码硬编码，集群扩展麻烦
• 依赖jvm内存，如果订单量过大，无界队列内容扩充，容易出现OOM
• 需要代码实现，多线程处理业务，复杂度较高
• 多线程处理时，数据频繁触发等待和唤醒，多了无谓的竞争

消息队列实现

原理：设置两个队列，每下一单放一条进延迟队列，设定过期时间。消息一旦过期，获取并放入工作队列，由consumer获取，唤起超时处理逻辑

如果采用的是RabbitMQ，其本身没有直接支持延迟队列功能，可以针对Queue和Message设置 x-
message-ttl，用消息的生存时间，和死信队列来实现，具体有两种手段， A: 通过队列属性设置，队列
中所有消息都有相同的过期时间，粗粒度，编码简单 B: 对消息进行单独设置，每条消息TTL可以不同，细粒度，但编码稍微复杂。

优点：

• 可以随时在队列移除，实现实时取消订单，及时恢复订单占用的资源（如商品）
• 消息存储在mq中，不占用应用服务器资源
• 异步化处理，一旦处理能力不足，consumer集群可以很方便的扩容

缺点：

• 可能会导致消息大量堆积
• mq服务器一旦故障重启后，持久化的队列过期时间会被重新计算，造成精度不足
• 死信消息可能会导致监控系统频繁预警

redis实现

原理：利用redis的notify-keyspace-events，该选项默认为空，改为Ex开启过期事件，配置消息监听。每下一单在redis中放置一个key（如订单id），并设置过期时间。

优点：

• 消息都存储在Redis中，不占用应用内存
• 外部redis存储，应用down机不会丢失数据
• 做集群扩展相当方便
• 依赖redis超时，时间准确度高

缺点：订单量大时，每一单都要存储redis内存，需要大量redis服务器资源

被动取消

原理：在每次用户查询订单的时候，判断订单时间，超时则同时完成订单取消业务。
优点：

• 实现极其简单
• 不会有额外的性能付出
• 不依赖任何外部中间件，只是应用逻辑的处理

缺点：延迟度不可控，如果用户一直没触发查询，则订单一直挂着，既不支付也未取消，库存也就被占着

支付中心

支付交互流程

1）重复支付

原因：在第一步发起的时候，用户进入支付方式选择页。选第一个支付方式并支付完后因为通知延迟，以为支付失败。在支付又选了第二种，再次支付。

应对方案：

• 程序屏蔽，前端js触发按钮置灰或者遮罩提示（支付成功？遇到问题？），或者在支付方式选择页直接跳转。
• 后端处理，发现不同通道下的支付成功回调，抛消息队列或记录日志。

数据修复：
首先查支付日志，确认针对同一笔订单收到了不同支付渠道的回调。
其次，在支付平台管理后端可以查到入账记录，人工介入。
最后对账阶段会发现对方多帐，我方补单时出现重复订单。

问题处理：调取退款接口或者在支付渠道的管理后台操作退款（一定要多次确认无误）。

2）异常订单

支付但未开单

场景：用户明明支付成功，但未开通订单

问题分析：
一般支付渠道会间隔性多次回调开单链接，如果支付未开单，银行未回调的可能性比较小，着重排查开单接口是否可用。如果可用追查日志是否出现异常记录。

应对措施：

• 对账阶段可以查漏，程序自动完成补单，但是处理相对延迟，取决于支付渠道的对账文件下发周期
• 人工补单，人工查询支付渠道后台数据，确认已支付的情况下，介入补单流程人工处理

未支付但已开单

场景：用户未支付，或者财务中心未收到这笔款项，订单状态已开通。这种就问题比较严重了
应对措施：首先排除人为操作因素。其次排查系统是否存在漏洞或者级联开单的情况

3）回调延迟

场景：用户是期望支付完成的同时立马看到结果。但是中间多层远程的调用，可能发生订单状态更新延迟问题。

解决：主动查询。在用户查看订单的时候，如果是类似“支付中”的中间态时，触发远程订单状态查询接口。

4）支付路由

背景：
保障支付可用性及支付分流，支付中心对接多家渠道

方案：

• 支付中心对接多个支付渠道，支付宝，微信，各银行或第三方支付供应商
• 对不同用户，进入支付方式选择页时，做支付分流
• 做好监控统计，一旦某个支付渠道不可用或者延迟较大，切掉，下线，或者降权

营销中心

1）概述

大促和活动不分家，一般营销中心所面对的主要是促销策略、优惠方式等业务上的架构问题。

从促销活动的范围来看，分为单品促销活动、套装促销活动、店铺促销活动，平台促销活动。
从促销类型来看，分为满减、折扣、赠品等。

业务复杂度高，一般遵循 “同类营销仅可选其一，不同类营销可叠加” 的规则。同类叠加意义不大且会造成系统复杂度上升，引发用户困惑。

2）前端设计

用户体验上的设计，比如购物车里商品的排序，按商铺分门别类。优惠总价格及时调整。这些依赖于前端的ui设计和交互体验。

3）赠品设计

(SPU , SKU 基础概念)
赠品有两种设计方案，一种是不做单独的SKU，只有一个空的描述，设计简单，缺点是没有商品详情
页，无法给用户直观的查看和估值。

另一种是单独做SKU，赠品也会作为一个商品存在，与主商品关联，下单的时候将会自动加到商品列
表，价格降为0。这种更为常见。整个商品有完善的详情页，用户可以直接看到价格甚至单独下单购
买。

4）排他与优先级

检查同类别促销，将最大优惠力度的规则应用到订单，并且满足排他性，同类只享受其一。比如满10减3，满20减5，那么用户购买大于20时，只减5即可。
不同类别不做排斥，如购物车整体满减后，不影响单个商品的折扣。在记录数据时，优惠要细化到每个单独的订单明细上。退款也做到明细级别的单独退。

5）价格分摊

满减或平台券等优惠，在多个商品下单时，涉及到金额的分摊。即 优惠总额度/购物车总额 ，得到比例后再按比例均分到每个商品。只有分摊才能在发生部分退款时退回真实金额。
但是这会涉及到一个精度问题。举例如下：满99减9活动，假设用户购买了 30+40+50=120，3件商品
应付111元。按比例折算的话，9/99取4位小数是0.9090，那么分摊后为
30x0.9090+40x0.9090+50x0.9090=109.08与实际支付金额出现偏差。这会造成财务无法平账。
解决方案：记账时在订单明细记录，将误差 111-109.08=1.92计入金额最大的明细，也就是50元商品
上。那么最终记账为：30x0.9090 + 40x0.9090 +（50*0.909+1.92）= 111

6）退单处理

退单后要同时恢复用户的权益，比如优惠券的再次使用，限购次数等。确保用户体验。

商品中心

1）限时商品的下架控制

这个和超时订单设计方案类似

2）库存管理

普通商品可以直接借助数据库锁实现，一般分乐观锁和悲观锁两种方案，如果采用悲观锁（如select语
句带forupdate），会带来很大的性能阻塞，所以更多的采用乐观锁设计。

乐观锁就是在最后执行库存扣减操作时，将事务开始前获取的库存数量带入到SQL语句中作为更新的
where条件，如果数量相等，则该条更新库存的语句成功执行返回update条数为1；如果不相等，则表
示该商品的库存信息已经被其他事务修改，需要放弃该条update的执行，采用重试处理。

库存秒杀商品因为大批量的访问在一瞬间涌入，数据库扛不住。可以采用 redis缓存做decr处理，正常
下单后，再使用mq异步更新到db。（秒杀不超卖课题的库存控制）