购物车设计

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

  闪购模式流量一般体现在某个时间段开抢的时候，这就意味着在这个峰值时间会有大量操作购物车的操作，并且对一个热点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项时，调用此方法。会重复计算选中列表，并返回计算后选中与未选中列表，及相应符合条件的优惠券信息。