面试问题总结二（技术能力-PHP）----Ⅱ

20、支付功能的实现？

答：在线支付通常来讲有两种实现方式，一种是调用各个银行提供的接口，另外一种是使用第三方集成好的支付功能，两种方式各有优劣。对于第三方支付来讲会须要提交企业5证来验证，还会有部分手续费，可是实现起来就很是方便了。对于直接使用银联接口的话就是使用起来必来麻烦，要为各个银行写接口实现，可是相比起来就更加安全了。

案例参考：https://blog.csdn.net/qq_38869854/article/details/79204792

 

2一、如何保证促销产品不会超卖？

答:这个问题是咱们在开发时遇到的一个难点，超卖的缘由主要是下的订单的数目和咱们要促销的商品的数目不一致致使的，订单的数比咱们的促销商品的数目要多，通过小组讨论了以后给出了好几个方案来实现：

第一种方案：在每次下订单前咱们判断促销商品的数量够不够，不够不容许下订单，更改库存量时加上一个条件，只更改商品库存大于 0 的商品的库存，使用 ab 进行压力测试，当并发超过 400，访问量超过 2000 时，仍是会出现超卖现象。因此方案一行不通。

第二种方案：使用 mysql 的事务加排他锁来解决，首先咱们选择数据库的存储引擎为 innoDB，使用的是排他锁实现的，刚开始测试了下共享锁，发现仍是会出现超卖的现象。当咱们进行高并发测试时，对数据库的性能影响很大，致使数据库的压力很大，最终也被否认。

第三种方案是：使用文件锁实现。当用户抢到一件促销商品后先触发文件锁，防止其余用户进入，该用户抢到促销品后再解开文件锁，放其余用户进行操做。这样能够解决超卖的问题，可是会致使文件得 I/O 开销很大，最终被否认。

最后通过测试后使用 redis 的队列来实现。将要促销的商品数量以队列的方式存入 redis 中，每当用户抢到一件促销商品则从队列中删除一个数据，确保商品不会超卖。这个操做起来很方便，并且效率极高。

 

2二、商城秒杀的实现？

答:抢购、秒杀是现在很常见的一个应用场景，主要须要解决的问题有两个：

1 高并发对数据库产生的压力

2 竞争状态下如何解决库存的正确减小（”超卖”问题）

 

 

对于第一个问题，用缓存来处理抢购，避免直接操做数据库，例如使用 Redis。

第二个问题，咱们可使用 redis 队列来完成，把要秒杀的商品放入到队列中，由于 pop 操做是原子的，即便有不少用户同时到达，也是依次执行，文件锁和事务在高并发下性能降低很快，固然还要考虑其余方面的东西，好比抢购页面作成静态的，经过 ajax 调用接口，其中也可能会出现一个用户抢屡次的状况，这时候须要再加上一个排队队列和抢购结果队列及库存队列。高并发状况下，将用户进入排队队列，用一个线程循环处理从排队队列取出一个用户，判断用户是否已在抢购结果队列，若是在，则已抢购，不然未抢购，库存减 1，写数据库，将用户入结果队列。

 

2三、购物车原理？

答:购物车至关于现实中超市的购物车，不一样的是一个是实体车，一个是虚拟车而已。用户能够在购物网站的不一样页面之间跳转，以选购本身喜好的商品，点击加入购物车时，该商品就自动保存到你的购物车中，重复选购后，最后将选中的全部商品放在购物车中统一到付款台结帐，这也是尽可能让客户体验到现实生活中购物的感受。服务器经过追踪每一个用户的行动，以保证在结帐时每件商品都物有其主。主要涉及如下几点:

一、把商品添加到购物车，即订购；

二、删除购物车中已定购的商品；

三、修改购物车中某一本图书的订购数量；

四、清空购物车；

五、显示购物车中商品清单及数量、价格。

实现购物车的关键在于服务器识别每个用户并维持与他们的联系。可是 HTTP 协议是一种“无状态(Stateless)”的协议，于是服务器不能记住是谁在购买商品，当把商品加入购物车时，服务器也不知道购物车里原先有些什么，使得用户在不一样页面间跳转时购物车没法“随身携带”，这都给购物车的实现形成了必定的困难。

目前购物车的实现主要是经过 cookie、session 或结合数据库的方式。下面分析一下它们的机制及做用。

 

