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