PHP常见的面试题（1）

PHP常见的面试题（1）

Thinkphp框架中M和D的作用：

D方式在实例的时候会调用Model类，M方法不会去调用Model类！
D和M的区别主要在于：M方法不需要创建模型类文件，M方法不会读取模型类，所以默认情况下自动验证是无效的，但是可以通过动态赋值的方式实现而D方法必须有创建模型类。我们可以用下面两种方法去创建一个数据表的映射对象第一种：$Test?=?D('Test')第二种：$Test?=?new?Model('Test')虽然这两种都可以对数据进行select,insert,delete,udpate操作，在数据验证上有很大的不同，用第一种方式实例一个模型就会有数据检查功能，如果?title?没有填写的话就会提示?“请输入标题”?（这个是tp提供的一个自动验证功能，当然也需要在相应的model中定义好验证条件）；如果用第二种就没有了·····还有1个区别就是当用了$trueTableName后，必须用$test=d('test')，表示查询的是test表，如果用的是$test=m('test'),那么都表示查询的数据边是think_test。thinkphp2.0版本测试有如此上面的问题      通俗点说：D就是实例化一个基于Model文件的Model。M则是通过直接实例化Model方法（ThinkPHP基类）来动态的实例化一个Model对象，即使这个对应的Model文件不存在     A快速实例化Action类库B执行行为类C配置参数存取方法D快速实例化Model类库F快速简单文本数据存取方法L?语言参数存取方法M快速高性能实例化模型R快速远程调用Action类方法S快速缓存存取方法U?URL动态生成和重定向方法W?快速Widget输出方法?D函数实例化的是你当前项目的Lib/Model下面的模块。如果该模块不存在的话，直接返回实例化Model的对象(意义就与M()函数相同)。而M只返回，实例化Model的对象。它的$name参数作为数据库的表名来处理对数据库的操作。

memcache和redis区别：

1 Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
2 Redis支持数据的备份，即master-slave模式的数据备份。
3 Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
总结：
1.Redis使用最佳方式是全部数据in-memory。
2.Redis更多场景是作为Memcached的替代者来使用。
3.当需要除key/value之外的更多数据类型支持时，使用Redis更合适。
4.当存储的数据不能被剔除时，使用Redis更合适。

RBAC 权限节点

现在假设一个用户登陆本系统且这个用户为合法用户，那么在他登陆之后就可以根据用户角色表确定该用户的角色（这个角色可以是一个角色，也可以是多个角色）；然后再根据角色权限表可以最终确定该用户对那几个页面有某种具体的组合操作的权力。
狭义上的权限管理有了这5张表明显已经足够了，但是我们系统中存在一个功能树，树的节点是根据特定角色的权限来显示的，也就是说得加一个表功能树数据表，里面将页面对象与树的节点关联起来，当然并不是所有的页面都会与某一个节点对应，也不是所有的节点一定要对应于一个页面，可采用的是父节点加子节点的设计方式。
那么在用户登陆之后查找到了该用户对应的能操作的且存在于功能树结点中的页面，是不是就能够很顺利的显示出树呢？看来似乎还有个小问题需要解决掉！
因为一个用户可能对应于几个角色，好几个角色中显然也有可能存在对同一个页面有相同的操作权力，如果该页面是功能树的一个节点，在用户登陆之后要显示出树就得想办法去掉相同的节点。
在后台代码中我们可以做到这一点，具体做法肯定是把某用户所对应的所有角色的相关页面id号放入一个datatable（ado.net中一个具体对象，相当于一张表格）,然后去掉重复的页面，即id号相同的页面，然后再从功能树数据表中去查找这些页面的父节点生成一颗功能树。当然我们完全可以在数据库中在做一张表为角色功能树节点对应表，这样直接通过查找这张表格找出不重复的节点来生成树，这样就减少了很多后台逻辑，带来了很大的方便。

支付宝同步回调和异步回调

当一个支付请求被发送到支付渠道方，支付渠道会很快返回一个结果。但是这个结果，只是告诉你调用成功了，不是扣款成功，这叫同步调用。
很多新手会拿这个结果 当作支付成功了，那就会被坑死，结果就是支付成功率特别高，伴随着一堆无法解释的坏账率，
测试人员尤其要注意测试数据的篡改：金额，同步返回结果，订单号等。

