面试:----电商项目中比较难得问题

SSO单点登录:

SSO系统：这里涉及到拦截器。

       这里是利用了sso的接口文档，即校验接口、注册、登录接口、根据token查询用户接口、安全退出接口。

   这个的调用服务层是利用jsonp的形式访问的服务接口，实现跨域访问。客户端全部在jsp页面实现的。

具体流程：

     当用户点击注册的时候，跳转到注册页面，即用户信息的保存功能。检验用户名是否存在、手机号和邮箱不能为空。

       当用户点击登录按钮的时候，用户输入用户名和密码，检验用户名是否在数据库中存在，然后用户名密码是否正确。这里的密码是用了spring的MD5加密技术。当全部成功后，给用户颁发一个token令牌（利用uuid实现），然后将token存入到redis中（token的key是它生成的号，值是用户的名字），然后设置在redis的过期时间。这相当于用户的session。

   然后将token写入cookie中，前台页面利用jsonp调用，根据cookie中的token的值，调用sso的根据token查询用户的服务，查看用户是否有效，如果有效则将用户返回前台页面，前台页面获取用户的用户名显示在首页，表示***已登陆。

   这里的cookie是设置了共享域，即全部子系统都可以访问到cookie。

当用户登录其他子系统时，先从从cookie中获取token信息，根据token信息获取用户信息，判断用户信息是否有效，如果有效则放行，如果无效，则利用拦截器拦截跳转到登录页面。用户再次登录的时候刷新redis的时间，重新设置有效期。

拦截器的拦截，在springMVC.xml中设置拦截的名称。

订单模块需要用到的表:

1、数据库的设计：订单相关表设计、订单关联的诸如商品列表、会员信息、折扣、积分、打包销售等；账单相关表，包括内部账单和渠道支付账单（如微信支付、支付宝支付等），还有就是操作日志类。建议网上去找一些资料或者开源电商产品参考一下，这块第一次做考虑完整比较难的，当然是根据实际需求裁剪，但如果大面上设计有问题后面功能扩展的时候会非常难受；

2、第三方支付：主要是支付过程中一些正常和异常的流程，微信支付你可以参考它帮助文档中推荐的测试用例，挺完整的；另外就是后台需要轧账和平账，就是你要每天和第三方平台去对一次账，看看两边数据库里的支付情况是否正确。

3、你在上面提到了及时到账，那就证明可能有个人账户体系，这里的充值、提现要想好怎么搞？一般第三方支付针对个人是没有提现接口的，只有退款

购物车与商城以及订单的关系：

从一般的商城来看，可以分为B2C与C2C，也就是单商城系统和多商城系统。单商城的系统，基本上就是全部商品生成一个订单，而多商城系统里面的购物车则是可以根据店铺来分别支付生成订单（如微店）或者全部统一支付然后根据店铺拆分订单（如有赞，淘宝等）。

      总结如下：

          

      如上图所示：

     （1）根据每个店铺生成订单去支付，很好理解，例如我在店铺A，买了1，2，3这几个商品，我只需要生成一个订单号，然后去支付就可以了，后续的退款等各种处理，只需要根据该订单号进行处理即可。

     （2） 那么，最后一个，购物车里面有多个店铺的商品，又需要一起支付的时候怎么办呢？假定我们使用微信支付，微信支付每次下单只能使用唯一一个单号，那么我们只能把不同的店铺，例如店铺A和店铺B的所有商品，都统一放到一个订单号去微信下单支付。但是，这样子又违反了订单规则：不同的店铺存在着不同的订单业务，店铺和订单是一对多的关系，而且每个订单号必须是唯一的。怎么办？这个时候，我们可以把内部订单号和微信下单号做一个映射（也就是图所说的拆单），后续做各种处理例如退款等，就可以通过映射关系去进行处理，如下图：

      

      总结一下他们之间的关系：

      （1）购物车可以存在多个店铺多个商品，可以一次性给钱购买购物车所有商品

      （2）一个订单只能对应一个店铺，一个店铺可以拥有多个订单

      （3）微信下单号只有一个，一个微信下单号可以对应多个内部订单号，一个内部订单号只能对应一个微信下单号

C2C商城购物车数据库设计与技术实现

 由于B2C商城和C2C大同小异，这里暂且不讨论B2C的设计和实现，相信会C2C实现而不会B2C的同学是不存在的。且纵观目前的商城，大部分慢慢倾向于增加商家入住功能，所以建议预留多商铺功能，即先把商铺表加进去，与商品相关的带上商铺id，只不过目前商铺只有一个就是自己，就这样可以减少业务需求改动带来的大量数据库结构和代码的改动。

如果用户购物车内的商品都是一个店铺的，那么就不存在拆单、映射表这种说法，直接生成唯一订单号作为微信订单号支付就可以，但是谁都不知道需求是如何变化的，既然淘宝都是可以统一支付不同店铺的商品，那么设计的时候最好是支持购物车所有商品统一支付的，这样子就通杀了，不管你是B2C的购物车，还是微店的购物车，还是淘宝的购物车，都能满足需求。如果只能支持不同店铺做分别支付，类似微店这样，那么万一产品要改成支付宝这样子，就又得重新设计映射表，进行拆单了。本人所在公司的产品经理刚开始比较倾向于微店这种产品设计，而我设计系统时，也仅仅往产品的需求思考，而没考虑到淘宝的设计，现在换一个产品又要改为淘宝这种购物车，就感觉深深地掉进了坑里面。这里学到了一个道理，那就是永远不要相信产品经理（哭），当然也不要过度设计，这里其实不是过度设计，只是用多一点时间，就能减少以后的巨大时间，而且产品人员也很喜欢参考大公司的产品功能，毕竟一些基础功能都是经过大量的用户反馈的。

那么我们就以有赞这种做法来设计我们的购物车和订单吧。

      1、订单表

          

     2、购物车表

          </