cookie 是由服务器产生，存储在客户端的一段信息。它定义了一种 Web 服务器在客户端存储和返回信息的机制，cookie 文件它包含域、路径、生存期、和由服务器设置的变量值等内容。当用户之后访问同一个 Web 服务器时，浏览器会把 cookie 原样发送给服务器。经过让服务器读取原先保存到客户端的信息，网站可以为浏览者提供一系列的方便，例如在线交易过程当中标识用户身份、安全要求不高的场合避免用户重复输入名字和密码、门户网站的主页定制、有针对性地投放广告等等。利用 cookie 的特性，大大扩展了 WEB 应用程序的功能，不只能够创建服务器与客户机的联系，由于 cookie 能够由服务器定制，所以还能够将购物信息生成 cookie 值存放在客户端，从而实现购物车的功能。用基于 cookie 的方式实现服务器与浏览器之间的会话或购物车，有如下特色：

一、cookie 存储在客户端，且占用不多的资源，浏览器容许存放 300 个 cookie，每一个 cookie 的大小为 4KB，足以知足购物车的要求，同时也减轻了服务器的负荷；

二、cookie 为浏览器所内置，使用方便。即便用户不当心关闭了浏览器窗口，只要在 cookie 定义的有效期内，购物车中的信息也不会丢失；

三、cookie 不是可执行文件，因此不会以任何方式执行，所以也不会带来病毒或攻击用户的系统；

四、基于 cookie 的购物车要求用户浏览器必须支持并设置为启用 cookie，不然购物车则失效；

五、存在着关于 cookie 侵犯访问者隐私权的争论，所以有些用户会禁止本机的 cookie 功能。

 

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 的文件属性使其仍然留有安全隐患。结合数据库的方式虽然在必定程度上解决了上述的问题，但从上面的例子能够看出：在这种购物流程中涉及到对数据库表的频繁操做，尤为是用户每选购一次商品，都要与数据库进行链接，当用户不少的时候就加大了服务器与数据库的负荷。

 

2四、redis 消息队列先进先出须要注意什么？

答:一般使用一个 list 来实现队列操做，这样有一个小限制，因此的任务统一都是先进先出，若是想优先处理某个任务就不太好处理了，这就须要让队列有优先级的概念，咱们就能够优先处理高级别的任务，实现方式有如下几种方式：

一、单一列表实现：队列正常的操做是 左进右出（lpush,rpop）为了先处理高优先级任务，在遇到高级别任务时，能够直接插队，直接放入队列头部（rpush），这样，从队列头部（右侧）获取任务时，取到的就是高优先级的任务（rpop）。

二、使用两个队列，一个普通队列，一个高级队列，针对任务的级别放入不一样的队列，获取任务时也很简单。

三、redis 的 BRPOP 命令能够按顺序从多个队列中取值，BRPOP 会按照给出的 key 顺序查看，并在找到的第一个非空 list 的尾部弹出一个元素，redis> BRPOP list1 list2 0    。

list1作为高优先级任务队列list2 作为普通任务队列这样就实现了先处理高优先级任务，当没有高优先级任务时，就去获取普通任务方式 1 最简单，但实际应用比较局限，方式 3 能够实现复杂优先级，但实现比较复杂，不利于维护，方式 2 是推荐用法，实际应用最为合适

 

2五、简述一下对redis 的认识？

答：Redis(REmote DIctionary Server) 是一个由Salvatore Sanfilippo写的key-value存储系统。

Redis是一个开源的使用ANSI C语言编写、遵照BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

它一般被称为数据结构服务器，由于值（value）能够是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。

Redis 与其余 key - value 缓存产品有如下三个特色：

• Redis支持数据的持久化，能够将内存中的数据保存在磁盘中，重启的时候能够再次加载进行使用。
• Redis不只仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
• Redis支持数据的备份，即master-slave模式的数据备份。

Redis 优点

• 性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
• 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操做。
• 原子 – Redis的全部操做都是原子性的，意思就是要么成功执行要么失败彻底不执行。单个操做是原子性的。多个操做也支持事务，即原子性，经过MULTI和EXEC指令包起来。

• 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过时等等特性。

Redis与其余key-value存储的不一样之处

• Redis有着更为复杂的数据结构而且提供对他们的原子性操做，这是一个不一样于其余数据库的进化路径。
• Redis运行在内存中可是能够持久化到磁盘，因此在对不一样数据集进行高速读写时须要权衡内存，由于数据量不能大于硬件内存。
• 在内存数据库方面的另外一个优势是，相比在磁盘上相同的复杂的数据结构，在内存中操做起来很是简单，这样Redis能够作不少内部复杂性很强的事情。同时，在磁盘格式方面他们是紧凑的以追加的方式产生的，由于他们并不须要进行随机访问。

 