同步请求参数里面会有一个回调地址，这个地址是支付渠道在扣款成功后调用的，这叫异步调用。
一般同步接口仅检查参数是否正确，签名是否无误等。异步接口才告诉你扣款结果。
一般异步接口有5秒以内的延迟。调用不成功会重试。有时候是这边成功了，但支付渠道侧没收到返回，于是会继续调。
当天的支付到第二天还在 被异步调用也都是正常的。这也是开发人员需要特别注意的地方，不要当做重复支付。
测试人员也要对重复回调进行测试，应只有一次有效。这还不是最坑的，一般 支付渠道侧，只有支付成功了才通知你。
要是支付失败了，压根儿都不告诉你。
另一方面，如何老收不到异步结果呢？那就得查查了。同步结果不可靠，异步调用不可靠，那怎么确定支付结果？最终的杀招就是查单了，
反查，一般支付渠道侧都 会提供反查接口，定时获取DB中待支付的订单调用支付渠道侧的反查接口，最终把支付渠道侧扣款成功的订单完成掉。

单点登录

1. 第一次登陆某个站：
a) 用户输入用户名+密码,向用户验证中心发送登录请求
b) 当前登录站点，通过webservice请求,用户验证中心验证用户名，密码的合法性。如果验证通过，则生成ticket，用于标识当前会话的用户
c) 将获取的用户数据和ticket返回给子站。如果验证不通过，则返回相应的错误状态码。
d) 根据上一步的webservice请求返回的结果，当前子站对用户进行登陆处理：如状态码表示成功的话，则当前站点通过本站cookie保存ticket，并本站记录用户的登录状态。状态码表示失败的话，则给用户相应的登录失败提示。
2. 登陆状态下，用户转到另一子站：
a) 通过本站cookie或session验证用户的登录状态：如验证通过，进入正常本站处理程序;否则户中心验证用户的登录状态(发送ticket到用户验证中心)，如验证通过，则对返回的用户信息进行本地的登录处理，否则表明用户未登录。

Cookie的作用域？什么时候用？

当我们给网站设置cookie时，大家有没有发现在网站的其他域名下也接收到了这些cookie。这些没用的cookie看似不占多少流量，但如果对一个日PV千万的站点来说，那浪费的资源就不是一点点了。因此在设置cookie时，对它的作用域一定要设置准确了。
Setcookie第五个参数$domain，因为它决定了cookie的作用域。

实现session的思路

1. 基于NFS的Session共享
NFS是Net FileSystem的简称，最早由Sun公司为解决Unix网络主机间的目录共享而研发。
这个方案实现最为简单，无需做过多的二次开发，仅需将共享目录服务器mount到各频道服务器的本地session目录即可，缺点是NFS依托于复杂的安全机制和文件系统，因此并发效率不高，尤其对于session这类高并发读写的小文件，会由于共享目录服务器的io-wait过高，最终拖累前端WEB应用程序的执行效率。
2. 基于数据库的Session共享
首选当然是大名鼎鼎的Mysql数据库，并且建议使用内存表Heap，提高session操作的读写效率。这个方案的实用性比较强，相信大家普遍在使用，它的缺点在于session的并发读写能力取决于Mysql数据库的性能，同时需要自己实现session淘汰逻辑，以便定时从数据表中更新、删除 session记录，当并发过高时容易出现表锁，虽然我们可以选择行级锁的表引擎，但不得不否认使用数据库存储Session还是有些杀鸡用牛刀的架势。
3. 基于Cookie的Session共享
这个方案我们可能比较陌生，但它在大型网站中还是比较普遍被使用。原理是将全站用户的Session信息加密、序列化后以Cookie的方式，统一种植在根域名下（如：.host.com），利用浏览器访问该根域名下的所有二级域名站点时，会传递与之域名对应的所有Cookie内容的特性，从而实现用户的Cookie化Session 在多服务间的共享访问。
这个方案的优点无需额外的服务器资源；缺点是由于受http协议头信心长度的限制，仅能够存储小部分的用户信息，同时Cookie化的 Session内容需要进行安全加解密（如：采用DES、RSA等进行明文加解密；再由MD5、SHA-1等算法进行防伪认证），另外它也会占用一定的带宽资源，因为浏览器会在请求当前域名下任何资源时将本地Cookie附加在http头中传递到服务器。
4. 基于Memcache的Session共享
Memcache由于是一款基于Libevent多路异步I/O技术的内存共享系统，简单的Key + Value数据存储模式使得代码逻辑小巧高效，因此在并发处理能力上占据了绝对优势，目前本人所经历的项目达到2000/秒 平均查询，并且服务器CPU消耗依然不到10%。
另外值得一提的是Memcache的内存hash表所特有的Expires数据过期淘汰机制，正好和Session的过期机制不谋而合，降低了过期Session数据删除的代码复杂度，对比“基于数据库的存储方案”，仅这块逻辑就给数据表产生巨大的查询压力。