博主还将大量面试题整理成了一个PHP面试手册,html
是PDF版,文章结尾有获取方式,感兴趣的来。程序员
答:购物车至关于现实中超市的购物车,不一样的是一个是实体车,一个是虚拟车而已。用户能够在购物网站的不一样页面之间跳转,以选购本身喜好的商品,点击购买时,该商品就自动保存到你的购物车中,重复选购后,最后将选中的全部商品放在购物车中统一到付款台结帐,这也是尽可能让客户体验到现实生活中购物的感受。服务器经过追踪每一个用户的行动,以保证在结帐时每件商品都物有其主。
主要涉及如下几点:面试
一、把商品添加到购物车,即订购
二、删除购物车中已定购的商品
三、修改购物车中某一本图书的订购数量
四、清空购物车
五、显示购物车中商品清单及数量、价格redis
实现购物车的关键在于服务器识别每个用户并维持与他们的联系。可是HTTP协议是一种“无状态(Stateless)”的协议,于是服务器不能记住是谁在购买商品,当把商品加入购物车时,服务器也不知道购物车里原先有些什么,使得用户在不一样页面间跳转时购物车没法“随身携带”,这都给购物车的实现形成了必定的困难。
目前购物车的实现主要是经过cookie、session或结合数据库的方式。下面分析一下它们的机制及做用。算法
cookie
cookie是由服务器产生,存储在客户端的一段信息。它定义了一种Web服务器在客户端存储和返回信息的机制,cookie文件它包含域、路径、生存期、和由服务器设置的变量值等内容。当用户之后访问同一个Web服务器时,浏览器会把cookie原样发送给服务器。经过让服务器读取原先保存到客户端的信息,网站可以为浏览者提供一系列的方便,例如在线交易过程当中标识用户身份、安全要求不高的场合避免用户重复输入名字和密码、门户网站的主页定制、有针对性地投放广告等等。利用cookie的特性,大大扩展了WEB应用程序的功能,不只能够创建服务器与客户机的联系,由于cookie能够由服务器定制,所以还能够将购物信息生成cookie值存放在客户端,从而实现购物车的功能。用基于cookie的方式实现服务器与浏览器之间的会话或购物车,有如下特色:数据库
一、cookie存储在客户端,且占用不多的资源,浏览器容许存放300个cookie,每一个cookie的大小为4KB,足以知足购物车的要求,同时也减轻了服务器的负荷;
二、cookie为浏览器所内置,使用方便。即便用户不当心关闭了浏览器窗口,只要在cookie定义的有效期内,购物车中的信息也不会丢失;
三、cookie不是可执行文件,因此不会以任何方式执行,所以也不会带来病毒或***用户的系统;
四、基于cookie的购物车要求用户浏览器必须支持并设置为启用cookie,不然购物车则失效;
五、存在着关于cookie侵犯访问者隐私权的争论,所以有些用户会禁止本机的cookie功能。json
session浏览器
session是实现购物车的另外一种方法。session提供了能够保存和跟踪用户的状态信息的功能,使当前用户在session中定义的变量和对象能在页面之间共享,可是不能为应用中其余用户所访问,它与cookie最重大的区别是,session将用户在会话期间的私有信息存储在服务器端,提升了安全性。在服务器生成session后,客户端会生成一个sessionid识别号保存在客户端,以保持和服务器的同步。这个sessionid是只读的,若是客户端禁止cookie功能,session会经过在URL中附加参数,或隐含在表单中提交等其余方式在页面间传送。所以利用session实施对用户的管理则更为安全、有效。
一样,利用session也能实现购物车,这种方式的特色是:安全
一、session用新的机制保持与客户端的同步,不依赖于客户端设置;
二、与cookie相比,session是存储在服务器端的信息,所以显得更为安全,所以可将身份标示,购物等信息存储在session中;
三、session会占用服务器资源,加大服务器端的负载,尤为当并发用户不少时,会生成大量的session,影响服务器的性能;
四、由于session存储的信息更敏感,并且是以文件形式保存在服务器中,所以仍然存在着安全隐患。服务器
结合数据库的方式
这也是目前较广泛的模式,在这种方式中,数据库承担着存储购物信息的做用,session或cookie则用来跟踪用户。这种方式具备如下特色:
一、数据库与cookie分别负责记录数据和维持会话,能发挥各自的优点,使安全性和服务器性能都获得了提升;
二、每个购物的行为,都要直接创建与数据库的链接,直至对表的操做完成后,链接才释放。当并发用户不少时,会影响数据库的性能,所以,这对数据库的性能提出了更高的要求;
三、使cookie维持会话有赖客户端的支持。
各类方式的选择:
虽然cookie可用来实现购物车,但必须得到浏览器的支持,再加上它是存储在客户端的信息,极易被获取,因此这也限制了它存储更多,更重要的信息。因此通常cookie只用来维持与服务器的会话,例如国内最大的当当网络书店就是用cookie保持与客户的联系,可是这种方式最大的缺点是若是客户端不支持cookie就会使购物车失效。
Session能很好地与交易双方保持会话,能够忽视客户端的设置。在购物车技术中获得了普遍的应用。但session的文件属性使其仍然留有安全隐患。
结合数据库的方式虽然在必定程度上解决了上述的问题,但从上面的例子能够看出:在这种购物流程中涉及到对数据库表的频繁操做,尤为是用户每选购一次商品,都要与数据库进行链接,当用户不少的时候就加大了服务器与数据库的负荷。
答:一般使用一个list来实现队列操做,这样有一个小限制,因此的任务统一都是先进先出,若是想优先处理某个任务就不太好处理了,这就须要让队列有优先级的概念,咱们就能够优先处理高级别的任务,实现方式有如下几种方式:
1)单一列表实现:队列正常的操做是 左进右出(lpush,rpop)为了先处理高优先级任务,在遇到高级别任务时,能够直接插队,直接放入队列头部(rpush),这样,从队列头部(右侧)获取任务时,取到的就是高优先级的任务(rpop)
2)使用两个队列,一个普通队列,一个高级队列,针对任务的级别放入不一样的队列,获取任务时也很简单,redis的BRPOP命令能够按顺序从多个队列中取值,BRPOP会按照给出的 key 顺序查看,并在找到的第一个非空 list 的尾部弹出一个元素,redis> BRPOP list1 list2 0
list1 作为高优先级任务队列 list2 作为普通任务队列 这样就实现了先处理高优先级任务,当没有高优先级任务时,就去获取普通任务 方式1最简单,但实际应用比较局限,方式3能够实现复杂优先级,但实现比较复杂,不利于维护 方式2是推荐用法,实际应用最为合适
答:在我负责的B2B电商项目中,当时我负责的是订单模块,因为客户一次选择了多家商户的商品,最终生成了一个订单,这样咱们平台在给商户结算时出现了不知道这比费用应该给哪一个商户,这时候咱们小组通过讨论,须要涉及到订单拆分,也就是说用户点击支付后,若是有多件商品,而且不是同一家店铺那么 就要用到订单的拆分,好比若是有两件商品,而且不是同一店铺 就在原来的订单号下 在生成两个子订单号 并修改订单表中两件商品的订单号。最终实现了商品的分配管理,解决了咱们的难题。
我以为在开发过程当中,遇到的难题无非是两个,一个是技术层次的,我认为,只要你有恒心,有热心,没有以为不了的难题。另外一个就是沟通问题,在任何地方任什么时候候沟通都是最重要的,尤为是咱们作开发的,不沟通好,会影响整个项目的进度,我本人是个很是还沟通的人,因此这点上也没多大问题。
答:判断用户有没有登陆,在没有登陆的状况下,不容许下单。登录后,可进行下单,并生成惟一的订单号,此时订单的状态为未支付。
答:分为普通登陆和第三方登陆 这边主要说一下第三方登陆吧,第三方登录主要使用的是author协议,我就以QQ的第三方登录为例来进行说明:当用户在咱们的站点请求QQ的第三方登录时,咱们站点会引导用户跳转到QQ的登录受权界面, 当用户输入QQ和密码成功登陆之后会自动跳回到咱们站点设置好的回调页面,并附带一个code参数,接着你使用code再次去请求QQ的受权页面,就能够从中获取到一个access token(访问令牌),经过这个access_token,咱们能够调用QQ提供给咱们的接口,好比获取open_id,能够获取用户的基本信息。获取到以后,咱们须要拿用户的受权信息和open_id和咱们平台的普通用户进行绑定。这样无论是普通用户登录仍是第三方登录用户,均可以实现登录。
答:咱们当时是这么作的,使用HTTP的POST方式,对固定参数+附加参数进行数字签名,使用的是md5加密,好比:我想经过标题获取一个信息,在客户端使用 信息标题+日期+双方约定好的一个key经过md5加密生成一个签名(sign),而后做为参数传递到服务器端,服务器端使用一样的方法进行校验,如何接受过来的sign和咱们经过算法算的值相同,证实是一个正常的接口请求,咱们才会返回相应的接口数据。
答:我主要用的第三方短信接口,在申请接口时进行相应信息的配置,而后在咱们站点须要用到短信验证的地方进行调用,咱们一般在用户注册时使用到。
答:整体来讲:在工做我主要遇到这几个问题比较难处理:
①我以前工做的时候发现常常会出现一些临时需求打乱了个人计划,搞得有时候这个任务还没完成,又得去作其余的任务,最后一天下来,大大小小的东西是不少,可是没有完成得很是好的,后面我总结了一下,我会把这些都添加优先级,遇到临时需求,按照优先级从新将已有任务和临时任务进行排版,保证在规定时间内有效率的完成优先级高的任务。
②在作项目需求时候,遇到理解能力欠佳的人,沟通时容易被气到,影响本身的情绪,最后反倒还不能到达须要的效果。后面,每次到这种时候,我通常会借助一些纸质的、更加形象的东西,让双方都认同的、都能明白的一种方式来进行沟通,后面减小了不少没必要须的麻烦。你们都知道,对于程序员来讲,改需求是一件很痛苦的事情,因此前期的沟通工做很重要。
③还有一件事时,我之前的领导不太懂技术,因此每次出一个新的需求出来,老是要求咱们在很短的时间内完成,完不成咱们就会被怀疑能力有问题。固然,每一个领导都但愿本身的员工可以尽快的完成任务,下降成本,提升效率。这时候我会把咱们的需求细化,把其中的重点、难点都列出来,作好时间规划,耐心的跟领导沟通,项目每一个点的重要性和时间的花费比例,确保在这个规划的时间点内保质保量的完成任务。慢慢的也获得了领导的承认,其实领导也不是一味的不通情理,只要把东西计划好了,以最小的代价换取最高的价值,每一个人都是很容易理解得
答:用户在不登陆的状况下,能够把要购买商品的信息(如商品的ID,商品的价格、商品的sku_id,购买数量等关键数据)存到COOKIE里面,当登录的状况下。把COOKIE里面的内容存到数据库,并清除cookie中的数据。
答:写过。接口分为两种:一种是数据型接口,一种是应用型接口。
数据型接口:是比抽象类更抽象的某种“结构”——它其实不是类,可是跟类同样的某种语法结构,是一种结构规范,规范咱们类要以什么格式进行定义,通常用于团队比较大,分支比较多的状况下使用。
应用型接口: API(application interface) 数据对外访问的一个入口
我主要是参与的APP开发中接口的编写,客户端须要什么样的数据,咱们就给他们提供相应的数据,数据以json/xml的格式返回,而且配以相应的接口文档。
答:SKU = Stock Keeping Unit (库存量单位)
即库存进出计量的单位,能够是以件,盒,托盘等为单位。SKU是库存量单位,区分单品。
在服装、鞋类商品中使用最多最广泛。 例如纺织品中一个SKU一般表示:规格、颜色、款式。
在设计表时,不只仅只有商品表,商品表中有个总库存,咱们还须要涉及一张SKU表,里面有SKU库存和单价字段,用户每购买一件商品,实际上购买的都是SKU商品,这样在下订单成功后,应该根据所购买的商品的惟一的SKU号来进行相应的SKU库存的减小,固然商品的总库存保存在商品主表中,也须要减小总库存中的库存量。
关注微信公众号:PHP大神,而后回复“面试手册”便可获取~