您的位置 首页 php

2019年最接地气的PHP面试题(二)

21.商城秒杀的实现?

答:抢购、秒杀是如今很常见的一个应用场景,主要需要解决的问题有两个:

1 高并发对数据库产生的压力
2 竞争状态下如何解决库存的正确减少("超卖"问题)
 

对于第一个问题,已经很容易想到用缓存来处理抢购,避免直接操作数据库,例如使用 redis 。第二个问题,我们可以使用redis队列来完成,把要秒杀的商品放入到队列中,因为pop操作是原子的,即使有很多用户同时到达,也是依次执行,文件锁和事务在高并发下性能下降很快,当然还要考虑其他方面的东西,比如抢购页面做成静态的,通过ajax调用接口,其中也可能会出现一个用户抢多次的情况,这时候需要再加上一个排队队列和抢购结果队列及库存队列。高并发情况下,将用户进入排队队列,用一个线程循环处理从排队队列取出一个用户,判断用户是否已在抢购结果队列,如果在,则已抢购,否则未抢购,库存减1,写数据库,将用户入结果队列。

22.购物车的原理?

答:购物车相当于现实中超市的购物车,不同的是一个是实体车,一个是虚拟车而已。用户可以在购物网站的不同页面之间跳转,以选购自己喜爱的商品,点击购买时,该商品就自动保存到你的购物车中,重复选购后,最后将选中的所有商品放在购物车中统一到付款台结账,这也是尽量让客户体验到现实生活中购物的感觉。服务器通过追踪每个用户的行动,以保证在结账时每件商品都物有其主。

主要涉及以下几点:

 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的文件属性使其仍然留有安全隐患。

结合数据库的方式虽然在一定程度上解决了上述的问题,但从上面的例子可以看出:在这种购物流程中涉及到对数据库表的频繁操作,尤其是用户每选购一次商品,都要与数据库进行连接,当用户很多的时候就加大了服务器与数据库的负荷。

23.redis消息队列先进先出需要注意什么?

答:通常使用一个list来实现队列操作,这样有一个小限制,所以的任务统一都是先进先出,如果想优先处理某个任务就不太好处理了,这就需要让队列有优先级的概念,我们就可以优先处理高级别的任务,实现方式有以下几种方式:

1)单一列表实现:队列正常的操作是 左进右出(lpush,rpop)为了先处理高优先级任务,在遇到高级别任务时,可以直接插队,直接放入队列头部(rpush),这样,从队列头部(右侧)获取任务时,取到的就是高优先级的任务(rpop)

2)使用两个队列,一个普通队列,一个高级队列,针对任务的级别放入不同的队列,获取任务时也很简单,redis的BRPOP命令可以按顺序从多个队列中取值,BRPOP会按照给出的 key 顺序查看,并在找到的第一个非空 list 的尾部弹出一个元素,redis> BRPOP list1 list2 0

list1 做为高优先级任务队列

list2 做为普通任务队列

这样就实现了先处理高优先级任务,当没有高优先级任务时,就去获取普通任务

方式1最简单,但实际应用比较局限,方式3可以实现复杂优先级,但实现比较复杂,不利于维护

方式2是推荐用法,实际应用最为合适

24.你负责的模块有哪些难题?

答:在我负责的B2B电商项目中,当时我负责的是订单模块,由于客户一次选择了多家商户的商品,最终生成了一个订单,这样我们平台在给商户结算时出现了不知道这比费用应该给哪个商户,这时候我们小组经过讨论,需要涉及到订单拆分,也就是说用户点击支付后,如果有多件商品,并且不是同一家店铺那么 就要用到订单的拆分,比如如果有两件商品,并且不是同一店铺 就在原来的订单号下 在生成两个子订单号 并修改订单表中两件商品的订单号。最终实现了商品的分配管理,解决了我们的难题。

我觉得在开发过程中,遇到的难题无非是两个,一个是技术层次的,我认为,只要你有恒心,有热心,没有觉得不了的难题。另一个就是沟通问题,在任何地方任何时候沟通都是最重要的,尤其是我们做开发的,不沟通好,会影响整个项目的进度,我本人是个非常还沟通的人,所以这点上也没多大问题。

25.用户下单是怎么处理的?

答:判断用户有没有登录,在没有登录的情况下,不允许下单。登陆后,可进行下单,并生成唯一的订单号,此时订单的状态为未支付。

26.电商的登录是怎么实现的?

