1、TP的特性有哪些/strong>
2、TP框架中的大字母函数/strong>
3、请介绍一下laravel框架/strong>
答: laravel框架的设计思想比较先进,非常适合应用各种开发模式,作为一个框架,它为你准备好了一切,composer是php的未来,没有composer,php肯定要走向没落
laravel框架最大的特点和优秀之处就是集合了php比较新的特点,以及各种各样的设计模式,Ioc模式,依赖注入等
4、laravel有那些特点/strong>
5、请简述一下数据库的优化/strong>
答:数据库的优化可以从四个方面来优化
6、如何解决异常处理/strong>
答: 抛出异常:
使用，异常的代码放在代码块内，如果没有触发异常，则代码继续执行，如果异常被触发，就会 抛出一个异常。代码块捕获异常，并创建一个包含异常信息的对象。，输出异常的错误信息。
解决异常:
使用函数获取异常(也可以使用和函数),然后使用函数设置默认的异常处理程序,函数来执行,执行机制是,要把调入的函数调入到内存,当页面所有的语句都执行完成时,再调用此函数
7、怎么保证促销商品不会超卖/strong>
答:这个问题是我们当时开发时遇到的一个难点，超卖的原因主要是下的订单的数目和我们要促销的商品的数目不一致导致的，每次总是订单的数比我们的促销商品的数目要多，当时我们的小组讨论了好久，给出了好几个方案来实现：
第一种方案：
在每次下订单前我们判断促销商品的数量够不够，不够不允许下订单，更改库存量时加上一个条件，只更改商品库存大于0的商品的库存，当时我们使用ab进行压力测试，当并发超过500，访问量超过2000时，还是会出现超卖现象。所以被我们否定了。
第二种方案：
使用mysql的事务加排他锁来解决，首先我们选择数据库的存储引擎为innoDB，使用的是排他锁实现的，刚开始的时候我们测试了下共享锁，发现还是会出现超卖的现象。有个问题是，当我们进行高并发测试时，对数据库的性能影响很大，导致数据库的压力很大，最终也被我们否定了。
第三种方案：
使用文件锁实现。当用户抢到一件促销商品后先触发文件锁，防止其他用户进入，该用户抢到促销品后再解开文件锁，放其他用户进行操作。这样可以解决超卖的问题，但是会导致文件得I/O开销很大。
最后我们使用了redis的队列来实现。将要促销的商品数量以队列的方式存入redis中，每当用户抢到一件促销商品则从队列中删除一个数据，确保商品不会超卖。这个操作起来很方便，而且效率极高，最终我们采取这种方式来实现
8、商城秒杀的实现/strong>
答:抢购、秒杀是如今很常见的一个应用场景，主要需要解决的问题有两个：
对于第一个问题，已经很容易想到用缓存来处理抢购，避免直接操作数据库，例如使用Redis。第二个问题，我们可以使用redis队列来完成，把要秒杀的商品放入到队列中，因为pop操作是原子的，即使有很多用户同时到达，也是依次执行，文件锁和事务在高并发下性能下降很快，当然还要考虑其他方面的东西，比如抢购页面做成静态的，通过ajax调用接口，其中也可能会出现一个用户抢多次的情况，这时候需要再加上一个排队队列和抢购结果队列及库存队列。高并发情况下，将用户进入排队队列，用一个线程循环处理从排队队列取出一个用户，判断用户是否已在抢购结果队列，如果在，则已抢购，否则未抢购，库存减1，写数据库，将用户入结果队列。
9、购物车的原理/strong>
答:购物车相当于现实中超市的购物车，不同的是一个是实体车，一个是虚拟车而已。用户可以在购物网站的不同页面之间跳转，以选购自己喜爱的商品，点击购买时，该商品就自动保存到你的购物车中，重复选购后，最后将选中的所有商品放在购物车中统一到付款台结账，这也是尽量让客户体验到现实生活中购物的感觉。服务器通过追踪每个用户的行动，以保证在结账时每件商品都物有其主。
实现购物车的关键在于服务器识别每一个用户并维持与他们的联系。但是HTTP协议是一种“无状态(Stateless)”的协议，因而服务器不能记住是谁在购买商品，当把商品加入购物车时，服务器也不知道购物车里原先有些什么，使得用户在不同页面间跳转时购物车无法“随身携带”，这都给购物车的实现造成了一定的困难。
目前购物车的实现主要是通过cookie、session或结合数据库的方式。下面分析一下它们的机制及作用。
1、cookie
cookie是由服务器产生，存储在客户端的一段信息。它定义了一种Web服务器在客户端存储和返回信息的机制，cookie文件它包含域、路径、生存期、和由服务器设置的变量值等内容。当用户以后访问同一个Web服务器时，浏览器会把cookie原样发送给服务器。通过让服务器读取原先保存到客户端的信息，网站能够为浏览者提供一系列的方便，例如在线交易过程中标识用户身份、安全要求不高的场合避免用户重复输入名字和密码、门户网站的主页定制、有针对性地投放广告等等。利用cookie的特性，大大扩展了WEB应用程序的功能，不仅可以建立服务器与客户机的联系，因为cookie可以由服务器定制，因此还可以将购物信息生成cookie值存放在客户端，从而实现购物车的功能。用基于cookie的方式实现服务器与浏览器之间的会话或购物车，有以下特点：
2、session
session是实现购物车的另一种方法。session提供了可以保存和跟踪用户的状态信息的功能，使当前用户在session中定义的变量和对象能在页面之间共享，但是不能为应用中其他用户所访问，它与cookie最重大的区别是，session将用户在会话期间的私有信息存储在服务器端，提高了安全性。在服务器生成session后，客户端会生成一个sessionid识别号保存在客户端，以保持和服务器的同步。这个sessionid是只读的，如果客户端禁止cookie功能，session会通过在URL中附加参数，或隐含在表单中提交等其他方式在页面间传送。因此利用session实施对用户的管理则更为安全、有效。
同样，利用session也能实现购物车，这种方式的特点是：
3、结合数据库的方式
这也是目前较普遍的模式，在这种方式中，数据库承担着存储购物信息的作用，session或cookie则用来跟踪用户。这种方式具有以下特点：
各种方式的选择：
虽然cookie可用来实现购物车，但必须获得浏览器的支持，再加上它是存储在客户端的信息，极易被获取，所以这也限制了它存储更多，更重要的信息。所以一般cookie只用来维持与服务器的会话，例如国内最大的当当网络书店就是用cookie保持与客户的联系，但是这种方式最大的缺点是如果客户端不支持cookie就会使购物车失效。
Session 能很好地与交易双方保持会话，可以忽视客户端的设置。在购物车技术中得到了广泛的应用。但session的文件属性使其仍然留有安全隐患。
结合数据库的方式虽然在一定程度上解决了上述的问题，但从上面的例子可以看出：在这种购物流程中涉及到对数据库表的频繁操作，尤其是用户每选购一次商品，都要与数据库进行连接，当用户很多的时候就加大了服务器与数据库的负荷。
10、redis消息队列先进先出需要注意什么/strong>
答:通常使用一个list来实现队列操作，这样有一个小限制，所以的任务统一都是先进先出，如果想优先处理某个任务就不太好处理了，这就需要让队列有优先级的概念，我们就可以优先处理高级别的任务，实现方式有以下几种方式：
1）单一列表实现：队列正常的操作是 左进右出（lpush,rpop）为了先处理高优先级任务，在遇到高级别任务时，可以直接插队，直接放入队列头部（rpush），这样，从队列头部（右侧）获取任务时，取到的就是高优先级的任务（rpop）
2）使用两个队列，一个普通队列，一个高级队列，针对任务的级别放入不同的队列，获取任务时也很简单，redis的BRPOP命令可以按顺序从多个队列中取值，BRPOP会按照给出的 key 顺序查看，并在找到的第一个非空 list 的尾部弹出一个元素，redis> BRPOP list1 list2 0
11、接口安全方面是怎么处理的/strong>
答:我们当时是这么做的，使用HTTP的POST方式,对固定参数+附加参数进行数字签名,使用的是md5加密,比如:我想通过标题获取一个信息,在客户端使用 信息标题+日期+双方约定好的一个key通过md5加密生成一个签名(sign),然后作为参数传递到服务器端,服务器端使用同样的方法进行校验,如何接受过来的sign和我们通过算法算的值相同，证明是一个正常的接口请求，我们才会返回相应的接口数据。
也可以使用RSA加密
12、写过接口吗，怎么定义接口的/strong>
答：写过。接口分为两种：一种是数据型接口，一种是应用型接口。
数据型接口：是比抽象类更抽象的某种“结构”——它其实不是类，但是跟类一样的某种语法结构，是一种结构规范，规范我们类要以什么格式进行定义，一般用于团队比较大，分支比较多的情况下使用。
应用型接口： API（application interface） 数据对外访问的一个入口
我主要是参与的APP开发中接口的编写，客户端需要什么样的数据，我们就给他们提供相应的数据，数据以json/xml的格式返回，并且配以相应的接口文档。
13、sku减库存/strong>
答:SKU = Stock Keeping Unit (库存量单位)
即库存进出计量的单位，可以是以件，盒，托盘等为单位。SKU是库存量单位，区分单品。
在服装、鞋类商品中使用最多最普遍。 例如纺织品中一个SKU通常表示：规格、颜色、款式。
在设计表时，不仅仅只有商品表，商品表中有个总库存，我们还需要涉及一张SKU表，里面有SKU库存和单价字段，用户每购买一件商品，实际上购买的都是SKU商品，这样在下订单成功后，应该根据所购买的商品的唯一的SKU号来进行相应的SKU库存的减少，当然商品的总库存保存在商品主表中，也需要减少总库存中的库存量。
14、库存设置/strong>
答:库存分为商品总库存和SKU库存，往往商品总库存的为SKU库存的总和。一般在商城的后台对货品设置最高库存及最低库存后，当前库存数量与最高、最低两者比较，超出库存或者低于库存的，则被统计成报表形式反映，便于用户掌握货品库存超、短缺状态及数量。
15、订单、库存两个表 如何保证数据的一致性/strong>
答：在一个电子商务系统中，正常的应该是订单生成成功后，相应的库存进行减少必须要保证两者的一致性，但有时候因为某些原因，比如程序逻辑问题，并发等问题，导致下单成功而库存没有减少的情况。这种情况我们是不允许发生的，MySQL的中的事务刚好可以解决这一问题，首先得选择数据库的存储引擎为InnoDB的，事务规定了只有下订单完成了，并且相应的库存减少了才允许提交事务，否则就事务回滚，确保数据一致性。
16、O2O用户下单，c端下单，如何保证ba端数据一致/strong>
答：O2O为线上和线下模式，O2O模式奉行的是“线上支付+实体店消费”的消费模式，即消费者在网上下单完成支付后，凭消费凭证到实体店消费。 O2O模式是把商家信息和支付程序放在线上进行，而把商品和服务兑现放在线下，也就是说O2O模式适用于快递无法送达的有形产品。数据一致性的问题是O2O行业中最常见的问题，我们可以类似于数据库的主从复制的思路来解决这个问题.O2O有个供应商系统，类似于主服务器，在（从服务器）下单时，数据同步更新到供应商系统端，b，a实时从供应商系统中拉取数据进行同步，比如利用定时任务，定时拉取数据进行同步。
17、Redis如何防止高并发/strong>
答：其实redis是不会存在并发问题的，因为他是单进程的，再多的命令都是一个接一个地执行的。我们使用的时候，可能会出现并发问题，比如获得和设定这一对。Redis的为什么 有高并发问题edis的的出身决定
Redis是一种单线程机制的nosql数据库，基于key-value，数据可持久化落盘。由于单线程所以redis本身并没有锁的概念，多个客户端连接并不存在竞争关系，但是利用jedis等客户端对redis进行并发访问时会出现问题。发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题，这些问题均是由于客户端连接混乱造成。
同时，单线程的天性决定，高并发对同一个键的操作会排队处理，如果并发量很大，可能造成后来的请求超时。
在远程访问redis的时候，因为网络等原因造成高并发访问延迟返回的问题。
解决办法
在客户端将连接进行池化，同时对客户端读写Redis操作采用内部锁synchronized。
服务器角度，利用setnx变向实现锁机制。
18、支付宝流程怎么实现的/strong>
答:首先要有一个支付宝账号，接下来向支付宝申请在线支付业务，签署协议。协议生效后有支付宝一方会给网站方一个合作伙伴ID,和安全校验码，有了这两样东西就可以按照支付宝接口文档开发支付宝接口了，中间主要涉及到一个安全问题。整个流程是这样的：我们的网站通过post传递相应的参数（如订单总金额，订单号）到支付页面，支付页面把一系列的参数经过处理，以post的方式提交给支付宝服务器，支付宝服务器进行验证，并对接收的数据进行处理，把处理后的结果返回给我们网站设置的异步和同步回调地址，通过相应的返回参数，来处理相应的业务逻辑，比如返回的参数代表支付成功，更改订单状态。
19、什么是单点登录/strong>
答:单点登录SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。
20、什么情况下使用缓存/strong>
答:当用户第一次访问应用系统的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把 ticket送到认证系统进行校验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
21、怎么实现第三方登录/strong>
答:第三方登陆主要是基于author协议来实现，下面简单说下实现流程:
22、如何处理负载、高并发好好看看，经常问到，能回答到主要的东西即可)/strong>
答:从低成本、高性能和高扩张性的角度来说有如下处理方案：
1、HTML静态化
其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的 网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。
2、图片服务器分离
把图片单独存储，尽量减少图片等大流量的开销，可以放在一些相关的平台上，如骑牛等
3、数据库集群和库表散列及缓存
数据库的并发连接为100，一台数据库远远不够，可以从读写分离、主从复制，数据库集群方面来着手。另外尽量减少数据库的访问，可以使用缓存数据库如memcache、redis。
4、镜像：
尽量减少下载，可以把不同的请求分发到多个镜像端。
5、负载均衡：
Apache的最大并发连接为1500，只能增加服务器，可以从硬件上着手，如F5服务器。当然硬件的成本比较高，我们往往从软件方面着手。
负载均衡 （Load Balancing） 建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力，同时能够提高网络的灵活性和可用性。目前使用最为广泛的负载均衡软件是Nginx、LVS、HAProxy。我分别来说下三种的优缺点:
Nginx的优点是：
Nginx的缺点是：
LVS：使用Linux内核集群实现一个高性能、高可用的负载均衡服务器，它具有很好的可伸缩性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。
LVS的优点是：
LVS的缺点是：
HAProxy的特点是：
① roundrobin，表示简单的轮询，这个不多说，这个是负载均衡基本都具备的；
② static-rr，表示根据权重，建议关注；
③ leastconn，表示最少连接者先处理，建议关注；
④ source，表示根据请求源IP，这个跟Nginx的IP_hash机制类似，我们用其作为解决session问题的一种方法，建议关注；
⑤ ri，表示根据请求的URI；
⑥ rl_param，表示根据请求的URl参数’balance url_param’ requires an URL parameter name；
⑦ hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；
⑧ rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。
Nginx和LVS对比的总结：
23、封装过一个简单的框架/strong>
答;封装过一个简单的MVC框架,主要分为3层，控制器层和模型层视图层，以及路由的分配和入口文件，模板引擎，单例模式、工厂模式，第三方类库的引入等。
24、谈谈对MVC的认识/strong>
答:核心思想是：视图和用户交互通过事件导致控制器改变 控制器改变导致模型改变 或者控制器同时改变两者 模型改变 导致视图改变 或者视图改变 潜在的从模型里面获得参数 来改变自己。他的好处是可以将界面和业务逻辑分离。
25、session与cookie的区别/strong>
26、echo(),print(),print_r()的区别/strong>
27、说一下单引号双引号/strong>
来源：即墨丹青
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！