什么是mvc？相互间有什么关系?
答：MVC是一种开发模式，主要分为三部分：M（模型），也就是模型，负责数据的操作; V（视图），也就是视图，负责前后台的显示; C（控制器），也就是控制器，负责业务逻辑 客户端请求项目的控制器,如果执行过程中需要用到数据,控制器就会到模型中获取数据,再将获取到的数据通过视图显示出来;
OOP具有三大特点:
1、封装性：也称为信息隐藏，就是将一个类的使用和实现分开，只保留部分接口和方法与外部联系，或者说只公开了一些供开发人员使用的方法。于是开发人员只 需要关注这个类如何使用，而不用去关心其具体的实现过程，这样就能实现MVC分工合作，也能有效避免程序间相互依赖，实现代码模块间松藕合。
2、继承性：就是子类自动继承其父级类中的属性和方法，并可以添加新的属性和方法或者对部分属性和方法进行重写。继承增加了代码的可重用性。PHP只支持单继承，也就是说一个子类只能有一个父类。
3、多态性：子类继承了来自父级类中的属性和方法，并对其中部分方法进行重写。于是多个子类中虽然都具有同一个方法，但是这些子类实例化的对象调用这些相同的方法后却可以获得完全不同的结果，这种技术就是多态性。多态性增强了软件的灵活性。
9 .smarty是什么，有什么作用？
smarty是个模板引擎，最显著的地方就是有可以把模板缓存起来。一般模板来说，都是做一个静态页面，然后在里面把一些动态的部分用一切分隔符切开，然后在PHP里打开这个模板文件，把分隔符里面的值替换掉，然后输出来，你可以看下PHPLib里面的template部分。
而smarty设定了缓存参数以后，第一次运行时候会把模板打开，在php替换里面值的时候把读取的html和php部分重新生成一个临时的php文件，这样就省去了每次打开都重新读取html了。如果修改了模板，只要重新刷下就行了。
15.简述一下数据库的优化?
答:数据库的优化可以从四个方面来优化:
1.从结构层: web服务器采用负载均衡服务器,mysql服务器采用主从复制,读写分离
2.从储存层: 采用合适的存储引擎,采用三范式
3.从设计层: 采用分区分表,索引,表的字段采用合适的字段属性,适当的采用逆范式,开启mysql缓存
4.sql语句层:结果一样的情况下,采用效率高,速度快节省资源的sql语句执行
16.如何解决异常处理?
答: 抛出异常:使用try...catch，异常的代码放在try代码块内，如果没有触发异常，则代码继续执行，如果异常被触发，就会 抛出一个异常。Catch代码块捕获异常，并创建一个包含异常信息的对象。$e->getMessage()，输出异常的错误信息。
解决异常:使用set_error_handler函数获取异常(也可以使用try()和catch()函数),然后使用set_exception_handler()函数设置默认的异常处理程序,register_shutdown_function()函数来执行,执行机制是,php要把调入的函数调入到内存,当页面所有的php语句都执行完成时,再调用此函数
18.权限管理（RBAC）的实现？
答: 1.首先创建一张用户表:id name auto(保存格式为:控制器-方法)
2.然后在后台中创建一个基类控制器,控制器里封装一个构造方法,当用户登陆成功后,使用TP框架中封装好的session函数获取保存在服务器中的session id,然后实例化模型,通过用户id获取保存在数据表中的auth数据,使用explode函数分割获取到的数据,并使用一个数组保存起来,然后使用TP框架中封装好的常量获取当前控制器和方法,然后把他们组装成字符串,使用in_array函数进行判断该数组中是否含有当前获取到的控制器和方法,如果没有,就提示该用户没有权限,如果有就进行下一步操作.
20.怎么保证促销商品不会超卖?
答:这个问题是我们当时开发时遇到的一个难点，超卖的原因主要是下的订单的数目和我们要促销的商品的数目不一致导致的，每次总是订单的数比我们的促销商品的数目要多，当时我们的小组讨论了好久，给出了好几个方案来实现：
第一种方案：①在每次下订单前我们判断促销商品的数量够不够，不够不允许下订单，更改库存量时加上一个条件，只更改商品库存大于0的商品的库存，当时我们使用ab进行压力测试，当并发超过500，访问量超过2000时，还是会出现超卖现象。所以被我们否定了。
第二种方案：②使用mysql的事务加排他锁来解决，首先我们选择数据库的存储引擎为innoDB，使用的是排他锁实现的，刚开始的时候我们测试了下共享锁，发现还是会出现超卖的现象。有个问题是，当我们进行高并发测试时，对数据库的性能影响很大，导致数据库的压力很大，最终也被我们否定了。
第三种方案：③使用文件锁实现。当用户抢到一件促销商品后先触发文件锁，防止其他用户进入，该用户抢到促销品后再解开文件锁，放其他用户进行操作。这样可以解决超卖的问题，但是会导致文件得I/O开销很大。
最后我们使用了redis的队列来实现。将要促销的商品数量以队列的方式存入redis中，每当用户抢到一件促销商品则从队列中删除一个数据，确保商品不会超卖。这个操作起来很方便，而且效率极高，最终我们采取这种方式来实现
21.商城秒杀的实现?
答:抢购、秒杀是如今很常见的一个应用场景，主要需要解决的问题有两个：
1.高并发对数据库产生的压力
2 竞争状态下如何解决库存的正确减少（”超卖”问题）
对于第一个问题，已经很容易想到用缓存来处理抢购，避免直接操作数据库，例如使用Redis。第二个问题，我们可以使用redis队列来完成，把要秒杀的商品放入到队列中，因为pop操作是原子的，即使有很多用户同时到达，也是依次执行，文件锁和事务在高并发下性能下降很快，当然还要考虑其他方面的东西，比如抢购页面做成静态的，通过ajax调用接口，其中也可能会出现一个用户抢多次的情况，这时候需要再加上一个排队队列和抢购结果队列及库存队列。高并发情况下，将用户进入排队队列，用一个线程循环处理从排队队列取出一个用户，判断用户是否已在抢购结果队列，如果在，则已抢购，否则未抢购，库存减1，写数据库，将用户入结果队列。
22.购物车的实现原理?
答:购物车相当于现实中超市的购物车，不同的是一个是实体车，一个是虚拟车而已。用户可以在购物网站的不同页面之间跳转，以选购自己喜爱的商品，点击购买时，该商品就自动保存到你的购物车中，重复选购后，最后将选中的所有商品放在购物车中统一到付款台结账，这也是尽量让客户体验到现实生活中购物的感觉。服务器通过追踪每个用户的行动，以保证在结账时每件商品都物有其主。
主要涉及以下几点:
1、把商品添加到购物车，即订购
2、删除购物车中已定购的商品
3、修改购物车中某一本图书的订购数量
4、清空购物车
5、显示购物车中商品清单及数量、价格
实现购物车的关键在于服务器识别每一个用户并维持与他们的联系。但是HTTP协议是一种“无状态(Stateless)”的协议，因而服务器不能记住是谁在购买商品，当把商品加入购物车时，服务器也不知道购物车里原先有些什么，使得用户在不同页面间跳转时购物车无法“随身携带”，这都给购物车的实现造成了一定的困难。
目前购物车的实现主要是通过cookie、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是推荐用法，实际应用最为合适
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和我们通过算法算的值相同，证明是一个正常的接口请求，我们才会返回相应的接口数据。
30.用户不登录，把商品加入购物车是怎么实现的?
答:用户在不登录的情况下，可以把要购买商品的信息（如商品的ID，商品的价格、商品的sku_id,购买数量等关键数据）存到COOKIE里面，当登陆的情况下。把COOKIE里面的内容存到数据库，并清除cookie中的数据。
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 . echo '1'.print(2)+3
如上所示。结果为什么会是511呢？
这个结果的计算分为三步来理解：
首先计算的是 右边print(2)+3，这个你可以直接理解成print(2+3),得到的结果是5。而print是一个函数， 它的返回值总是1。
第二步就是echo '1'.print('结果')(返回值是1)，因此会得到11的结果。
第三步就是将之前计算的结果进行连接，并最终进行输出，得到的结果就是511了。
类似的，可以解释为什么echo '2' . print(2) + 3;的结果是521，
echo '1' . (print '2') + 3;结果是214
