No.0

算法类

1.快速排序算法 
2.树的非递归后序排序算法 
3.希尔排序 
4.冒泡排序 
5.链表和链表转向 
6.其余

 

设计模式

1.单例模式 
2.工厂模式 
3.抽象工厂模式 
4.面向对象设计，ooa，ood，oop

 

PHP

1.PHP FastCGI 
2.php-fpm

web server（好比说nginx）只是内容的分发者。好比，若是请求/index.html，那么web server会去文件系统中找到这个文件，发送给浏览器，这里分发的是静态数据。好了，若是如今请求的是/index.php，
根据配置文件，nginx知道这个不是静态文件，须要去找PHP解析器来处理，那么他会把这个请求简单处理后交给PHP解析器。Nginx会传哪些数据给PHP解析器呢？url要有吧，查询字符串也得有吧，POST数据也要有，
HTTP header不能少吧，好的，CGI就是规定要传哪些数据、以什么样的格式传递给后方处理这个请求的协议。仔细想一想，你在PHP代码中使用的用户从哪里来的。
当web server收到/index.php这个请求后，会启动对应的CGI程序，这里就是PHP的解析器。接下来PHP解析器会解析php.ini文件，初始化执行环境，而后处理请求，再以规定CGI规定的格式返回处理后的结果，退出进程。
web server再把结果返回给浏览器。 提升性能，那么CGI程序的性能问题在哪呢？"PHP解析器会解析php.ini文件，初始化执行环境"，就是这里了。标准的CGI对每一个请求都会执行这些步骤（不闲累啊！启动进程很累的说！），因此处理每一个时间的时间会比较长。
这明显不合理嘛！那么Fastcgi是怎么作的呢？首先，Fastcgi会先启一个master，解析配置文件，初始化执行环境，而后再启动多个worker。当请求过来时，master会传递给一个worker，而后当即能够接受下一个请求。
这样就避免了重复的劳动，效率天然是高。并且当worker不够用时，master能够根据配置预先启动几个worker等着；固然空闲worker太多时，也会停掉一些，这样就提升了性能，也节约了资源。这就是fastcgi的对进程的管理。 你们都知道，PHP的解释器是php-cgi。php-cgi只是个CGI程序，他本身自己只能解析请求，返回结果，不会进程管理（皇上，臣妾真的作不到啊！）因此就出现了一些可以调度php-cgi进程的程序，好比说由lighthttpd分离
出来的spawn-fcgi。好了PHP-FPM也是这么个东东，在长时间的发展后，逐渐获得了你们的承认（要知道，前几年你们但是抱怨PHP-FPM稳定性太差的），也愈来愈流行。

3.数组或字符串函数 
4.php命令行命令

php -l linux在当前目录检测php语法错误
php –v查看当前php的版本
php -m 会显示当前php加载的有效模块 php -i 则输出无html格式的phpinfo php -S localhost:80 php5.4以后提供测试服务器

5.file_get_content和fread区别

fread() 最大一次性能读取8k长度的字节数，因此不能一次性读取大文件去做下载。 优点在于，操做更加灵活，每次读取指定字节的内容，用于下载时方便控制服务器的流量。
file_get_contents() 函数把整个文件读入一个字符串中。 与 函数file()不一样的是 file_get_contents() 把文件读入一个字符串，而file()把整个文件读入一个数组中。
file_get_contents() 函数是用于将文件的内容读入到一个字符串中的首选方法。若是操做系统支持，还会使用内存映射技术来加强性能。在读取小文本内容到字符串变量时，这个函数最适合使用，简单，更快。

 

6.比较两个文件中url的不一样，而后问执行速度，文件大于300G

