关闭

购物车设计

标签: 购物车设计
1861人阅读 评论(0) 收藏 举报
分类:

  对于闪购平台的购物车设计来讲,性能是一个设计目标。

  闪购模式流量一般体现在某个时间段开抢的时候,这就意味着在这个峰值时间会有大量操作购物车的操作,并且对一个热点sku会有大量的存取操作。

  因此设计时,可以将购物车数据及对就sku库存放入缓存中。这样可以提升性能,但会存在丢失数据的危险。这就需要有机制当缓存挂掉时,重启时候,用户购物车在缓存中的数据不会没掉。这个缓存可以用redis,主备结构,主结点负责写,读操作操作,从结点作为冷备。当缓存主结点挂掉时或者更严重的是主结点机子磁盘损坏,这样可以从备份结点恢复数据。

  因为sku库存放入缓存中后,与数据库中的sku库存会有一致性问题。具体来讲会有缓存中sku库存大于数据库中sku库存,这时就会发生超卖。而如果缓存中的sku库存小于数据库中sku库存,这时就会发生少卖。

  超卖的情况在小概率情况下,如果不对加库存操作做幂等性,这个就不可避免,即当由于业务中对某个sku加库存dubbo操作重复发送,导致缓存中的库存被多加了n个。这样在之后这多出的n个库存被用户放入购物车,最终下单时,由于实际数据库库存只有m个,因此导致拥有这个n个多出库存的用户操作是失败的。

  而如果对库存操作做幂等操作,意味着库存增加操作dubbo服务提供方需要保证幂等性。一般的做法是服务调用方生成一个唯一流水号,然后将此流水放入redis缓存,并在调用服务提供方时将此流水号带上。然后加库存服务提供方在接收到此流水号时,先尝试从缓存中delete,如果有数据且清除成功且执行加库存操作。

  由此可见对于库存操作做幂等性来讲,会增加两次对于缓存的操作。

  而如果不做幂等的话,就会发生超卖,当然对于这种情况可以选择告诉用户[您手慢了,此商品已被抢光]。

  而之前网易项目使用不做幂等,最终提供用户的方案,解决超卖问题。

  而对于少卖,即缓存中sku库存小于数据库中库存,这一般会发生在并发时,多个用户抢一件商品sku时,导致库存变成负数,而之后回滚库存操作可能失败。这就导致少卖的情况。对于这种情况一种解决方案是每天凌晨2点同步一次缓存库存与数据库库存。

  对于购物车涉及到的业务接口,基本有以下几个:

 1.addToCart(long userId,long skuId,int count); //加入sku到购物车接品

 2.updateAmount(long userId,skuId,int differ,List<long> selectedSkuIds); //将用户购物车中某个sku的数量增加或减去differ值。此方法更新商品后,会根据selectedSkuIds重新计算一遍购物车价格,返回满足条件的优惠券

 3.deleteCart(long userId,long skuId, List<long> selectedSkuIds); //将某个sku从用户购物车移除。此接品,在清除后台会重复计算selectedSkuIds价格,并会返回选中的sku列表与未选中的sku列表集合。及相应优惠券。

4.getCart(long userId,list<Long> selectedSkuIds); //查询用户购物车。此接品会重新计算selectedSkuIds,并返回选中与未选中sku列表集合,返回相应的满足条件的优惠券信息。

5.doSelectCart(long userId, List<Long> selectedSkuIds); //用户在选中或取消购物车中某个sku项时,调用此方法。会重复计算选中列表,并返回计算后选中与未选中列表,及相应符合条件的优惠券信息。

  

  

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:190063次
    • 积分:3036
    • 等级:
    • 排名:第11521名
    • 原创:130篇
    • 转载:12篇
    • 译文:0篇
    • 评论:15条
    最新评论