2六、你工做中遇到哪些难题？如何解决？

答:在工做我主要遇到这几个问题比较难处理：

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

②在作项目需求时候，遇到理解能力较差的人，不容易沟通，容易影响本身的情绪，最后还不能到达须要的效果。自此后，我通常会借助一些纸质的、更加形象的东西，让双方都认同的、都能明白的一种方式来进行沟通，减小了不少没必要须的麻烦。对于程序员来讲，改需求是一件很痛苦的事情，因此前期的沟通工做很重要。

③我之前的领导不太懂技术，因此每次出一个新的需求出来，老是要求咱们在很短的时间内完成，完不成容易被怀疑能力有问题。固然，每一个领导都但愿本身的员工可以尽快的完成任务，下降成本，提升效率。当领导提出需求时，我会把需求进行细化拆分，把其中的重点、难点都列出来，作好时间规划，耐心的跟领导沟通，项目每一个点的重要性和时间的花费比例，确保在这个规划的时间点内保质保量的完成任务。慢慢的也获得了领导的承认，其实领导也不是一味的不通情理，只要把东西计划好了，以最小的代价换取最高的价值，每一个人都是很容易理解的。

④以前工做中遇到过不少不懂的知识技能，但在公司发展规划中须要用到这些知识，由于才毕业没多久而且是在创业公司，也没有人能够带领去学习相关的知识。前期确实有点手忙脚乱的感受，后来经过与领导交流和加入一些技术群与群里的技术大咖们进行探讨学习，以后在工做之余梳理了下公司的发展计划，罗列了一系列的知识技能点，按需求时间顺序去查找相关的资料和在网上听取相关知识的公开课，并结合实践进行练习。经过实战练习发现问题并记录下来，能经过网上查询找到解决的方法的就先解决，实在没办法了才去询问技术群里的前辈或咨询讲解公开课的老师。坚持自学和与他人沟通很是重要，只要天天学一点，坚持下去总会有所收获的。

 

2七、用户下单如何处理？

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

 

2八、电商的登陆是怎么实现的？

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

 

2九、接口数据安全是如何处理的？

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

 

30、短信发送如何实现？通常什么状况下会用到？

答:主要用的第三方短信接口，在申请接口时进行相应信息的配置，而后在咱们站点须要用到短信验证的地方进行调用，咱们一般在用户注册和修改密码时使用到。

 

3一、用户不登陆如何把商品加入购物车？

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

可是若用户禁用了cookie，则须要提示用户开启cookie 才能生效。

 

3二、如何定义接口？

答：接口分为两种：一种是数据型接口，一种是应用型接口。

数据型接口：是比抽象类更抽象的某种“结构”——它其实不是类，可是跟类同样的某种语法结构，是一种结构规范，规范咱们类要以什么格式进行定义，通常用于团队比较大，分支比较多的状况下使用。

应用型接口： API（application interface） 数据对外访问的一个入口。客户端须要什么样的数据，咱们就给他们提供相应的数据。

我主要是参与的 APP 开发中接口API的编写，数据以 json 的格式返回，而且配以相应的接口文档。

 

3三、SKU 减库存？

答:SKU = Stock Keeping Unit (库存量单位) 即库存进出计量的单位，能够是以件，盒，托盘等为单位。SKU 是库存量单位，区分单品。 在服装、鞋类商品中使用最多最广泛。 例如纺织品中一个 SKU 一般表示：规格、颜色、款式。在设计表时，不只仅只有商品表，商品表中有个总库存，咱们还须要涉及一张 SKU 表，里面有 SKU 库存和单价字段，用户每购买一件商品，实际上购买的都是 SKU 商品，这样在下订单成功后，应该根据所购买的商品的惟一的 SKU 号来进行相应的 SKU 库存的减小，固然商品的总库存保存在商品主表中，也须要减小总库存中的库存量。

 

3四、库存的设置？

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

 

3五、订单和库存2张表如何保证数据的一致性？

