购物车实现逻辑

先谈一下购物车的演变：

        早期的购物车默认全选功能然后进行提交订单，但是狠多用户将购物车当成了收藏夹，只是收藏而不购买，如果每次都是全选的话，用户需要将收藏的商品手动勾选掉，体验比较不友好，所以慢慢演变成购物车会记录用户勾选了哪些商品，在用户下次进入购物车的时候只有上次勾选的商品才会默认被勾选。

        购物车的异常区域，有时候用户将很早的商品加到购物车，时间久了，这件商品可能会被下架或者库存为零，导致用户不能正常下单的时候需要在购物车里面对这部分商品进行提醒，所以也就有了购物车的异常区域。

 

        购物车的另一个功能---降价通知，当用户加入的商品有降价的时候，会进行一个提醒，这需要购物车将当时用户加入商品的价格记录下来，后面用户每次打开购物车的时候对比最新的价格

         购物车之促销功能，常用的范围促销有：满减，满赠，满返等这类促销可以在商详上看到规则，但是在商详页用户基本搞不清楚目前购买的商品是否满足此促销，这个时候就需要在购物车对用户进行提醒，主流的购物车基本都有如下功能。

 

购物车逻辑

设计购物车首先考虑的是，需不需要登录？

在生成订单的时候，必须要登录，但是购物车这个环节，一定需要动态吗？大多数的网站是必须要登录态的。这样在购车环节就可以知道是哪一个用户加入哪一个商品进入的购物车。但是这样的体验并不是很好。如果不需要登录态，这时候会面临一个问题：没有登录态我们就不知道这个商品是哪个用户加入了。这个时候我们就需要一个叫做离线购物车的。他根据设备号来记录哪个商品加入到哪个设备的购物车，在用户加入离线物车之后真正去提交订单的环节再提示用户需要登录态。这是一种比较好的体验。支持离线购物车的话，还会面临一个问题是：离线购物车和在线购车如何合并的问题。在用户登录后我们会去判断用户这个设备下面有没有离线购车的数据。如果有离线购物车的数据，那么我们认为他之前已经离线加入购物车，我们会将离线购物车的数据和在线购物者的数据进行合并。

用户的购车数据一定是会落到数据库里的。购物车的数据库只需要落地用户和商品的关系就可以了，购物车里面会展示商品信息、促销信息、库存信息这些都不需要加到购物车的数据库。类似价格信息促销信息库存信息这些都是需要实时调用相应的系统。比如 某件产品10元，几天后降价到8元，如果把商品的价格落地到购物车数据库的话，那么用户再次打开购物车的时候他是看不到商品的最新的价格信息。

需要跟哪些外部系统进行交互？

商品：从商品系统主要是获取商品的一些基本信息。有商品的主题、商品的文描、商品的上下架状态、以及商品上的一些特殊属性的标志与标记位。有一些体验比较好的电商平台会将购物车中商品已经下架的商品置灰掉提示用户此商品目前不能进行购买。

库存：从库存系统主要是获取商品目前库存数量情况以及是从哪个仓库出货，后面拆单的时候会用到这个信息。购物车系统会进行判断目前商品的库存是否满足用户购买的数量？如果库存已经卖光会将商品制成灰色提示用户商品已经没有库存。

促销：促销是购物车中比较重要的部分，也是最复杂的部分。购物车会将目前用户选中的商品列表传给促销系统。促销系统经过一系列复杂的运算会告诉购车目前这些商品命中了哪些促销？因为一个购物车里面的商品可能有不同商家的，这里还要按照商家的纬度再进行一轮计算。算出每个商家纬度下面有哪些促销？可以说，这里是整个购物车中最复杂的一个环节。各个平台购物车做得好坏的区别主要就体现在这里。

淘宝：需要时刻跟服务器保持同步

例：手机A 添加购物车    手机B  登录后也可以查看

商品列表界面：商品订单号是唯一的  PID

商品详情界面：根据商品的pid 向服务器请求详情界面的数据

点击购物车按钮：发送网络请求，向服务器传送数据（商品id，用户id），服务器会把商品信息存放在一个购物车数据库表里

（如果服务器接受到数据会返回一个成功的返回码，接受到返回码之后在本地做一个缓存，缓存的是购物车的信息，只是展示作用）

跳转到购物车界面：调用接口（URL），服务器会把购物车所有的信息返回回来

支付：

支付宝SDK

1.后台接口

2.用户id

3.购物车的商品id（还有私钥，公钥，这里就不多做介绍了）

       发送给支付宝服务器（支付页面，输入密码页面，支付）

            支付宝服务端会把最终信息返回到自己公司的服务器

                公司的服务器会把成功或者失败的返回码返回给客户端

订单，未完成订单，已完成订单，调接口