购物车业务问题

购物车业务问题

记录一些在社招中被问到的购物车方面业务问题。


购物车表结构

  1. 临时车表、公共库表略;

  2. 车1库表:【车表】、【店铺信息表】、【商品行表】、【规格信息表】、【配送信息表】

    【行表】上记录了:【车ID】、【店铺 ID】、【行号 ID】、【商品信息 & 规格】。
    车1、车2皆是如此。

  3. 车2库表:车表、店铺信息表、行表、规格信息表、配送信息表、【邮寄信息表】、【卡表】、【券表】、【云钻表】、【发票信息表】、【促销类型表】

    车1、车2都有的表:【车、店铺、行、规格、配送信息】。
    由于到车2的用户都已经有了购买意向,所以车2对比车1多了与购买相关的【卡、券、云钻、发票、促销】表,以及和物流相关的【邮寄信息】表。


车1加入后,车1展示如何排序(保证最新加入的店铺和商品展示在最上面,并且去重)?

  • 车1加入时,会将【创建时间】写入【行表】中;
  • 车1展示时,根据【车号】去查【行表】,然后根据【创建时间】进行SQL排序,就可以保证最后加入的商品行在最上面;
  • 查询得到的商品行,会判断【店铺ID】和【商品ID】是否都相同,进行同品合并

提交订单时如何通过事务保证数据一致性?

  • 通过2PC协议 —— 提交订单时需要锁定下游的库存、促销等系统的资源,如果所有系统执行成功,才能提交事务,否则回滚事务
  • 也可以通过3PC协议防止阻塞 —— 一阶段超时默认失败,二阶段超时默认成功

购物车的缓存持久化与同步策略

Master不做任何持久化工作(RDB/AOF),Slave开启AOF备份策略,每秒同步一次。


购物车与其他系统间的通信方式

通过类似于DubboRPC框架序列化/反序列化进行通信,没有采用Service Mesh


异地多活中,万一一笔数据在两边都修改了,如何解决冲突?

  1. 首先通过全局定义的规则避免数据冲突,让每笔数据都有属于自己的归属机房,两个机房同时修改一笔数据的情况很少出现。
  2. 有时候冲突不可避免(比如:在A机房修改了数据,还没有同步到B机房,然后A机房宕机切换到了B机房),则需要引入冲突处理机制:①为每笔数据打上变更时间戳,发生冲突时最后修改的会胜出;②如果时间戳不满足需要,则为业务方提供原始数据和最新数据,由业务逻辑决定哪个数据是最终正确的数据;③不要对数据进行合并,合并的问题更多

    2020-2-27 字节跳动·一面 被问到。

-------------本文结束感谢您的阅读-------------

本文标题:购物车业务问题

文章作者:DragonBaby308

发布时间:2019年11月05日 - 23:00

最后更新:2020年02月27日 - 20:36

原始链接:http://www.dragonbaby308.com/shoppingcart/

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

急事可以使用右下角的DaoVoice,我绑定了微信会立即回复,否则还是推荐Valine留言喔( ఠൠఠ )ノ
0%