能够估计每一个文件的大小为5G*64=300G，远大于4G。因此不可能将其彻底加载到内存中处理。考虑采起分而治之的方法。遍历文件a，对每一个url求取hash(url)%1000，而后根据所得值将url分别存储到1000个小文件（设为a0,a1,...a999）当中。
这样每一个小文件的大小约为300M。遍历文件b，采起和a相同的方法将url分别存储到1000个小文件(b0,b1....b999)中。这样处理后，全部可能相同的url都在对应的小文件(a0 vs b0, a1 vs b1....a999 vs b999)当中，不对应的小文件（好比a0 vs b99）
不可能有相同的url。而后咱们只要求出1000对小文件中相同的url便可。 好比对于a0 vs b0，咱们能够遍历a0，将其中的url存储到hash_map当中。而后遍历b0，若是url在hash_map中，则说明此url在a和b中同时存在，保存到文件中便可。若是分红的小文件
不均匀，致使有些小文件太大（好比大于2G），能够考虑将这些太大的小文件再按相似的方法分红小小文件便可。

 

7.for与foreach那个更快 
8.是否读过源码 
9.PHP7的新特征 
10.PHP-FPM的进程控制方式

php-fpm进程管理的三种模式：
一、`ondemand`，在php-fpm启动的时候，不会给这个pool启动任何一个worker，是按需启动，当有链接过来才会启动。 优势：按流量需求建立，不浪费系统资源（在硬件如此便宜的时代，这个优势略显鸡肋） 缺点：因为php-fpm是短链接的，因此每次请求都会先创建链接，创建链接的过程必然会触发上图的执行步骤，因此，在大流量的系统上master进程会变得繁忙，占用系统cpu资源，不适合大流量环境的部署 二、`dynamic`，在php-fpm启动时，会初始启动一些worker，在运行过程当中动态调整worker数量，worker的数量受限于pm.max_children配置，同时受限全局配置process.max 优势：动态扩容，不浪费系统资源，master进程设置的1秒定时器对系统的影响忽略不计； 缺点：若是全部worker都在工做，新的请求到来只能等待master在1秒定时器内再新建一个worker，这时可能最长等待1s； 三、`static`,php-fpm启动采用固定大小数量的worker，在运行期间也不会扩容，虽然也有1秒的定时器，仅限于统计一些状态信息，例如空闲worker个数，活动worker个数，网络链接队列长度等信息。

11.高并发等PHP的原理 
12.php底层实现

 

数据库

1.设计分表（基因法） 

 
2.数据库最左前缀原则 
3.Mysql集群 
4.Redis的五种对象类型及其底层实现(跳跃表) 
5.MySQL双机双备 
6.分表，系统运行时如何修改表结构

1 建立一个和你要执行 alter 操做的表同样的空表结构。
2 执行表结构修改，而后从原表中的数据到copy到 表结构修改后的表， 3 在原表上建立触发器将 copy 数据的过程当中，在原表的更新操做 更新到新表. 注意:若是表中已经定义了触发器这个工具就不能工做了。 4 copy 完成之后，用rename table 新表代替原表，默认删除原表。

7.Redis的持久化机制

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘(默认)。
优点：
1、一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这样很是方便进行备份。好比你可能打算没1天归档一些数据。 方便备份，咱们能够很容易的将一个一个RDB文件移动到其余的存储介质上 2、RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。 三、RDB 能够最大化 Redis 的性能：父进程在保存 RDB 文件时惟一要作的就是 fork 出一个子进程，而后这个子进程就会处理接下来的全部保存工做，父进程无须执行任何磁盘 I/O 操做。 劣势： 一、若是你须要尽可能避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 容许你设置不一样的保存点（save point）来控制保存 RDB 文件的频率， 可是， 由于RDB 文件须要保存整个数据集的状态， 因此它并非一个轻松的操做。
 所以你可能会至少 5 分钟才保存一次 RDB 文件。 在这种状况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。 2、每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工做。 在数据集比较庞大时， fork() 可能会很是耗时，形成服务器在某某毫秒内中止处理客户端； 若是数据集很是巨大，而且 CPU 时间很是紧张
