Php使用require包含文件时将被包含的文件当成当前文件的一个组成部分,如果被包含的文件中有语法错误或者被包含的文件不存在,则php脚本将不再执行,并提示错误。
Php使用include包含文件时相当于指定了这个文件的路径,当被包含的文件有语法错误或者被包含的文件不存在时给出警告,不影响本身脚本的运行。
Include在包含文件时可以判断文件是否包含,而require则不管任何情况都包含进来。
Require的效率比require_once的效率更高,因为require_once在包含文件时要进行判断文件是否已经被包含。
2. Cookie和session的区别,禁止了cookie后session能正常使用吗?session的缺点是什么?session在服务器端是存在哪里的?是共有的还是私有的?
COOKIE保存在客户端,用户通过手段可以进行修改,不安全,单个cookie允许的最大值是3k。而SESSION保存在服务器端,相对比较安全,大小没有限制。禁用了cookie之session不能正常使用。
Session的缺点:保存在服务器端,每次读取都从服务器进行读取,对服务器有资源消耗。
Session保存在服务器端的文件或中,默认保存在文件中,文件路径由php配置文件的session.save_path指定。
3. 怎么防止sql注入?
或者通过系统函数:addslashes(需要被过滤的内容)来进行过滤。
3、SQL语句书写的时候尽量不要省略小引号(tab键上面那个)和单引号
4、提高数据库命名技巧,对于一些重要的字段根据程序的特点命名,取不易被猜到的
5、对于常用的方法加以封装,避免直接暴漏SQL语句
Magic_quotes_gpc=off;默认是关闭的,它打开后将自动把用户提交的sql语句的查询进行转换,把'转为\',这对防止sql注入有重大作用。
关闭错误提示信息,将错误信息写到系统日志。
4. 数据库索引有几类,分别是什么?什么时候该用索引
普通索引、主键索引、唯一索引
并非所有的数据库都以相同的方式使用索引,作为通用规则,只有当经常查询列中的数据时才需要在表上创建索引。
5. 引用传值和非引用传值的区别,什么时候该用引用传值?什么时候该用非引用传值?
按值传递:函数范围内对值的改变在函数外都会被忽略。
按引用传递:函数范围内对值的任何改变在函数外也将反应出这些修改。
按值传递时,php必须复制值,如果操作的是大型的对象和字符串,这将是一个代价很大的操作。按引用传递不需要复制值,因此对性能的提高有好处。
当需要在函数内改变源变量的值时用引用传递,如果不想改变原变量的值用传值。
6. 写几个魔术方法并说明作用?
__call()当调用不存在的方法时会自动调用的方法
__autoload()在实例化一个尚未被定义的类是会自动调用次方法来加载类文件
__set()当给未定义的变量赋值时会自动调用的方法
__get()当获取未定义变量的值时会自动调用的方法
__construct()构造方法,实例化类时自动调用的方法
__destroy()销毁对象时自动调用的方法
__unset()当对一个未定义变量调用unset()时自动调用的方法
__isset()当对一个未定义变量调用isset()方法时自动调用的方法
__tostring()当输出一个对象时自动调用的方法
它们都是PHP预定义变量。
$_GET用来获取get方式提交的值
$_FILE用来获取上传文件表单的值
8. 数组中下标最好是什么类型的,为什么?
数组的下标最好是数字类型的,数字类型的处理速度快。
++i效率比i++的效率更高,因为++i少了一个返回i的过程。
Magic_quotes_runtime()是php中的函数,如果参数为true则会数据库中取出来的单引号、双引号、反斜线自动加上反斜杠进行转义。
Echo() 是PHP语法,可以输出多个值,不能输出数组。
Print() 是php的语言结构,可以输出单个简单类型的变量值。
Print_r() 是php函数,可以打印出复杂类型变量的值,如数组,对象。
12.谈谈你对Mvc的认识
MVC是一种设计模式,强制使输入、处理、输出分开,MVC的三个核心部分:M模型,V视图,C控制器。
视图就是用户看到并与之交互的界面。
模型就是程序的数据业务规则。
控制器接收用户的数组调用模型和视图去完成用户需求。
使用MVC的优点:低耦合、高重用性、较低的生命周期成本、快速开发部署、可维护性、可扩展性,有利于软件工程化管理。
MVC的缺点:没有明确的定义,完全理解并不容易。小型项目不适合用MVC。
13.框架中什么是单一入口和多入口,单一入口的优缺点
多入口就是通过访问不同的文件来完成用户请求。
单一入口只web程序所有的请求都指向一个脚本文件的。
单一入口更容易控制权限,方便对http请求可以进行安全性检查。
缺点:URL看起来不那么美观,特别是对来说不友好。
14.打印一个用‘.’链接的字符串时候,还可以用什么代替‘.’链接效率更高些?
可以用,代替.,效率更高。
200是请求成功,404是文件未找到,502是服务器内部错误。
16.编写一个自定义函数提取这段路径的的后缀名。
17.你对Memcach的理解,优点有哪些?
Memcache是一种缓存技术,在一定的时间内将动态网页经过解析之后保存到文件,下次访问时动态网页就直接调用这个文件,而不必在重新访问数据库。使用memcache做缓存的好处是:提高网站的访问速度,减轻高并发时服务器的压力。
Memcache的优点:稳定、配置简单、多机分布式存储、速度快
在最初的时候,我们自认为应该使用自己熟悉的编程语言,因为我们是一个小团队,而且已经做了两项冒险的举动:将我们的大流量游戏平台和。
不过,最终,我们还是决定放弃PHP,转向Go。在这篇文章中,我们将解释为什么要这样做。我们还将分享一些微服务架构中有关数据库的观点。
微服务和PHP:错误的搭配
我们熟悉的语言是PHP,它驱动着我们现有的应用程序,有两个模糊的理由支撑着我们使用PHP:
这些听起来都很正确,但是当我们清楚地认识到PHP真的不是我们这个案例的正确选择时,我们很快就放弃了这些想法。
我们正在向着微服务架构迁移,因为我们希望这些大流量的基础架构(每日200万活跃用户)具备可扩展性。从长远来看,随着我们向1000万甚至更多用户发展的时候,我们的基础设施也应该能相应地进行扩大。
PHP无法满足这些需求,因为:
PHP的启动成本很高。 PHP一开始是为短生命周期脚本的运行而设计的,因此持久性并不是其原生特性。这意味着对于每个请求、数据库连接和类都必须实例化,这增加了不必要的开销。当然,这也是有办法解决的,例如通过PHP-FPM或Apache来创建连接池,或者绑定C以获得与Redis的长连接。但是,由于我们需要追求高性能,所以这些依赖让我们开始质疑PHP对于这个系统来说是否是一个合适的工具。
容器化的PHP是一个雷区。 PHP需要借助Nginx和PHP-FPM(或类似的软件)来进行进程管理和连接池管理。这意味着对于部署的每个微服务来说,PHP-FPM和Nginx必须同时运行。这既浪费了资源,又降低了效率。对运行在服务器上的PHP实例进行优化也是相当困难的,因为你需要同时熟悉PHP、PHP-FPM和Nginx的配置。我们无法想象在弹性Kubernetes环境上配置多个PHP栈的痛苦,我们甚至不知道在这同一台机器上还运行了其他什么东西。
对微服务来说,其复杂性存在于架构中,因为你正在处理的是一个复杂的交互系统。既然我们已经确定采用微服务架构,那么因为错误的选择了编程语言导致的消耗显然就不值得。
招聘的要求是什么?我们发现这个所谓的要求对于我们现在这种情况是毫无意义的。像微服务一样,我们认为开发人员应该是编程语言无关的。我们宁愿聘请一位聪明的并愿意为了完成工作而学习新的编程语言的开发人员,而不是一位坚持己见的专家。因此,从这个意义上来说,放弃PHP对我们来说是一种解放。
我们主要偏向使用Node.js和Golang这两种语言。在做了一些研究之后,我们最后决定放弃Node,使用Go。
那么为什么要使用Go呢?
性能: Go的二进制文件会生成一个长时间运行的进程,这意味着每个请求和数据库连接的启动成本很低。这使得Go在处理大量的并发请求时能保证极快的速度,因为Go语言(模块)。
Go可以编译出一个小巧便携的二进制文件。这使得Go非常适合在Docker容器中使用。部署我们的Go容器只需几秒钟,因为它们的体积很小(大多数是4-5MB),并且由于是静态链接,因此在容器内不需要OS或运行时依赖。例如,当使用Node Alpine Linux镜像时,我们的前端容器大约为55MB。
Go是类型严格的。这让代码中的内部通信更为可靠,也有助于在构建期间捕获异常,而不是在运行期间。
Go的工具链的规模很大。虽然工具是很多编程语言关注的问题,但Google从一开始就解决了这个问题,他提供了大量常用的工具作为语言安装时的一部分。
我们也考虑到Go有这些缺点:
然而,我们必须接受这一点:用Go程序确实需要花上一些功夫,但它能提高代码质量,并让我们能够时刻知道代码实际是如何运行的。
这并不是说所有的代码我们都用Go来写。对于服务器端渲染,我们使用Node,因为它允许我们在前端和后端之间共用代码逻辑。我们也可以使用Java来解决特定的问题,因为它已经存在了很长时间,并且拥有大量的库。我们希望能使用最合适的工具,对于大多数情况而言,Go是我们的首选。
当我们开始使用Go语言来编写我们的第一个服务时,我们也开始考虑数据库的选择。我们习惯了过去为我们服务的MySQL,但它经常会成为性能的瓶颈。
在我们的传统架构中,我们使用了大量的Redis来进行缓存,它的性能非常棒,因为它有效地减少了昂贵的连接数量。所以当我们开始在我们的新架构中探索数据库时,我们要探索一下NoSQL,来看看是否可以完全避免这些连接。
我们试用了这两个数据库:
MongoDB:因为我们非常好奇对于存储包含大量元数据的游戏数据而言,文件存储是否是一个好的解决方案。但是,缺点是:我们必须在Google Cloud上管理它,而且根据社区所说,它根本不能很好地进行扩展。
Cassandra:因为它是一个大家熟知的可以扩展的数据库,并被大流量平台Netflix和Reddit所使用。它的优点是:速度非常快,能线性扩展。不过,我们发现它的内容管理太复杂了。如果你知道该如何查询数据,那么Cassandra是挺好的。它适用于包含大量数据的分析服务,但是在敏捷产品设计环境中,产品变化频繁,Cassandra就是一个强大的野兽,对于大多数情况而言它太笨重了。
我们倾向于构建小型而又独立的服务,这些服务可以完成指定的工作,并且在需要的时候可以很轻松地进行升级或更换。
这就是为什么我们决定坚持使用MySQL作为我们的默认数据库的原因。我们已经使用MySQL很多年了,知道如何设计高性能的数据库方案。虽然它不能线性扩展,但现在还好,得益于微服务架构的模块化特性,应用程序负载可以分布在不同机器的不同微服务上,并且每个微服务都可以访问自己的和不同的数据库读副本(Read Replicas)。
让我们高兴的是,至今我们还没有过度设计。如果有某个服务确实需要Cassandra或其他数据库的话,那么没有什么可以阻止我们迁移这个服务。
那么为什么选用MySQL?主要是因为它可以在Google Cloud上进行管理,而在DevOps方面我们是务实的。我们想尝试试用Postgres,因为它是开源的,有一个强大的社区,并且。因此,如果Google Cloud上有了Alpha版本,我们也会研究一下。