答:分为普通登录和第三方登录 这边主要说一下第三方登录吧,第三方登陆主要使用的是author协议,我就以 QQ 的第三方登陆为例来进行说明:当用户在我们的站点请求QQ的第三方登陆时,我们站点会引导用户跳转到QQ的登陆授权界面, 当用户输入QQ和密码成功登录以后会自动跳回到我们站点设置好的回调页面,并附带一个code参数,接着你使用code再次去请求QQ的授权页面,就可以从中获取到一个access token(访问令牌),通过这个access_token,我们可以调用QQ提供给我们的接口,比如获取open_id,可以获取用户的基本信息。获取到之后,我们需要拿用户的授权信息和open_id和我们平台的普通用户进行绑定。这样不管是普通用户登陆还是第三方登陆用户,都可以实现登陆。

27.接口安全方面是怎么处理的?

答:我们当时是这么做的,使用HTTP的POST方式,对固定参数+附加参数进行数字签名,使用的是 md5加密 ,比如:我想通过标题获取一个信息,在客户端使用 信息标题+日期+双方约定好的一个key通过md5加密生成一个签名(sign),然后作为参数传递到服务器端,服务器端使用同样的方法进行校验,如何接受过来的sign和我们通过算法算的值相同,证明是一个正常的接口请求,我们才会返回相应的接口数据。

28.用的什么技术实现短信发送,在哪调用?

答:我主要用的第三方短信接口,在申请接口时进行相应信息的配置,然后在我们站点需要用到短信验证的地方进行调用,我们通常在用户注册时使用到。

29.在工作中遇到什么困难?

答:总体来说:在工作我主要遇到这几个问题比较难处理:

①我之前工作的时候发现经常会出现一些临时需求打乱了我的计划,搞得有时候这个任务还没完成,又得去做其他的任务,最后一天下来,大大小小的东西是很多,但是没有完成得非常好的,后面我总结了一下,我会把这些都添加优先级,遇到临时需求,按照优先级重新将已有任务和临时任务进行排版,保证在规定时间内有效率的完成优先级高的任务。

②在做项目需求时候,遇到理解能力欠佳的人,沟通时容易被气到,影响自己的情绪,最后反倒还不能到达需要的效果。后面,每次到这种时候,我一般会借助一些纸质的、更加形象的东西,让双方都认同的、都能明白的一种方式来进行沟通,后面减少了很多不必须的麻烦。大家都知道,对于程序员来说,改需求是一件很痛苦的事情,所以前期的沟通工作很重要。

③还有一件事时,我以前的领导不太懂技术,所以每次出一个新的需求出来,总是要求我们在很短的时间内完成,完不成我们就会被怀疑能力有问题。当然,每个领导都希望自己的员工能够尽快的完成任务,降低成本,提高效率。这时候我会把我们的需求细化,把其中的重点、难点都列出来,做好时间规划,耐心的跟领导沟通,项目每个点的重要性和时间的花费比例,确保在这个规划的时间点内保质保量的完成任务。慢慢的也得到了领导的认可,其实领导也不是一味的不通情理,只要把东西计划好了,以最小的代价换取最高的价值,每个人都是很容易理解得

30.用户不登录,怎么直接加入购物车的?

答:用户在不登录的情况下,可以把要购买商品的信息(如商品的ID,商品的价格、商品的sku_id,购买数量等关键数据)存到COOKIE里面,当登陆的情况下。把COOKIE里面的内容存到数据库,并清除cookie中的数据。

31.写过接口吗,怎么定义接口的?

答:写过。接口分为两种:一种是数据型接口,一种是应用型接口。

数据型接口 :是比抽象类更抽象的某种“结构”——它其实不是类,但是跟类一样的某种语法结构,是一种结构规范,规范我们类要以什么格式进行定义,一般用于团队比较大,分支比较多的情况下使用。

应用型接口 : API(application interface) 数据对外访问的一个入口

我主要是参与的APP开发中接口的编写,客户端需要什么样的数据,我们就给他们提供相应的数据,数据以json/xml的格式返回,并且配以相应的接口文档。

32.sku减库存?

答:SKU = Stock Keeping Unit (库存量单位)

即库存进出计量的单位,可以是以件,盒,托盘等为单位。SKU是库存量单位,区分单品。

在服装、鞋类商品中使用最多最普遍。 例如纺织品中一个SKU通常表示:规格、颜色、款式。

在设计表时,不仅仅只有商品表,商品表中有个总库存,我们还需要涉及一张SKU表,里面有SKU库存和单价字段,用户每购买一件商品,实际上购买的都是SKU商品,这样在下订单成功后,应该根据所购买的商品的唯一的SKU号来进行相应的SKU库存的减少,当然商品的总库存保存在商品主表中,也需要减少总库存中的库存量。

