@toc
电商系统分类
一般电商项目的架构图
介绍
面试官你好，我最近参与的项目是青鸟微商城系统，这个项目是我们学校创新学院孵化的项目之一，我从去年开始到现在一直参与这个微商城系统的开发我们研发的这个微商城系统是B/C模式的电商系统，将来会和学校的超市水果店等等进行对接。目前已经完成了百分之七十左右。我来给您介绍一下这个微商城系统的架构，
微商城系统一共分为4个子系统，前两个系统是商城前后台管理项目，后台项目用的是spring boot，springMVC和mybatis。权限验证用的是shiro。前台项目用的是elementUI和VUE。后两个系统就是移动端的前台和后台，移动端后台所用的技术和管理系统后台相同。移动端前台我们做成了微信小程序，在这个系统中我负责了移动支付、订单管理、商品管理这三个模块儿的开发。其中最有挑战的就是移动支付模块，因为跟钱有关，所以要保证绝对不能出错，虽然说微信支付接口调用的原理并不复杂，但是微信支付平台也会偶尔出现一些技术上的问题，
- 比如说银行已经完成扣款，用户也收到了扣款短信，但是微信平台却显示支付失败。刚开始我们在自己身上找原因。最后发现是银行的消息队列出了问题，微信平台把付款请求发送到银行的支付队列中，银行内部的系统完成了扣款之后，把扣款的结果发送到消息队列上面，但是由于技术原因（我们猜测是网络故障或消息队列崩溃）导致微信平台没有收到通知。于是微信平台返回的结果就是支付失败。这个解决办法就只有等待三个工作日，然后会自动退款到账户。
- 还有一个问题就是微信支付成功之后，微信平台会发送给微商城一个回调的请求，通知微商城用户支付是否成功。但是有可能会因为网络的原因或者其他的技术原因，微商城系统没有收到回调的请求，结果呢就出现了用户手机上显示扣款成功，但是微商城系统没有得到扣款成功的通知。订单的状态还是未支付，这种情况呢我们也想过办法，那就是用户手机显示扣款成功之后，马上发起AJAX请求，让微商城后台主动去请求微信平台查询用户的支付结果，这样就让微商城从等待推送变成了主动请求，问题就解决了。
- 另外商品可能会进行超售，就是说明明只有一件商品了，但是两个人都下单成功了，最开始是想了改变Mysql的隔离级别为串行化，但是并发量太低了，然后就想着在修改商品库存的时候直接加锁，但是这样容易导致死锁，所以最终采取的方案就是采用乐观锁机制，给SKU数据表(存放着库存)，加一个version字段。详解见解决数据库超售方案
项目架构
商品管理模块面试题
1、spu是商品公共信息，sku是商品的规格信息。比如说一个小米手机，CPU信息是安卓系统高通的CPU、六点五寸的屏幕等等。但是这部手机的内存容量和颜色是有很多种规格的，假设有三种内存容量和三种颜色组合在一起呢就是九种规格方案，也就是九条sku记录。我们创建数据表的时候，SPU表和SKU表示一对多的关系，也就是说一个SPU记录对应多条SKU记录。
2、如果是物理删除，在删除SPU记录之前，先要判断SPU记录有没有关联的订单，如果有关联的订单，那么SPU记录是不能删除的。如果没有关联的订单，是可以删除SPU记录呢，但是删除SPU记录要连带着删除sku记录，这个呢是物理删除的情况，如果是逻辑删除，那么就不需要判断SPU是否存在关联的订单了，直接在spu记录的Del字段上设置上true这个值，就代表说这条记录已经删除了。那么关联的sku数据delete字段也要设置删除。
3、我做的电商系统是B2C模式的，也就是单商铺的模式。如果要做多商铺的C 2 C电商系统，那么商铺之间的数据是要隔离的，不能交叉访问。所以设计数据表的时候就要引入商铺表，然后呢让SPU关联到商铺的ID，这样呢每个商铺就只能看到自己商铺的商品数据了。
4、虽然我们做的是单商铺的电商系统，只要商家编辑商品都会形成一条新的商品记录。当用户根据订单查询商品的时候，并不会看到最新的商品记录，而是会查询到他下单时候的商品记录，这个就可以防止商家随意篡改订单的商品信息。因为我们现在做的是单商铺的电商网站，所以一个商家的商品记录，包括归档数据还形不成上千万的数据规模。如果做成C2C的多商铺电商系统，那么SPU表和SKU表里边就会保存大量的数据，因为单表超过两千万数据，买mysql的读写性能就会很差。所以在这种情况下，应该单独创建SPU和SKU的归档数据表，把归档的数据转移存储到归档表里边，这样呢就可以实现对spu和sku数据表的缩表，这种数据库设计叫做冷热数据分离。
5、我们用的是逻辑删除。因为我们的系统是个微商城系统，数据量不是特别大，所以采用逻辑删除，这样的话误删除或者历史数据恢复方便。
如果以后数据量变大，就可能使用物理删除，数据直接清除，减小表的体量，一定程度上有利于查询效率。但是无法恢复数据，所以可以用一个折中的办法，对于物理删除，可以建立一张日志表。对物理删除后的数据记录到日志表中，并标记来源。在后续恢复时可以查找。
6、我觉得提高前端渲染的速度有很多种优化方案。首先是数据库方面要做好优化，比如说优化sql语句，多利用索引，设置innodb缓冲池，增加数据库的线程数量等。如果是小型项目，我们可以采用mysql分区技术，把数据切分存储到不同的硬盘上，多块硬盘的IO能力是要好于单块硬盘的，所以mysql的读写速度就提升了。
如果是大型项目，数据库层面要使用集群，数据呢要做分库、分表，还要做读写分离、冷热数据分离等等。
其次呢在程序的后台部分也能做很多提升数据读取速度的改进，比如说引入缓存，把热点的业务数据缓存到redis里边，如果命中缓存的话就不需要走数据库了。还有就是后台项目的网络连接方式可以从B I O改成N I O，这样呢依靠少量的线程就能处理更多的网络请求了。那么再有呢就是tomcat线程的数量，也能实现更大的网络吞吐能力。
另外呢我们可以利用cdn服务缓存静态的网页和图片，这样浏览器加载商品信息的时候也会更快一些。那么前端方面也有一些优化的手段，比如说减少http请求，能合并的请求就合并成一个http请求，那么素材图片可以使用雪花图，那么商品图片可以使用延时加载的办法。
7、我做的电商项目支持用户按照参数去查找商品，那么我们录入商品之后，就会把商品数据保存到数据库的SPU和SKU数据表里边，然后把可以用来检索的参数和商品名称以及主键值写到es里边。用户搜索商品的时候，我们就到es中查找，然后呢得到商品的ID。接下来呢从数据库中提取商品的信息，最后呢渲染到页面上面。
8、ES不能替代sku数据表。虽然es用来检索数据，但是es里边并不是存放了一个商品的全部信息，只是存放了用来被检索的那部分属性信息。页面渲染的时候，详细的规格信息还是要从sku数据表里边读取的
9、我们给ES添加了ik分词器，提取搜索信息里边的名词，忽略形容词，那么用户搜索最好看的全面屏手机的时候，最终是按照全面屏手机这个关键字来检索商品的。
解决数据库超售方案
产生原因
①修改库存的时候对记录加锁(悲观锁)
这种方案容易造成死锁
②使用乐观锁机制。乐观锁通过版本号来判定提交的更新操作是否有冲突。
我们需要在SKU数据表也就是litemall_goods_product中添加一个version字段。
乐观锁是怎么判断是否产生冲突的
redis超售现象出现的原因
虽然 Redis是单线程执行,但是也出出现超售的现象。一组业务命令发送给Reds执行,如果这些指令被插队就会出现超售现象
解决：
秒杀相关面试题
1、如果让你设计一个秒杀系统,你会怎么设计?
①第一点呢，秒杀活动通常时间都非常的短，并发访问很高，如果跟原网站部署在一起，可能会让原网站瞬间瘫痪，所以我会单独部署秒杀程序，分配独立的域名。
②第二点呢，在秒杀之前，为了不错过秒杀活动，用户会频繁的刷新画面，这对后台系统来说呢。会造成很大的负担。所以在使用数据库集群、redis集群以及负载均衡之外，那么秒杀页面要实现静态化，避免后台系统渲染动态页面消耗过多的资源。
③第三点呢，秒杀的时候需要短时间增大网络带宽。一方面呢可以在云端租用临时的带宽资源，另外一方面呢可以把秒杀页面放在cdn节点上。
④第四点呢，为了避免秒杀之前，用户提前获取下单页面儿的url路径，所以需要我们对下单页面实现url动态化。例如呢在秒杀开始之后，服务端生成特殊规则的随机数，然后呢把这些随机数保存到redis上面，那么秒杀的时候url地址必须要带上这样的随机数，才能进入到下单的画面，这样呢就能。避免秒杀之前提前下单的问题了，如果秒杀没有开始，任何人都不能进入到下单画面。
⑤那么第五点呢。就是扣减库存的方式也需要合理的设计。目前呢有两种扣减库存的方案，第一种是付款之后才扣减库存，但是会出现问题，比如说iphone手机有一百部库存，但是秒杀的时候有两千人成功的下单，然后呢有一百人成功的支付剩余一千九百人，那么这一千九百人在付款的时候会提示没有库存，明明是用户下单成功支付的时候却提示没有货，这种体验真的是太糟糕了，所以这种方案呢是不可取的。另外一种扣减库存的方案就是下单就扣减库存，这种方案意味着用户下单成功支付的时候一定会有货，不会出现提示没有库存的现象，所以我采用的是这种方案。
⑥第六点呢是有关超售的现象，在数据库层面可以使用乐观锁来解决，在redis层面可以使用事物来解决。
⑦ 以上这些呢就是我对秒杀模块的设计了，如果存在没有说到的地方，还请您多指正。
2、商品秒杀活动很容易出现超售现象,你会怎么解决?
秒杀活动开始之前，我先会用程序在redis里边创建商品的库存记录。接下来的秒杀程序，首先watch一下redis里边的库存和成功抢购商品的用户列表记录，然后开启redis事务，扣减库存和记录下成功抢购商品的用户id，最后呢提交redis事务。如果事务提交的批处理指令送达给redis，没有被其他秒杀程序插队执行，于是呢redis单线程就会执行当前事务提交的批处理命令，扣减库存就不会出现超售的现象了。
订单模块面试题
1、我们开发的微商城系统拥有团购优惠券、购物积分等功能，所以用户在微信小程序上面下了订单，后台系统首先要做数据验证，然后呢还要做内容验证。假如有人用postman拟小程序提交数据，有的数据呢能通过后台的正则表达式验证，但是逻辑上是有问题的。比如说呢提交过来的优惠券id在数据库里边就根本不存在，这样的订单是绝对不能生成的。所以我们要通过数据库来验证ajax提交过来的数据是否逻辑有效。特别是优惠券团购都是有明确期限的，所以呢后台系统还要额外去验证一下ajax提交过来的团购和优惠券是否已经过期了。
接下来需要后台系统计算订单中的商品总价格，然后计算团购的减免金额、优惠券的金额，还有积分的金额。有了这些数据，接下来后台程序就可以计算订单价格了。订单价格等于商品总价格减去团购减免的金额，减去优惠券金额、减去积分金额，但是计算出来的订单价格还不是用户需要支付的实际价格。因为我们做的微商城有一个包邮规则，只要用户购物满八十八元就可以包邮，所以后台程序要根据订单的价格计算出邮费是多少，满足包邮条件的时候邮费就是零元，如果不满足包邮条件，邮费该是多少钱就是多少钱。订单的付款金额啊就是订单价格再加上邮费，用户只要按照这个金额去付款就行了。那么往数据库里边添加订单信息之后，后台程序还要去更新优惠券的状态为已使用，并且记录下来用户参加了哪项团购活动。最后呢根据用户下单的商品数量，后台程序还要去扣减库存，然后呢跳转到支付页面，等待用户去支付。以上呢就是订单生成的全部流程了。
2、生成订单的时候先要验证前台提交的数据格式，还要验证它的逻辑有效性。就拿下架的商品来说吧，后台程序生成订单之前要验证商品是否存在，以及商品是否已经下架了。如果商品已经下架，那么订单是绝对不能生成的，我们给前台系统返回一个状态码，那么前台页面再告诉用户，订单的商品已经下架了。
3、我觉得最合理的扣减库存应该是用户下订单之后，而不是付款成功之后，这样能保证用户下单之后如果付款成功就一定能买到商品。如果下单不去扣减库存，等到用户付款的时候，这件商品已经卖光了，对购物体验来说呢是非常糟糕的。另外呢如果用户取消了订单，或者订单长时间未付款，那么后台系统也会自动取消订单。不管什么原因，只要订单取消了，那么订单关联的商品就会自动释放库存，这样库存就可以恢复了。
4、幂等性就是不管一个人操作数据还是多个人同时操作数据，最终的结果不能出现任何错误。在高并发的情况下，扣减库存确实可以出现逻辑上的错误。解决的办法有三种，第一种方案呢是把数据库的事务级别设置为串行化执行。这种方法的缺点是数据库中所有的事物。都要串行化去执行了，严重的降低了数据库的并发性。第二个方案呢是对数据库的记录进行加锁，但是加锁这种操作呢很容易引发死锁，所以呢不建议大家使用。第三个方案是给数据表加乐观锁，乐观锁不会锁住记录，所以呢可以保证并发性。但是乐观所独有的版本号机制保证了数据修改必须要符合逻辑性，所以乐观锁是保证扣减库存具有幂等性的最好方案。
5、在我做的微商城项目里边，用了雪花算法生成订单号，雪花算法结合了时间戳。主机ID和随机数来生成订单号，但是在高并发的情况下，还是容易出现相同的订单号，因此说呢可以增大订单号的长度，避免出现重复的订单号。
6、订单号和流水号不是一回事儿，它们的用途并不一样。流水号是对内公开的，并且包含了一定的业务信息，比方说订单商品是固体还是液体、是不是易碎品、走空运还是陆运等等。因为我做的是微商城系统，并没有那种大型的自动化仓库，所以在流水号里边并没有包含货架的信息。流水号的作用是工作人员或者机器人，不需要查询数据库就知道怎么去发货，算是一种内部工作的指令集。那么订单号是对外开放的，不需要包含详细的业务信息，只需要包括时间戳就可以了，能看出来是哪一天下的订单即可。
7、订单记录不能引用收货地址的ID，因为顾客修改了收货地址，那么他之前所有的订单收货地址都同时更新了，这个绝对不行，以前的订单必须用以前的收货地址，不能受到地址更新的影响。所以在订单记录中，我不是引用地址表的ID，而是把收货地址的数据保存在订单记录中，这样呢就不会受到用户修改地址的影响了。
8、订单模块儿用到了两张数据表，一个是订单表，另外一个是订单商品表。因为一个订单可以包含多个商品，所以这两张表的关系是一对多的。订单的价格、邮费、实付金额、优惠券、团购、收货地址、发货信息、签收信息，这些数据保存在订单表里边。订单包含的商品信息、规格信息、原始价格，这样的数据呢保存在订单商品表里边。如果一个订单买了十个不同的商品，那么订单商品表里边就要存储这个订单的十件商品记录，这里不是直接引用SPU和SKU记录的ID，那样呢商家修改了商品信息，订单里边的商品也就变了。所以呢我们是把商品信息复制到订单商品表。
9、因为我做的是微商城系统，都是在学校附近，没有别的异地商品，所以不需要对订单拆分。但是您说的订单拆分这个功能的思路我还是知道一些的。首先呢可以按照发货的仓库来拆分订单，A仓库发货的商品形成一个订单，B仓库发货的商品形成另外一个订单，以此类推。其次呢，如果最近的仓库没有货，需要后台系统根据仓库的地理坐标位置计算出最近的发货仓库，而且运费还要是最便宜，让这样的仓库来发货，这是拆分订单的另外一种思路。以上这些呢就是我对订单拆分理解了。
10、在我做的微商城系统中，取消订单的场景主要有三类。第一类呢是由顾客发起的取消，用户在客户端可以直接取消订单。那么第二类是客服人员或者卖家代为取消订单。比如说顾客下完订单之后成功的付款，但是呢马上又后悔了，通过联络卖家或者客服人员来取消订单，如果卖家尚未发货，是可以给顾客取消订单的。那么第三类是系统自动取消订单，比如说用户下单订单长时间没有支付，会被自动取消。
支付模块面试题
1、因为我现在做的是基于微信小程序的微商城系统，所以呢目前我们支持的支付平台啊只有微信支付，等我们的团队开始做支付宝小程序的时候，就可以使用支付宝。为订单付款了。因为做完微信支付业务之后，我去支付宝网站对比了一下跟微信支付的区别，基本的调用流程呢是相同的，而且呢传递的参数也都非常的接近，我也亲自调试了一下支付宝付款，觉得呢并不难，所以这种支付方式我是有能力融合到自己的项目里边的。
2、支付模块儿的大部分功能都是我写的。包括生成商品订单、小程序发起支付请求，商户平台申请生成支付订单，以及小程序发起付款请求，到最后商户系统接收到支付通知，那么甚至说呢定时关闭超期未支付的商品订单，这些功能全都是我写的。因为订单的支付呢涉及到了小程序和商户系统，所以呢这两个系统我都参与了开发。
3、小程序上面的微信支付牵扯到三个平台，分别是小程序、商户系统和微信平台。首先呢用户要在小程序上面点击付款按钮，发送请求给商户系统，告诉商户系统现在呢用户要为哪一个商品订单付款。然后呢商户系统会检查这个商品订单的信息，比如说呢检查一下是否存在这个商品订单的记录，以及呢这个订单是否已经取消或者过期了。如果没有问题呢，那么接下来商户系统就会向微信平台上传商品订单的信息。然后呢申请创建支付订单。微信平台创建出支付订单以后呢，会把很多信息返回给商户系统，那么商户系统再把这些信息返回给小程序，小程序为了验证商户系统在微信平台上面创建的支付订单，会拿着支付订单的编号到微信平台去查询支付订单的信息。这个时候呢用户的手机上面就会弹出支付订单的信息了，如果用户核对没有问题，就可以正常的输入支付密码了。付款成功之后呢，微信平台会把支付的结果分别发送给小程序和商户系统，商户系统得到通知以后呢，就可以修改商品订单的状态为已支付了。以上呢就是微信支付的全部流程。更详细的信息可以看这里
4、按照开发文档来的
5、JSAPI这种方式呢是应用在网页版的商城上面，比如说呢我们在微信的消息里边点开了商城网站的链接地址，或者说呢用微信扫描二维码，那么在微信里边打开商城网站，如果用户选购商品之后下单支付，那么这个时候就可以使用JSAPI发起微信支付了。那么JSAPI这种方式仅限于在微信里边打开商城的网页来使用，但是呢用户在手机上面用浏览器打开商城的网站，那么购物之后要下单支付，这个时候就可以使用H5的方式来发起微信支付了。当然了，如果想要在app里面发起微信支付，那么就需要。使用微信平台提供的APP支付这种方式，最后呢就是小程序这种支付方式，具体的流程刚才我已经说过了，但是呢它仅限于在小程序上面使用。
6、微信支付的数字签名是一个很长的字符串儿，这个字符串儿做了MD5运算，得出的结果就是数字签名。当然了，这个原始的字符串儿呢应该包括app id、支付订单的body、设备编号、商户id、随机字符串儿，还有呢商户平台的密钥，经过MD5运算之后，得到的结果就是数字签名。
7、第一种解决方案呢是可以这么去做，用户在付款成功之后呢，我们在小程序的success回调函数里边加上一个AJAX请求，主动请求后台的商户系统更改订单状态为已支付。那么第二种方案呢是让商户系统定时检查未支付的订单是否已经付款了。在小型的电商系统上面可以使用这种方案，但是在大型的电商系统上面存在未支付的订单很多，要是每一个订单都要向微信平台发起检查请求，对商户系统呢会造成一定的压力，而且呢还会占用网络带宽，所以呢这种方案并不推荐使用。那么除了您说的这个情况之外呢，还会出现其他的问题。比如说商户系统会多次接收到通知消息，因为微信平台呢没有接收到商户系统返回的确认响应，所以呢微信平台就会继续向商户系统发出消息通知，遇到这种情况呢就非常的好解决，让商户系统呢返回正确的接收响应即可。
8、支付订单未付款的超时时间是两个小时，就是说用户超过两个小时不去付款，那么支付订单就会被微信平台给取消，而且我们做的商户系统也会定期关闭超时未支付的订单。这样呢用户就不能在小程序上面为这个订单付款了。
9、return_code呢代表的是通信状态码，如果是success就意味着微信平台接收到的请求，但是并不意味着可以成功的处理请求。那么result_code呢是业务状态码，在success的时候，代表说呢微信平台成功地处理了请求。
10、您说的这种情况，在我们的微商城系统里边是不会出现的。因为用户每次发起付款请求的时候，商户系统都要检查商品订单状态是否已经支付。如果用户已经成功的付款，那么商户系统就会接收到消息通知更改订单的状态。微信小程序呢也会发起请求，让商户系统呢修改订单的状态。即便出现最严重的情况，商户系统没有接收到微信平台的通知，也没有接收到小程序的请求。那么用户再次发起支付请求的时候，商户系统检查商品订单记录是未支付的状态，而且呢有支付订单的ID，那么商户系统呢就会向微信平台发起请求，查询一下这个支付订单是否已经付款成功了。如果已经支付成功了呢，那么商户系统就会更新商品订单的状态，返回结果，告诉用户不能。重复付款。如果这个支付订单呢没有付款成功，那么商户系统啊就会关闭这个支付订单，然后呢创建新的支付订单，让用户去付款。
11、需要关闭商品订单，但是呢不用跟微信平台关闭支付订单一样，都设置成两个小时。因为即便关闭了支付订单，但是用户再次发起给商品订单付款的时候，我们可以创建新的支付订单让用户去付款，所以呢不会受到微信平台关闭支付订单的影响。我做的微商城系统会为商品订单设置二十四小时的付款上限。如果用户超过二十四小时没有为商品订单付款，那么商户系统呢就会关闭商品订单，把订单里边的商品呢释放回库存。但是呢关闭订单的时候啊会出现一种情况，就是关闭商品订单的那一刻，用户呢却付款成功了，但是呢商户系统已经把这个商品订单给关闭了，然后呢商户系统又接收到了微信平台的通知或者小程序发出的请求，这个时候呢商户平台应该把商品订单的状态由关闭状态改为已支付的状态。
12、有可能会出现这种情况，微信平台把扣款的请求发送给银行系统，银行系统呢完成了扣款，但是微信平台呢没有接收到银行系统返回的消息通知，所以呢就以为这一次扣款失败了，那么返回给用户的结果就是支付失败，但是用户呢又收到了银行扣款成功的短信，这种情况问题并不是出现在我开发的微商城系统上面，所以呢用户可以等待二十四小时。微信平台啊每天都会跟银行系统对账，如果发现你这笔订单已经扣款成功了，那么微信平台就会把支付结果分别发送给用户的小程序和商户系统，这个时候啊订单的状态就会改变了。如果二十四小时之后你还没有收到微信支付成功的通知，那么你就可以向微信平台去申诉了，让客服人员呢帮你解决一下。
13、有可能会出现这种情况，但是呢概率很低。问题啊可能会出现在微信平台或者银行系统上面，比如说呢微信平台的消息队列出现了问题，向银行系统发出了多次扣款的请求，或者说呢银行内部的消息队列出现了问题，在给扣款程序发送消息的时候，发送了多次扣款消息，这些啊都会导致重复的扣款。但是呢这些都不是我们这些普通开发者所能解决的，遇到这种问题啊，我只能及时的向微信平台申诉，协助用户找回重复扣款的那些钱。
购物车面试题
1、购车模块儿呢对用户来说呀有四点好处。
①是可以暂时存放商品，凑齐减免的额度，然后呢用户可以统一下单，或者用户积攒到商城促销的时候一起为这些商品下单，这些呢都是购物车暂时存放商品的好处。
②是可以合并下单，一个订单可以包含多件商品，如果没有购物车就不可以合并下单了，一个订单只能对应一件商品。
③是可以批量支付。这衔接的前一个好处，我们可以为一个订单去付款，而不用为每一件商品单独去付款。
④是可以对比商品的价格。商品收藏的购物车里边之后呢。用户可以在商城促销的时候看到商品降价了多少钱，这个可以促进用户下单购买商品。
购物车模块儿对商家来说呢有三个好处。
①第一个好处呢是可以提醒库存。比如说在双十一之前，有很多用户在购物车里边添加了A商品，那么电商系统就可以根据A商品实际的库存给卖家发去库存预警信息，提醒卖家在双十一期间这个商品可能会大卖，需要你提前准备好库存。
②是可以促进消费，在购物车的顶部放置上优惠的信息，比如说在凑单多少元可以减免邮费或者领取代金券等等。这种方式呢可以激励用户购买更多的商品。
③是可以猜测用户的喜好，结合大数据技术，电商系统可以分析用户购物车中的商品，然后呢就可以对用户的喜好进行画像了，进而呢准确地推荐用户喜欢的商品。以上呢就是我总结出来的购物车模块各种好处和重要意义。
2、在购物车顶部放置促销信息，告诉用户在凑单多少钱可以减免邮费或者领取代金券儿。用户看到之后呢心里就会想，反正有的东西以后也要买，不如现在一起买了吧。这样呢就可以引导和促进用户去消费了。另外呢购物车具有比价的功能，商家促销或者降价的时候呢，用户在购物车里边能看到商品降价了多少钱，商家周期。性的涨价和降价，目的就是让用户看到降价的时候赶紧抓紧下单去购买商品。还有呢就是可以利用大数据技术推测出用户的喜好，然后呢在购物车的底部放上推荐的商品，也能起到促进消费的作用。最后呢是利用购物车上面显示商品库存紧张，来鼓励用户立即下单购买。
3、很抱歉，我做的是微商城系统，并不具备商品推荐的功能。但是呢我听说收集用户的数据并且分析出用户的喜好，需要用到大数据技术。如果让我去设计一套推荐系统，我可以这么去做。编写程序从mysql上面提取用户购物车里边的数据，交给大数据的算法，推测出用户的喜好。为了降低数据处理的负担，我让程序呢每天只对新添加到购物车上面的数据做大数据的计算，然后呢商城的首页、商品的详情页面的底部以及购物车的底部就会放上。推荐的商品了，这就是我对商品推荐功能的设计和理解。
4、我做的微商城系统可以不用登录，直接使用购物车。如果用户不登录系统呢，那么购物车中的数据是保存在小程序本地的，而不是存放在数据库上面。微信小程序有自己的local storage（本地缓存），我就是用它来存放本地购物车中的数据。当用户创建订单的时候呢，我再要求用户必须登录系统，然后呢把小程序上面本地购物车的数据提交到微商城上面，并且保存到数据库里边，接下来呢再去创建商品订单。
5、离线购物车就是小程序本地的。购物车优点呢是可以让用户不登录系统就能用上购物车模块儿，另外呢往购物车里边删减商品也不需要向系统后台发出请求，这是离线购物车的两个优点。离线购物车呢也有缺点，那就是用户登录之后，离线购物车和在线购物车里边相同的商品合并会有问题。原来a商品在购物车中的收藏价格是五百元，但是呢商品经过调价之后呢，离线购物车里边收藏的这个a商品价格是四百元，那么这个呢就存在着商品合并的矛盾了。还有呢就是推荐系统无法根据离线购物车中的数据向用户推荐商品。
6、有上限，上限就是商品的库存数量。用户进入到购物车页面的时候呢，商户系统会查询出每一种sku商品的实际库存数量，如果库存紧张的商品呢就需要在购物车上面标注出来。然后呢用户给某件商品增加收藏数量的时候，因为用户进入到购物车页面的时候，每一种sku商品的库存数量已经查询出来了，所以不用每次添加商品收藏数量的时候就去查询实际的库存。换句话说呢，用户能添加的sku商品数量取决于离线库存
7、分析mysql数据库中每一个用户购物车里边收藏了哪些商品，然后结合商家的实际库存给出告警信息。
8、我的微商城系统啊，购物车商品是有数量上限的，淘宝购物车的上线呢是一百二，所以这一点呢我们跟淘宝是一致的。给购物车商品设置种类的数量上限也是方便以后用大数据计算用户的喜好以及对商品库存做出提前的预警。
9、订单模块已经回答过了
10、，这个系统是b2c类型的电商平台，购物车里边的商品可以按照收藏时间来排序，最新收藏的商品排在最前面。如果是c2c类型的电商平台，那么购物车里边的商品排序要结合店铺。比如说有一个用户。很早之前收藏了A店铺的一件商品，但是呢过去了一年多的时间，这个用户又收藏了A店铺的另外一件商品，这个时候呢就应该把A店铺排在购物车的顶部。