的话，那么这种中止时间甚至可能会长达整整一秒。 虽然 AOF 重写也须要进行 fork() ，但不管 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。 AOF，redis会将每个收到的写命令都经过write函数追加到文件中(默认是 appendonly.aof)。 优点 1、使用 AOF 持久化会让 Redis 变得很是耐久（much more durable）：你能够设置不一样的 fsync 策略，好比无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，
Redis 仍然能够保持良好的性能，而且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，因此主线程能够继续努力地处理命令请求）。 二、AOF 文件是一个只进行追加操做的日志文件（append only log）， 所以对 AOF 文件的写入不须要进行 seek ， 即便日志由于某些缘由而包含了未写入完整的命令（好比写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具
也能够轻易地修复这种问题。 3、Redis 能够在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操做是绝对安全的，由于 Redis 在建立新 AOF 文件的过程当中，会继续将命令追加到现
有的 AOF 文件里面，即便重写过程当中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件建立完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操做。 3、AOF 文件有序地保存了对数据库执行的全部写入操做， 这些写入操做以 Redis 协议的格式保存， 所以 AOF 文件的内容很是容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也很是简单： 举个例子， 若是你
不当心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要中止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就能够将数据集恢复到 FLUSHALL 执行以前的状态。 劣势 1、对于相同的数据集来讲，AOF 文件的体积一般要大于 RDB 文件的体积。 2、根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在通常状况下， 每秒 fsync 的性能依然很是高， 而关闭 fsync 可让 AOF 的速度和 RDB 同样快， 即便在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 能够提供
更有保证的最大延迟时间（latency）。 三、AOF 在过去曾经发生过这样的 bug ： 由于个别命令的缘由，致使 AOF 文件在从新载入时，没法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引发过这样的 bug 。） 测试套件里为这种状况添加了测试： 它们会
自动生成随机的、复杂的数据集， 并经过从新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 可是对比来讲， RDB 几乎是不可能出现这种 bug 的。

8.数据库中事务的四大特性

原子性（全部操做要么所有成功，要么所有失败回滚）
一致性 (一个事务执行以前和执行以后都必须处于一致性状态)
隔离性 (隔离性是当多个用户并发访问数据库时, 多个并发事务之间要相互隔离) 持久性 (持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即使是在数据库系统遇到故障的状况下也不会丢失提交事务的操做)

9.不考虑隔离性会出现的问题

脏读
　　脏读是指在一个事务处理过程里读取了另外一个未提交的事务中的数据。
不可重复读
　　不可重复读是指在对于数据库中的某个数据，一个事务范围内屡次查询却返回了不一样的数据值，这是因为在查询间隔，被另外一个事务修改并提交了
虚读(幻读)
　　幻读是事务非独立执行时发生的一种现象。例如事务T1对一个表中全部的行的某个数据项作了从“1”修改成“2”的操做，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值仍是为“1”而且提交给数据库。
　　而操做事务T1的用户若是再查看刚刚修改的数据，会发现还有一行没有修改，其实这行是从事务T2中添加的，就好像产生幻觉同样，这就是发生了幻读。

 

10.MySQL数据库为咱们提供的四种隔离级别

Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。（锁表）
Repeatable read (可重复读)：可避免脏读、不可重复读的发生。
Read committed (读已提交)：可避免脏读的发生。（一个事务只能看见已经提交事务所作的改变）
Read uncommitted (读未提交)：最低级别，任何状况都没法保证。（脏读）
在MySQL数据库中默认的隔离级别为Repeatable read (可重复读)
可重复读隔离级别是最严格的隔离级别。在该隔离级别下，一个事务的影响彻底与其余并发事务隔离，脏读、不可重复的读、幻像读现象都不会发生。当使用可重复读隔离级别时，在事务执行期间会锁定该事务以任何方式引用的全部行。
所以，若是在同一个事务中发出同一个SELECT语句两次或更屡次，那么产生的结果数据集老是相同的。所以，使用可重复读隔离级别的事务能够屡次检索同一行集，并对它们执行任意操做，直到提交或回滚操做终止该事务。可是，在事务
存在期间，不容许其余事务执行会影响这个事务正在访问的任何行的插入、更新或删除操做。为了确保这种行为不会发生，锁定该事务所引用的每一行-- 而不是仅锁定被实际检索或修改的那些行。所以，若是一个事务扫描了1000行，但
只检索10行，那么它所扫描的1000行(而不只是被检索的10行)都会被锁定

 

11.快速找到MySQL语句是否命中索引（EXPLAIN）

 

其余

1.http code