33.库存设置?

答:库存分为商品总库存和SKU库存,往往商品总库存的为SKU库存的总和。一般在商城的后台对货品设置最高库存及最低库存后,当前库存数量与最高、最低两者比较,超出库存或者低于库存的,则被统计成报表形式反映,便于用户掌握货品库存超、短缺状态及数量。

34.订单、库存两个表 如何保证数据的一致性?

答:在一个电子商务系统中,正常的应该是订单生成成功后,相应的库存进行减少必须要保证两者的一致性,但有时候因为某些原因,比如程序逻辑问题,并发等问题,导致下单成功而库存没有减少的情况。这种情况我们是不允许发生的, MySQL 的中的事务刚好可以解决这一问题,首先得选择数据库的存储引擎为InnoDB的,事务规定了只有下订单完成了,并且相应的库存减少了才允许提交事务,否则就事务回滚,确保数据一致性。

35. O2O 用户下单,c端下单,如何保证ba端数据一致?

答:O2O为线上和线下模式,O2O模式奉行的是“线上支付+实体店消费”的消费模式,即消费者在网上下单完成支付后,凭消费凭证到实体店消费。 O2O模式是把商家信息和支付程序放在线上进行,而把商品和服务兑现放在线下,也就是说O2O模式适用于快递无法送达的有形产品。数据一致性的问题是O2O行业中最常见的问题,我们可以类似于数据库的主从复制的思路来解决这个问题.O2O有个供应商系统,类似于主服务器,在ç端(从服务器)下单时,数据同步更新到供应商系统端,b,a实时从供应商系统中拉取数据进行同步,比如利用定时任务,定时拉取数据进行同步。

36.Redis如何防止高并发?

答:其实redis是不会存在并发问题的,因为他是单进程的,再多的命令都是一个接一个地执行的。我们使用的时候,可能会出现并发问题,比如获得和设定这一对。Redis的为什么 有高并发问题?Redis的的出身决定

Redis是一种单线程机制的nosql数据库,基于key-value,数据可持久化落盘。由于单线程所以redis本身并没有锁的概念,多个客户端连接并不存在竞争关系,但是利用jedis等客户端对redis进行并发访问时会出现问题。发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题,这些问题均是由于客户端连接混乱造成。

同时,单线程的天性决定,高并发对同一个键的操作会排队处理,如果并发量很大,可能造成后来的请求超时。

在远程访问redis的时候,因为网络等原因造成高并发访问延迟返回的问题。

解决办法

在客户端将连接进行池化,同时对客户端读写Redis操作采用内部锁synchronized。

服务器角度,利用setnx变向实现锁机制。

37.秒杀当中的细节你是怎么得出来的?

答:通过性能测试及模拟秒杀场景。每个问题都经过反复测试,不断的发现问题,不断的解决。

38.做秒杀用什么数据库,怎么实现的?

答:因为秒杀的一瞬间,并发非常大,如果同时请求数据库,会导致数据库的压力非常大,导致数据库的性能急剧下降,更严重的可能会导致数据库服务器宕机。这时候一般采用内存高速缓存数据库redis来实现的,redis是非关系型数据库,redis是单线程的,通过redis的队列可以完成秒杀过程。

39.支付宝流程怎么实现的?

答:首先要有一个支付宝账号,接下来向支付宝申请在线支付业务,签署协议。协议生效后有支付宝一方会给网站方一个合作伙伴ID,和安全校验码,有了这两样东西就可以按照支付宝接口文档开发支付宝接口了,中间主要涉及到一个安全问题。整个流程是这样的:我们的网站通过post传递相应的参数(如订单总金额,订单号)到支付页面,支付页面把一系列的参数经过处理,以post的方式提交给支付宝服务器,支付宝服务器进行验证,并对接收的数据进行处理,把处理后的结果返回给我们网站设置的异步和同步回调地址,通过相应的返回参数,来处理相应的业务逻辑,比如返回的参数代表支付成功,更改订单状态。

40.什么是单点登录?

答:单点登录SSO(Single Sign On)说得简单点就是在一个多系统共存的环境下,用户在一处登录后,就不用在其他系统中登录,也就是用户的一次登录能得到其他所有系统的信任。

文章来源:智云一二三科技

文章标题:2019年最接地气的PHP面试题(二)

文章地址:https://www.zhihuclub.com/80128.shtml

关于作者: 智云科技

热门文章

网站地图