答:在一个电子商务系统中，正常的应该是订单生成成功后，相应的库存进行减小。必需要保证二者的一致性，但有时候由于某些缘由，好比程序逻辑问题，并发等问题，致使下单成功而库存没有减小的状况。这种状况咱们是不容许发生的，MySQL 中的事务恰好能够解决这一问题，首先得选择数据库的存储引擎为 innoDB,事务规定了只有下订单完成了，而且相应的库存减小了才容许提交事务，不然就事务回滚，确保数据一致性。

 

3六、O2O 用户下单,c 端下单,如何保证 b a 端数据一致?

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

 

3七、Redis 如何防止高并发？

答:其实 redis 是不会存在并发问题的，由于他是单进程的，再多的 command 都是 one by one 执行的。咱们使用的时候，可能会出现并发问题，好比 get 和 set 这一对。redis 为何会有高并发问题redis 的出身决定 Redis 是一种单线程机制的 nosql 数据库，基于 key-value，数据可持久化落盘。因为单线程因此 redis 自己并无锁的概念，多个客户端链接并不存在竞争关系，可是利用 jedis 等客户端对 redis 进行并发访问时会出现问题。发生链接超时、数据转换错误、阻塞、客户端关闭链接等问题，这些问题均是因为客户端链接混乱形成。 同时，单线程的天性决定，高并发对同一个键的操做会排队处理，若是并发量很大，可能形成后来的请求超时。 在远程访问 redis 的时候，由于网络等缘由形成高并发访问延迟返回的问题。解决办法 在客户端将链接进行持久化，同时对客户端读写 Redis 操做采用内部锁 synchronized。 服务器角度，利用 setnx 变向实现锁机制。

 

3八、作秒杀通常用什么数据库？怎么实现？

答:由于秒杀的一瞬间，并发很是大，若是同时请求数据库，会致使数据库的压力很是大，致使数据库的性能急剧降低，更严重的可能会致使数据库服务器宕机。这时候通常采用内存高速缓存数据库 redis 来实现的,redis 是非关系型数据库，redis 是单线程的，经过 redis 的队列能够完成秒杀过程。

 

3九、支付宝流程如何实现？

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

 

40、微信支付流程如何实现？

官方文档：

https://pay.weixin.qq.com/wiki/doc/api/app/app.php?chapter=8_3

答：业务流程说明： 
一、商户后台系统根据用户选购的商品生成订单。 
二、用户确认支付后调用微信支付【统一 下单API】生成预支付交易； 
三、微信支付系统收到请求后生成预支付交易单，并返回交易会话的二维码连接code_url。 
四、商户后台系统根据返回的code_url生成二维码。 
五、用户打开微信“扫一扫”扫描二维码，微信客户端将扫码内容发送到微信支付系统。 
六、微信支付系统收到客户端请求，验证连接有效性后发起用户支付，要求用户受权。 
七、用户在微信客户端输入密码，确认支付后，微信客户端提交受权。 
八、微信支付系统根据用户受权完成支付交易。 
九、微信支付系统完成支付交易后给微信客户端返回交易结果，并将交易结果经过短信、微信消息提示用户。微信客户端展现支付交易结果页面。 
十、微信支付系统经过发送异步消息通知商户后台系统支付结果。商户后台系统需回复接收状况，通知微信后台系统再也不发送该单的支付通知。 
十一、未收到支付通知的状况，商户后台系统调用【查询订单API】。 
十二、商户确认订单已支付后给用户发货。 

 

4一、网银在线支付流程如何实现？

答：事先作好API接口申请工做。

1 先作商品支付页面

2 用户肯定提交订单(同时本地写入数据库一个惟一的订单号,并设定成未支付状态)
3.提交订单到网银在线支付页面
4用户支付成功后返回网站操做页面(对用户进行操做,数据中的当前订单更改为已支付)

 

相关资源：

支付流程演示连接   http://chinabank.com.cn/aminute/

商户管理登陆地址：https://merchant3.chinabank.com.cn

网银在线 ： http://www.chinabank.com.cn/gateway/help.html 

支付平台网关接口地址：https://pay3.chinabank.com.cn/PayGate

登录网银在线商户后台 https://merchant3.chinabank.com.cn/login.do

网银在线官网地址：http://www.chinabank.com.cn

B2C银行卡支付的接口文档：http://www.chinabank.com.cn/gateway/chinabank.zip

 

银联在线支付：

文档和接口下载地址： https://online.unionpay.com/mer/doc/viewDoc.action   ---php接口开发包 （并附有“银联在线支付（UPOP） ECSHOP支付插件”）