449
    出现499的缘由大致都是说服务端处理时间过长，客户端主动关闭了链接；upstream_response_time和request_time过长；客户端请求速度过快，触发了nginx保护机制，直接返回499状态码；第二种状况就是客户端主动关闭了链接；证书错误
    解决方式：
    proxy_ignore_client_abort on;# 告诉nginx不要主动关闭链接
    proxy_connect_timeout 600; proxy_read_timeout 600; proxy_send_timeout 600; 502 502优化，php-cgi进程数不够用、php执行时间长、或者是php-cgi进程死掉，都会出现502错误 a、查看当前的PHP FastCGI进程数是否够用netstat -anpo | grep "php-cgi"| wc -l 若是实际使用的“FastCGI进程数”接近预设的“FastCGI进程数”，那么，说明“FastCGI进程数”不够用，须要增大。 b、部分PHP程序的执行时间超过了Nginx的等待时间 fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; c、max-children和max-requests php-fpm有一个参数 max_requests，该参数指明了，每一个children最多处理多少个请求后便会被关闭，默认的设置是500。由于php是把请求轮询给每一个children，在大流量下，每一个childre到达max_requests所用的时间都差很少，这样就形成全部的
　　children基本上在同一时间被关闭。在这期间，nginx没法将php文件转交给php-fpm处理，因此cpu会降至很低(不用处理php，更不用执行sql)，而负载会升至很高(关闭和开启children、nginx等待php-fpm)，网卡流量也降至很低(nginx没法生成数据传输给客户端) 增长children的数量，而且将 max_requests 设置为0或者一个比较大的值 d、增长缓冲区容量大小 大意是nginx缓冲区有一个bug形成的,增长了缓冲区容量大小设置 e、request_terminate_timeout 若是主要是在一些post或者数据库操做的时候出现502这种状况，而不是在静态页面操做中常见，那么能够查看一下php-fpm.conf设置中的一项：request_terminate_timeout 这个值是max_execution_time，就是fast-cgi的执行脚本时间。 0s为关闭，就是无限执行下去。 优化fastcgi中，还能够改改这个值5s 看看效果。 504 错误通常是与nginx.conf配置有关了。主要与如下几个参数有关：fastcgi_connect_timeout、fastcgi_send_timeout、fastcgi_read_timeout、fastcgi_buffer_size、fastcgi_buffers、fastcgi_busy_buffers_size、fastcgi_temp_file_write_size、
fastcgi_intercept_errors。特别是前三个超时时间。若是fastcgi缓冲区过小会致使fastcgi进程被挂起从而演变为504错误。 首先，谈谈499，它区别于500+系列，是Nginx端返回的，是客户端（即链接nginx的前段客户）主动断开链接。 500 502 504 都是后台服务错误致使。 500:很明显的程序内部错误，很常见的出现是因为程序的内部语法逻辑出错致使。 502:Bad gateway!常出现的一种场景，好比咱们用nginx作代理，当upstream到后端的某一个服务，这个服务没任何响应。nginx就会return 502的响应。 504:Gareway timeout! 表示后端的服务能接收请求，可是迟迟未能完成整个代码逻辑，后台服务只能主动超时断开请求，这个时候return 504.

2.http1.0和1.1区别

一、HTTP 1.1支持长链接（PersistentConnection）和请求的流水线（Pipelining）处理
Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持链接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭链接。HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。在一个TCP链接上能够传送多个HTTP请求和响应，减小了创建和关闭链接的消耗和延迟。 2.HTTP 1.1增长host字段 随着虚拟主机技术的发展，在一台物理服务器上能够存在多个虚拟主机，HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中若是没有Host头域会报告一个错误（400 Bad Request）。 三、100(Continue) Status(节约带宽) 客户端事先发送一个只带头域的请求，若是服务器由于权限拒绝了请求，就回送响应码401（Unauthorized） 四、HTTP/1.1中引入了Chunked transfer-coding来解决上面这个问题，发送方将消息分割成若干个任意大小的数据块，每一个数据块在发送时都会附上块的长度，最后用一个零长度的块做为消息结束的标志。这种方法容许发送方只缓冲消息的一个片断，避免缓冲整个消息带来的过载。 五、HTTP/1.1在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不须要直接抛弃stale对象，而是与源服务器进行从新激活（revalidation）。

