⾯试：----电商项⽬中⽐较难得问题
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的时间，重新设置有效期。
的拦截，在l中设置拦截的名称。
订单模块需要⽤到的表:
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、购物车表
最主要的是：商铺订单号in_trade_no和第三⽅⽀付下单号out_trade_no
- 下单核⼼实现(⾮完整代码)
《⼀》购物车提交过来的下单最终是以不同店铺组成的数组
如：
$data=arrray(
'店铺A'=>array('商品1'，'商品2'),
立夏是2022的几月几日'店铺B'=>array('商品1'，'商品2'),
);
《⼆》只有⼀个数组时，让商铺订单号in_trade_no和第三⽅⽀付下单号out_trade_no⼀致，这样⼦的好处是，我们可以认为订单号和下单号⼀致时就是在⼀个店铺⽀付的，⽽不是多个，这样就可以复⽤下单接⼝返回的数据，从⽽对该待付款订单进⾏付款，⽽不是再调下单接⼝⽣成新的订单号去⽀付（既可以减少接⼝调⽤，也可以减少费单）
如：
1234=》1234
$unified_order= WeixinPay::unifiedOrder(
$this->conf['weixin']['pay_key'],
$this->openid,1234,$order['pay']*100,$this->appid,
$this->conf['weixin']['mch_id'],
$this->conf['weixin']['pay_notify_url'],
WeixinPay::getNonceStr(),$order['title']
);
$data=array(
高考考哪几门科目'appId'=>$this->appid,
'nonceStr'=>$unified_order['nonce_str'],
'package'=>"prepay_id={$unified_order['prepay_id']}",
'signType'=>'MD5',
'timeStamp'=>strval($_SERVER['time']),
);
$data['paySign']= WeixinPay::MakeSign($data,$this->conf['weixin']['pay_key']);
$this->vshop_orderWeixinPrepay->setPrePay(1234,$data);
$this->err_msg['ok']['data']=$data;
$this->_showJsonMsg('ok');
⽤户⽀付待付款订单时直接把之前存着的下单数据拿出来：
if(商铺订单号==第三⽅⽀付下单号){//在⼀个店铺内购买东西
去检查1234这个下单号是否已经⽀付过了，⽀付过了则退出，⽽且如果订单不是未付款状态，例如⽹络超时等直接报错退出
通过执⾏下⾯代码
$data=$this->vshop_orderWeixinPrepay->getPrePay(1234);
$this->err_msg['ok']['data']=$data;
$this->_showJsonMsg('ok');
}else{//不⼀致为什么这么做？请看《三》
重新⽣成商铺订单号和第三⽅⽀付下单号，让其⼀致
调⽤下单接⼝，根据该订单⾦额等，重新下单
}
《三》多个数组时，每个店铺订单对应相同的第三⽅⽀付下单号，但是商铺订单号不能与下单号出现⼀致的情况，否则就会导致超额付款问题。怎么装扮qq空间
如
1234=>1111
4567=>1111
8910=>1111
⽽不能是
1234=>4567
4567=>4567
8910=>4567
为什么商铺订单号不能与下单号出现⼀致的情况，否则就会导致超额付款？
场景是⽤户把⼏个店铺的商品提交过来，假如3个店铺，我们内部会⽣成3个内部订单号和⼀个下单号，如果成功⽀付问题很好解决，假如没有成功⽀付，前端就会像有赞那样出现3个待付款的订单。
假如这么巧，⽤户就对 4567 => 4567 这个单进⾏付款操作，按照上⾯《⼆》的逻辑，就会进到getPrePay获取到下单号4567的下单数据，记住，下单号4567的⾦额是内部订单号1234，4567， 8910三者⾦额的和，⽤户本来想⽀付第⼆个内部订单4567的钱，最后却变成了⽀付三个订单的钱，这是万万不可的，因此要确保商铺订单号不能与下单号出现⼀致的情况，这很简单，例如加个字母前缀等即可
1234=> o_4567
4567=>o_4567
8910=>o_4567
这样⼦，⽤户单独⽀付订单时，永远⾛的是：《重新⽣成商铺订单号和第三⽅⽀付下单号，让其⼀致；调⽤下单接⼝，根据该订单⾦额等，重新下单》这个逻辑，请看《⼆》。
《四》订单的退款，成功付款，只需要结合内部订单号和第三⽅下单号处理就可以了
:(怎么理解的)
第⼀次写博客，与⼤家共勉.
这⾥⽤到的原理其实⾮常简单，将cookie存在⼀个公共的站点的页⾯上就可以了，这⾥我们管那个站点叫主站S.
先说说所谓的跨域
环境需要跟b.xxx实现跨域，这种⽐较简单，只需要设置cookie的域名关联域就可以了 cookie.Domain = "xxx"，这样两个域名间的cookie就可以互相访问，实现跨域.
手语学习环境2:a.aaa需要跟b.bbb实现跨域，这种不同域名的情况下，想要实现就必须换种⽅式了.
在这⾥我将引⼊第三者,s.sss这个站点，就是某个浏览器同时打开了这3个站点，我们访问A站点，先判断⾃⾝是否登录，如果session为空，就
重定向到S站点，判断S站点上⾯是否有cookie，如果S站点上⾯也没有cookie，则由S站点重定向到A站点的登录页.
这样我们就实现了第⼀步,S站做的的就是隐藏在幕后,⼦站先判断⾃⼰是否存在session，如果不存在，就重定向到主站S上⾯去验证.
第⼆步，验证登录信息合法性.这⾥我引⼊token(令牌),⽹上有很多资料，描述token的传递,⼯作⽅式是这样,A登录成功，保存⾃⾝的session，重定
向到S,S在⾃⼰站点保存⼀个session跟cookie,session保存token对象{tokenID,userName,startTime,endTime},cookie保存tokenID,tokenID是
⼀个Guid，把token对象缓存在集合⾥⾯，另起⼀个线程，根据endTime(过期时间)来定期清理集合列表，重定向到A的时候再将tokenID传递过去,
拿到tokenID后，进⼊验证环节,S站有提供⼀个接⼝，根据tokenID获取token对象，如果获取到对象，且没有失效，则tokenID合法，跳⼊index页⾯.情
况2,A登录，直接打开B，这时候B⾃⾝没有session，会主动请求主站，主站会返回cookieID(S站存在客户端的cookie)，这个时候再⾛验证环节，如果
通过，则B根据token对象创建⾃⾝的session，再跳⼊index
什么是顶级域名，什么是⼆级域名(理解)
⼀个完整的域名由⼆个或⼆个以上部分组成，各部分之间⽤英⽂的句号"."来分隔，最后⼀个"."的右边部分称为（TLD，也称为），最后⼀个"."的左边部分称为⼆级域名（SLD），⼆级域名的左边部分称为三级域名，以此类推，每⼀级的域名控制它下的分配。
域名的构成
：⼀个域名由两个以上的词段构成，最右边的就是。
⽬前，国际上出现的顶级域名有,,.org,.gov,.edu,.mil,.cc,.to,.tv以及国家或地区的代码，其中最通⽤的是,,.org
.COM - -适⽤于商业实体，它是最流⾏的顶级域名，任何⼈都可注册⼀个.。
.NET - -最初⽤于⽹络机构如ISP，今天，任何⼀个⼈都可注册⼀个域名。
.ORG ---设计是⽤于各类组织机构，包括⾮盈利团体，今天，任何⼀个⼈都可注册⼀个.。国家代码：像cn（中国）,fr（法国）和au（）这样
两个字母的域名谓之国家代码顶级域名（ccTLDs），通过ccTLDs，基本上可以辨明域名持有者的国家或地区。详细的国家代码可在查。
⼆级域名：靠左边的部分就是所谓的⼆级域名，在中，cctv就是顶级域名下的⼆级域名，还可以有的形式，这⾥的mail可以谓之"主机"或"⼦域名"。
域名的结构
顶级域名
域名由两个或两个以上的词构成, 中间由点号分隔开。最右边的那个词称为顶级域名。下⾯是⼏个常见的顶级域名及其⽤法：
.COM--⽤于商业机构。它是最常见的顶级域名。任何⼈都可以注册.COM 形式的域名。
.NET--最初是⽤于⽹络组织，例如因特⽹服务商和维修商。现在任何⼈都可以注册以.NET结尾的域名。
.ORG--是为各种组织包括⾮盈利组织⽽定的。现在，任何⼈都可以注册以.ORG 结尾的域名。
国家代码由两个字母组成的顶级域名如, .uk, .de和.jp称为国家代码顶级域名(ccTLDs), 其中是中国专⽤的顶级域名
activeMA是怎么保证收到消息的:
消费者注册到activemq服务器时，在activemq服务器上会记录消费者的信息。并且消费者与服务器之间会保持⼀种类似于⼼跳线的机制，只要任意⼀⽅出现的异常导致程
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论