站長資訊網(wǎng)本篇文章給大家整理分享28道PHP面試題（附答案分享），帶你梳理基礎(chǔ)知識，有一定的參考價值，有需要的朋友可以參考一下，希望對大家有所幫助。
過完年之后打算尋找新的工作機會，發(fā)現(xiàn)之前自己對于很多基礎(chǔ)的面試理解和學習不夠深刻，為了鼓勵自己持續(xù)前進所以最近開始在論壇和搜索引擎上開始學習和總結(jié)相關(guān)知識，其中有一些題目時論壇里面一些前輩分享過的題目或者答案，還有一部分時自己最近面試遇到的問題，基于自己的理解和前輩們的分享歸檔了一部分，所以分享出來，希望對其他的小伙伴們也有幫助，同時也希望能收到大佬們對于理解有誤的地方的指導，最近一段時間會持續(xù)更新
本論壇的文章參考的比較多，優(yōu)先列出來大家參考，如下： https://learnku.com/articles/63520 https://learnku.com/php/t/47623 https://learnku.com/articles/28772
一、php 數(shù)組底層實現(xiàn)原理
1、底層實現(xiàn)是通過散列表（hash table） + 雙向鏈表（解決hash沖突）
-
hashtable：將不同的關(guān)鍵字（key）通過映射函數(shù)計算得到散列值（Bucket->h） 從而直接索引到對應(yīng)的Bucket
-
hash表保存當前循環(huán)的指針，所以foreach 比for更快
-
Bucket：保存數(shù)組元素的key和value，以及散列值h
2、如何保證有序性
-
1. 散列函數(shù)和元素數(shù)組（Bucket）中間添加一層大小和存儲元素數(shù)組相同的映射表。
-
2. 用于存儲元素在實際存儲數(shù)組中的下標
-
3. 元素按照映射表的先后順序插入實際存儲數(shù)組中
-
4. 映射表只是原理上的思路，實際上并不會有實際的映射表，而是初始化的時候分配Bucket內(nèi)存的同時，還會分配相同數(shù)量的 uint32_t 大小的空間，然后將 arData 偏移到存儲元素數(shù)組的位置。
3、解決hash重復(fù)(php使用的鏈表法)：
-
1. 鏈表法:不同關(guān)鍵字指向同一個單元時，使用鏈表保存關(guān)鍵字（遍歷鏈表匹配key）
-
2. 開放尋址法：當關(guān)鍵字指向已經(jīng)存在數(shù)據(jù)的單元的時候，繼續(xù)尋找其他單元，直到找到可用單元（占用其他單元位置，更容易出現(xiàn)hash沖突，性能下降）
4、基礎(chǔ)知識
-
鏈表：隊列、棧、雙向鏈表、
-
鏈表 ：元素 + 指向下一元素的指針
-
雙向鏈表：指向上一元素的指針 + 元素 + 指向下一元素的指針
參考：
算法的時間與空間復(fù)雜度（一看就懂）
https://zhuanlan.zhihu.com/p/50479555
LeetCode0：學習算法必備知識：時間復(fù)雜度與空間復(fù)雜度的計算
https://cloud.tencent.com/developer/article/1769988
二、冒泡排序的時間復(fù)雜度和空間復(fù)雜度
1、代碼實現(xiàn)
$arr = [2, 4, 1, 5, 3, 6]; for ($i = 0; $i < (count($arr)); $i++) { for ($j = $i + 1; $j < (count($arr)); $j++) { if ($arr[$i] <= $arr[$j]) { $temp = $arr[$i]; $arr[$i] = $arr[$j]; $arr[$j] = $temp; } } } result : [6,5,4,3,2,1]
2、計算原理
-
第一輪：將數(shù)組的第一個元素和其他所有的元素進行比較，哪個元素更大，就換順序，從而冒泡出第一大（最大）的元素
-
第一輪：將數(shù)組的第二個元素和其他所有的元素進行比較（第一大已經(jīng)篩選出來不用繼續(xù)比較了），哪個元素更大，就換順序，從而冒泡出第二大的元素
-
… 依次類推，冒泡從大到小排序的數(shù)組
平均時間復(fù)雜度：O(n^2) ；
最優(yōu)時間復(fù)雜度：O(n) ，需要加判斷，第一次循環(huán)如果一次都沒有交換就直接跳出循環(huán)
空間復(fù)雜度：O(1)，交換元素的時候的臨時變量占用的空間
最優(yōu)空間復(fù)雜度：O(1)，排好序，不需要交換位置
3、時間復(fù)雜度和空間復(fù)雜度
時間復(fù)雜度：全程為漸進時間復(fù)雜度，估算對處理器的使用效率（描述算法的效率趨勢，并不是指算法具體使用的時間，因為不同機器的性能不一致，只是一種效率計算的通用方法）
表示方法：大O符號表示法
復(fù)雜度量級：
-
常數(shù)階O(1)
-
線性階O(n)
-
平方階O(n2)
-
立方階O(n3)
-
K次方階O(n^k)
-
指數(shù)階(2^n)
-
對數(shù)階O(logN)
-
線性對數(shù)階O(nlogN)
時間復(fù)制類型：
-
最好時間復(fù)雜度
-
最壞時間復(fù)雜度
-
平均時間復(fù)雜度
-
均攤時間復(fù)雜度
空間復(fù)雜度：全程漸進空間復(fù)雜度，估算對計算機內(nèi)存的使用程度（描述算法占用的存儲空間的趨勢，不是實際占用空間，同上）
參考：
算法的時間與空間復(fù)雜度（一看就懂）
https://zhuanlan.zhihu.com/p/50479555
LeetCode0：學習算法必備知識：時間復(fù)雜度與空間復(fù)雜度的計算
https://cloud.tencent.com/developer/article/1769988
三、網(wǎng)絡(luò)七層協(xié)議及 TCP 和 TCP
應(yīng)用層、表示層、會話層、傳輸層、網(wǎng)絡(luò)層、（數(shù)據(jù)）鏈路層、物理層
記憶套路：
首字：應(yīng)表會傳（物鏈網(wǎng)）
第一個字：應(yīng)用層（出現(xiàn)次數(shù)多，易憶）
前四個正向：應(yīng)表 – 會傳
后三個反向：物聯(lián)網(wǎng)諧音比網(wǎng)鏈物更好記
四、TCP 和 UDP 的特點和區(qū)別
1、都是屬于傳輸層協(xié)議
2、TCP
-
面向連接，所以只能一對一
-
面向字節(jié)流傳輸
-
數(shù)據(jù)可靠，不丟失
-
全雙工通信
3、UDP（根據(jù)TCP特點反記）
-
無連接，支持一對一，一對多，多對多
-
面向保溫傳輸
-
首部開銷小，數(shù)據(jù)不一定可靠但是速度更快
參考：
github:colinlet/PHP-Interview-QA =>PHP 面試問答 網(wǎng)絡(luò)篇
https://github.com/colinlet/PHP-Interview-QA/blob/master/docs/01.網(wǎng)絡(luò).md#1-計算機網(wǎng)絡(luò)體系結(jié)構(gòu)
五、TCP 的三次握手和四次揮手
1、三次握手：
-
1）第一次：客戶端發(fā)送SYN = 1,seq = client_isn
作用：
客戶端：無
服務(wù)端：確認自己的接收功能和客戶端的發(fā)送功能
-
2）第二次：服務(wù)端發(fā)送SYN = 1,seq = server_isn,ACK =client_isn +1
作用：
客戶端：確認自己發(fā)送和接收都正常，確認服務(wù)端的接收和發(fā)送正常
服務(wù)端：確認自己的接收正常，確認服務(wù)端的發(fā)送正常（這時候服務(wù)端還不能確認客戶端接收是否正常）
-
3）第三次：客戶端發(fā)送SYN = 0, ACK = server_isn+1,seq =client_isn+1
作用：雙方確認互相的接收和發(fā)送正常，建立連接
2、四次揮手
-
1）第一次:客戶端發(fā)送FIN
作用：告訴服務(wù)端我沒有數(shù)據(jù)發(fā)送了（但是還能接收數(shù)據(jù)）
-
2）第二次：服務(wù)端發(fā)送ACK
作用：告訴客戶端收到請求了，可能服務(wù)端可能還有數(shù)據(jù)需要發(fā)送，所以客戶端收到進入FIN_WAIT狀態(tài)，等服務(wù)端數(shù)據(jù)傳輸完之后發(fā)送FIN
-
3）第三次：服務(wù)端發(fā)送FIN
作用：服務(wù)端告訴客戶端我發(fā)送完了，可以關(guān)閉連接了。
-
4）第四次:客戶端發(fā)送ACK
作用：客戶端收到FIN之后，擔心服務(wù)端不知道要關(guān)閉，所以發(fā)送一個ACK，進入TIME_WAIT，等待2MSL之后如果沒有收到回復(fù)，證明服務(wù)端已經(jīng)關(guān)閉了，這時候客戶端也關(guān)閉連接。
注意：
-
當收到對方的FIN報文時，僅僅表示對方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)
-
最后需要等待2MSL是因為網(wǎng)絡(luò)是不可靠的，如果服務(wù)端沒有收到最后一次ACK,服務(wù)端會重新放FIN包然后等客戶端再次發(fā)送ACK包然后關(guān)閉（所以客戶端最后發(fā)送ACK之后不能立即關(guān)閉連接）
參考：
github:colinlet/PHP-Interview-QA =>PHP 面試問答 網(wǎng)絡(luò)篇
https://github.com/colinlet/PHP-Interview-QA/blob/master/docs/01.網(wǎng)絡(luò).md#1-計算機網(wǎng)絡(luò)體系結(jié)構(gòu)
TCP 協(xié)議中的三次握手和四次揮手 (圖解)
https://blog.csdn.net/whuslei/article/details/6667471
“三次握手，四次揮手” 你真的懂嗎？
https://zhuanlan.zhihu.com/p/53374516
TCP 的特性
https://hit-alibaba.github.io/interview/basic/network/TCP.html
六、HTTP 狀態(tài)碼
1、狀態(tài)碼分類
-
– 1xx：信息，服務(wù)器收到請求，需要請求者繼續(xù)操作
-
– 2xx：成功
-
– 3xx：重定向
-
– 4xx：客戶端錯誤
-
– 5xx：服務(wù)端錯誤
2、常用狀態(tài)碼
-
200：請求成功
-
301：永久重定向
-
302：臨時移動
-
400 bad request：客戶端請求語法錯誤
-
401 unauthorized：客戶端沒有權(quán)限
-
403 forbidden：服務(wù)器拒絕客戶端請求
-
404 not found：客戶端請求資源不存在
-
500 Internal Server Eerro：服務(wù)器內(nèi)部錯誤
-
502 bad gateway：作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請求時，從上游服務(wù)器接收到無效的響應(yīng)
-
503 Service Unavailable 超載或系統(tǒng)維護
-
504 Gateway timeout：網(wǎng)關(guān)超時
3、502 的原因及解決方法
原因：nginx將請求提交給網(wǎng)關(guān)（php-fpm）處理異常導致
1）fastcgi 緩沖區(qū)設(shè)置過小
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
2）php-cgi的進程數(shù)設(shè)置過少
查看FastCgi進程數(shù)：netstat -anpo | grep "php-cgi"| wc -l
調(diào)整參數(shù)最大子進程數(shù)：max_children
一般按照單個進程20M計算需要需要設(shè)置的子進程數(shù)
3）max_requests（內(nèi)存溢出或頻繁重啟）
參數(shù)指明每個children最多能處理的請求數(shù)量，到達最大值之后會重啟children。
設(shè)置過小可能導致頻繁重啟children：
php將請求輪詢給每個children，在大流量的場景下，每一個children 到達最大值的時間差不多，如果設(shè)置過小可能多個children 在同一時間關(guān)閉，nginx無法將請求轉(zhuǎn)發(fā)給php-fpm，cpu降低，負載變高。
設(shè)置過大可能導致內(nèi)存泄露
4）php執(zhí)行時間超過nginx等待時間
fastcgi_connect_timeout
fastcgi_send_timeout
fastcgi_read_timeout
5）fastcgi執(zhí)行時間
max_execution_time
參考：
php+php-fom+nginx 配置參數(shù)調(diào)優(yōu)詳解
http://www.voycn.com/article/phpphp-fomnginxpeizhicanshudiaoyouxiangjie
nginx 報錯 502
https://www.cnblogs.com/fengzhongzhuzu/p/9193355.html
七、http 和 HTTPS 的區(qū)別
1、端口：http 80； https ：443
2、http無狀態(tài)，https是有http + ssl構(gòu)建的可進行加密傳輸?shù)膮f(xié)議
3、http明文傳輸，https加密傳輸
4、http更快，三次握手三個包，https 需要12個包（3個tcp包+9個ssl握手包）
八、redis 分布式鎖及問題
1、實現(xiàn)：
加鎖：setnx
解鎖：del
鎖超時：expire
2、可能出現(xiàn)的問題
-
1）setnx 和expire非原子性問題（加鎖之后還沒來得及設(shè)置超時就掛了）
解決方案：
Redis 2.6.12以上版本為set指令增加了可選參數(shù)，偽代碼如下：set（key，1，30，NX）,這樣就可以取代setnx指令
-
2）超時誤刪其他進程鎖。（A進程執(zhí)行超時，導致鎖釋放，這時候B進程獲取鎖開始處理請求，這時候A進程處理完成，會誤刪B進程的鎖）
解決方案：只能刪除自己進程的鎖 （lua腳本防止B進程獲取過期鎖之后誤刪A進程的鎖）
-
3）并發(fā)場景，A進程執(zhí)行超時導致鎖釋放，這時候B進程獲取到鎖。
解決方案：開啟守護進程，給當前進程要過期的鎖延時。
-
4）單點實例安全問題
單機宕機之后導致所有客戶端無法獲取鎖
解決：
主從復(fù)制，因為是異步完成的所以無法完全實現(xiàn)解決
參考：
使用 Redis 作為分布式鎖的一些注意點
https://www.cnblogs.com/gxyandwmm/p/9588383.html
面試官：你真的了解 Redis 分布式鎖嗎？
https://segmentfault.com/a/1190000038988087
九、redis 為什么是單線程？為什么快？
推薦閱讀：https://www.php.cn/redis/475918.html
十、redis 的數(shù)據(jù)類型及應(yīng)用場景
1、string ：
普通的key/value存儲
2、hash：
hashmap：鍵值隊集合，存儲對象信息
3、list：
雙向鏈表:消息隊列
4、set：
value永遠為null的hashMap：無序集合且不重復(fù)：計算交集、并集、差集、去重值
5、zset：
有序集合且不重復(fù):hashMap(去重) + skiplist跳躍表（保證有序）：排行榜
參考：
Redis 五種數(shù)據(jù)類型及應(yīng)用場景
https://www.cnblogs.com/jasonZh/p/9513948.html
十一、redis 實現(xiàn)持久化的方式及原理、特點
1、RDB持久化（快照）：指定時間間隔內(nèi)的內(nèi)存數(shù)據(jù)集快照寫入磁盤
1）fork一個子進程，將快照內(nèi)容寫入臨時RDB文件中（dump.rdb），當子進程寫完快照內(nèi)容之后新的文件替換老的文件
2）整個redis數(shù)據(jù)庫只包含一個備份文件
3）性能最大化，只需要fork子進程完成持久化工作，減少磁盤IO
4）持久化之前宕機可能會導致數(shù)據(jù)丟失
2、AOF持久化 ：以日志的形式記錄服務(wù)器的所有的寫、刪除操作
1）每接收到一個寫的命令用write函數(shù)追加到文件appendonly.aof
2）持久化的文件會越來越大，存在大量多余的日志（0 自增100次到100，會產(chǎn)生100條日志記錄）
3）可以設(shè)置不同的fsync策略
-
appendfsync everysec ：1s一次，最多丟失1s的數(shù)據(jù)（默認）
-
appendfsync always ：每次變動都會執(zhí)行一次
-
appendfsync no ：不處理
4）AOF文件太大之后會進行重寫：壓縮AOF文件大小
-
fork一個子進程，將redis內(nèi)地數(shù)據(jù)對象的最新狀態(tài)寫入AOF臨時文件（類似rdb快照）
-
主進程收到的變動會先寫入內(nèi)存中，然后同步到老的AOF文件中（重寫失敗之后也能保證數(shù)據(jù)完整性）
-
子進程完成重寫之后會將內(nèi)存中的新變動同步追加到AOF的臨時文件中
-
父進程將臨時AOF文件替換成新的AOF文件，并重命名。之后收到的新命令寫入到新的文件中
參考：
Redis 專題：萬字長文詳解持久化原理
https://segmentfault.com/a/1190000039208726
Redis 持久化
https://segmentfault.com/a/1190000002906345
RDB 和 AOF 持久化的原理是什么？我應(yīng)該用哪一個？它們的優(yōu)缺點？
https://segmentfault.com/a/1190000018388385
十二、秒殺設(shè)計流程及難點
1、靜態(tài)緩存
2、nginx 負載均衡
三種方式：DNS輪詢、IP負債均衡、CDN
3、限流機制
方式：ip限流、接口令牌限流、用戶限流、header動態(tài)token（前端加密，后端解密）
4、分布式鎖
方式：
-
setnx + expire （非原子性，redis2.6 之后set保證原子性）
-
釋放鎖超時 （開啟守護進程自動續(xù)時間）
-
過期鎖誤刪其他線程（requestId驗證或者lua腳本保證查 + 刪的原子性）
5、緩存數(shù)據(jù)
方式：
-
緩存擊穿：緩存數(shù)據(jù)預(yù)熱 + 布隆過濾器/空緩存
-
緩存雪崩：緩存設(shè)置隨機過期時間，防止同一時間過期
6、庫存及訂單
-
扣庫存
-
redis 自減庫存，并發(fā)場景下可能導致負數(shù)，影響庫存回倉：使用lua腳本保證原子性
-
redis預(yù)扣庫存之后，然后使用異步消息創(chuàng)建訂單并更新庫存變動
-
數(shù)據(jù)庫更新庫存使用樂觀鎖：where stock_num – sell_num > 0
-
添加消息發(fā)送記錄表及重試機制，防止異步消息丟失
-
-
創(chuàng)建訂單
-
前端建立websocket連接或者輪詢監(jiān)聽訂單狀態(tài)
-
消費驗證記錄狀態(tài)，防止重復(fù)消費
-
-
回倉
-
創(chuàng)建訂單之后發(fā)送延時消息，驗證訂單支付狀態(tài)及庫存是否需要回倉
-
十三、防 sql 注入
1、過濾特殊字符
2、過濾數(shù)據(jù)庫關(guān)鍵字
3、驗證數(shù)據(jù)類型及格式
4、使用預(yù)編譯模式，綁定變量
十四、事務(wù)隔離級別
1、標準的sql隔離級別實現(xiàn)原理
-
未提交讀：其他事務(wù)可以直接讀到?jīng)]有提交的：臟讀
-
事務(wù)對當前被讀取的數(shù)據(jù)不加鎖
-
在更新的瞬間加行級共享鎖到事務(wù)結(jié)束釋放
-
-
提交讀：事務(wù)開始和結(jié)束之間讀取的數(shù)據(jù)可能不一致，事務(wù)中其他事務(wù)修改了數(shù)據(jù)：不可重復(fù)度
-
事務(wù)對當前讀取的數(shù)據(jù)（被讀到的時候）行級共享鎖，讀完釋放
-
在更新的瞬間加行級排他鎖到事務(wù)結(jié)束釋放
-
-
可重復(fù)讀：事務(wù)開始和結(jié)束之前讀取的數(shù)據(jù)保持一致，事務(wù)中其他事務(wù)不能修改數(shù)據(jù)：可重復(fù)讀
-
事務(wù)對當前讀到的數(shù)據(jù)從事務(wù)一開始就加一個行級共享鎖
-
在更新的瞬間加行級排他鎖到事務(wù)結(jié)束釋放
-
其他事務(wù)再事務(wù)過程中可能會新增數(shù)據(jù)導致幻讀
-
-
串行化
-
事務(wù)讀取數(shù)據(jù)時加表級共享鎖
-
事務(wù)更新數(shù)據(jù)時加表級排他鎖
-
2、innodb的事務(wù)隔離級別及實現(xiàn)原理（??！和上面的不一樣，區(qū)分理解一個是隔離級別 一個是??！事務(wù)！！隔離級別）
1）基本概念
-
mvcc:多版本并發(fā)控制:依賴于undo log 和read view
-
讓數(shù)據(jù)都讀不會對數(shù)據(jù)加鎖，提高數(shù)據(jù)庫并發(fā)處理能力
-
寫操作才會加鎖
-
一條數(shù)據(jù)有多個版本，每次事務(wù)更新數(shù)據(jù)的時候會生成一個新的數(shù)據(jù)版本，舊的數(shù)據(jù)保留在undo log
-
一個事務(wù)啟動的時候只能看到所有已經(jīng)提交的事務(wù)結(jié)果
-
-
當前讀：讀取的是最新版本
-
快照讀:讀取的是歷史版本
-
間隙鎖：間隙鎖會鎖住一個范圍內(nèi)的索引
-
update id between 10 and 20
-
無論是否范圍內(nèi)是否存在數(shù)據(jù)，都會鎖住整個范圍：insert id = 15，將被防止
-
只有可重復(fù)讀隔離級別才有間隙鎖
-
-
next-key lock：
-
索引記錄上的記錄鎖+ 間隙鎖（索引值到前一個索引值之間的間隙鎖）
-
前開后閉
-
阻止幻讀
-
2）事務(wù)隔離級別
-
未提交讀
-
事務(wù)對當前讀取的數(shù)據(jù)不加鎖，都是當前讀
-
在更新的瞬間加行級共享鎖到事務(wù)結(jié)束釋放
-
-
提交讀
-
事務(wù)對當前讀取的數(shù)據(jù)不加鎖，都是快照讀
-
在更新的瞬間加行級排他鎖到事務(wù)結(jié)束釋放
-
-
可重復(fù)讀
-
事務(wù)對當前讀取的數(shù)據(jù)不加鎖，都是快照讀
-
事務(wù)再更新某數(shù)據(jù)的瞬間，必須加行級排他鎖（Record 記錄鎖、GAP間隙鎖、next-key 鎖），事務(wù)結(jié)束釋放
-
間隙鎖解決的是幻讀問題
-
主從復(fù)制的情況下 ,如果沒有間隙鎖，master庫的A、B進程
-
A進程 delete id < 6 ;然后還沒有commit
-
B進程insert id = 3，commit
-
A進程提交commit
-
該場景下，主庫會存在一條id =3 的記錄，但是binlog里面是先刪除再新增就會導致從庫沒有數(shù)據(jù)，導致主從的數(shù)據(jù)不一致
-
-
MVCC的快照解決的是不可重復(fù)讀問題
-
-
串行化
-
事務(wù)讀取數(shù)據(jù)時加表級，當前讀
-
事務(wù)更新數(shù)據(jù)時加表級排他鎖
-
參考：
深入理解 MySQL 中事務(wù)隔離級別的實現(xiàn)原理
https://segmentfault.com/a/1190000025156465
小胖問我：MySQL 事務(wù)與 MVCC 原理
https://segmentfault.com/a/1190000039809030
快照在 MVCC 中是怎么工作的？
https://www.jianshu.com/p/6c4454ffecc3
MVCC 我知道，但是為什么要設(shè)計間隙鎖？
https://www.jianshu.com/p/fbec6d1fa16c
間隙鎖和 next-key lock
https://www.jianshu.com/p/d1aba64b5c03
十五、索引原理
索引就是幫助數(shù)據(jù)庫高效查找數(shù)據(jù)的存儲結(jié)構(gòu)，存儲再磁盤中，需要消耗磁盤IO
1、存儲引擎
-
myisam 支持表鎖，索引和數(shù)據(jù)分開存儲適合跨服務(wù)器遷移
-
innodb 支持行鎖，索引和數(shù)據(jù)存儲再一個文件
2、索引類型
-
hash索引
-
適合精確查詢且效率高
-
無法排序、不適合范圍查詢
-
hash沖突的情況下需要遍歷鏈表（php數(shù)組的實現(xiàn)原理、redis zset 的實現(xiàn)原理類似）
-
-
b-tree、b+tree
-
b-tree 和b+tree的去區(qū)別
-
b+tree 的數(shù)據(jù)全部存儲在葉子節(jié)點，內(nèi)部節(jié)點只存key,一次磁盤IO能獲取到
-
-