3.http和https区别

1、https协议须要到ca申请证书，通常免费证书较少，于是须要必定费用。
2、http是超文本传输协议，信息是明文传输，https则是具备安全性的ssl加密传输协议。 3、http和https使用的是彻底不一样的链接方式，用的端口也不同，前者是80，后者是443。 四、http的链接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。 HTTPS的工做原理： （1）客户使用https的URL访问Web服务器，要求与Web服务器创建SSL链接。 （2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。 （3）客户端的浏览器与Web服务器开始协商SSL链接的安全等级，也就是信息加密的等级。 （4）客户端的浏览器根据双方赞成的安全等级，创建会话密钥，而后利用网站的公钥将会话密钥加密，并传送给网站。 （5）Web服务器利用本身的私钥解密出会话密钥。 （6）Web服务器利用会话密钥加密与客户端之间的通讯。 HTTPS的优势： （1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器； （2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程当中不被窃取、改变，确保数据的完整性。 （3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增长了中间人攻击的成本。 （4）谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。 HTTPS的缺点： （1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增长10%到20%的耗电； （2）HTTPS链接缓存不如HTTP高效，会增长数据开销和功耗，甚至已有的安全措施也会所以而受到影响； （3）SSL证书须要钱，功能越强大的证书费用越高，我的网站、小网站没有必要通常不会用。 （4）SSL证书一般须要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。 （5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么做用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家能够控制CA根证书的状况下，中间人攻击同样可行。

4.进程之间如何通讯

1无名管道( pipe )：管道是一种半双工的通讯方式，数据只能单向流动，并且只能在具备亲缘关系的进程间使用。进程的亲缘关系一般是指父子进程关系。
2高级管道(popen)：将另外一个程序当作一个新的进程在当前程序进程中启动，则它算是当前程序的子进程，这种方式咱们成为高级管道方式。 3有名管道 (named pipe) ： 有名管道也是半双工的通讯方式，可是它容许无亲缘关系进程间的通讯。 4消息队列( message queue ) ： 消息队列是由消息的链表，存放在内核中并由消息队列标识符标识。消息队列克服了信号传递信息少、管道只能承载无格式字节流以及缓冲区大小受限等缺点。 5信号量( semophore ) ： 信号量是一个计数器，能够用来控制多个进程对共享资源的访问。它常做为一种锁机制，防止某进程正在访问共享资源时，其余进程也访问该资源。所以，主要做为进程间以及同一进程内不一样线程之间的同步手段。 6信号 ( sinal ) ： 信号是一种比较复杂的通讯方式，用于通知接收进程某个事件已经发生。 7共享内存( shared memory ) ：共享内存就是映射一段能被其余进程所访问的内存，这段共享内存由一个进程建立，但多个进程均可以访问。共享内存是最快的 IPC 方式，它是针对其余进程间通讯方式运行效率低而专门设计的。它每每与其余通讯机制，如信号两，配合使用，来实现进程间的同步和通讯。 8套接字( socket ) ： 套解口也是一种进程间通讯机制，与其余通讯机制不一样的是，它可用于不一样机器间的进程通讯。

5.消息中间件（kafka等） 
6.nginx和apache的区别

nginx相对于apache的优势： 
轻量级，一样起web 服务，比apache 占用更少的内存及资源 
抗并发，nginx 处理请求是异步非阻塞的，而apache 则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能 
Nginx自己就是一个反向代理服务器
高度模块化的设计，编写模块相对简单 
社区活跃，各类高性能模块出品迅速啊 
apache 相对于nginx 的优势： 
rewrite ，比nginx 的rewrite 强大 
模块超多，基本想到的均可以找到 
少bug ，nginx 的bug 相对较多 
超稳定 
最核心的区别在于apache是同步多进程模型，一个链接对应一个进程；nginx是异步的，多个链接（万级别）能够对应一个进程 

7.break，last的区别 8.负载均衡的实现 9.11种运行模式 10.nginx-lua插件