Nginx面試題

一、缺省安裝的Nginx+php-fpm環境，假設用戶瀏覽一個耗時的網頁，可是卻在服務端渲染頁面的中途中關閉了瀏覽器，那麼請問服務端的PHP腳本是繼續執行仍是退出執行？

答：正常狀況下，若是client異常退出了，Server端的程序仍是會繼續執行，直到與IO進行了兩次交互操做。Server端發現client端已經斷開鏈接，這個時候會出發一個User_abort，若是這個沒有設置ignore_user_abort，那麼這個php-fpm的程序纔會被中斷。

二、nginx是如何實現高併發的？

答：nginx之因此能夠實現高併發，與它採用的epoll模型有很大的關係。epoll模型採用異步非阻塞的事件處理機制。這種機制可以讓nginx進程同時監控多個事件。

簡單來講，就是異步非阻塞，使用了epoll模型和大量的底層代碼優化。若是深刻一點的話，就是nginx的特殊進程模型和事件模型的設計，才使其能夠實現高併發。

進程模型

它是採用一個master進程和多個worker進程的工做模式。
一、master進程主要負責收集、分發請求。當一個請求過來時，master拉起一個worker進程負責處理這個請求。；
二、master進程也要負責監控worker的狀態，保證高可靠性；
三、worker進程議案設置爲和CPU核心數一致或者其二倍。nginx的worker進程和Apache的不同。apache的進程在同一時間只能處理一個請求，因此它會開啓不少個進程，幾百甚至幾千個。而nginx的worker進程在同一時間能夠處理的請求數只受內存限制，所以能夠處理更多請求。

事件模型

nginx是異步非阻塞的。

一個master進程，多個worker進程，每一個worker進程能夠處理多個請求。每進來一個request，都會有worker進程去處理。但不是全程的處理，那麼處理到的程度就是可能發生阻塞的地方，好比向後端服務器轉發request，並等待請求返回。那麼，在等待期間，這個處理的worker不會這麼傻等着，他會在發送完請求後，註冊一個事件：「若是upstream返回了，告訴我一聲，我再接着幹」。因而它就去休息了，此時，若是再有request進來，它就能夠很快再按這種方式處理。而一旦後端服務器返回了，就會觸發這個事件，worker纔會來接手，這個request纔會接着往下走。
因爲nginx的的這個工做性質決定了每一個請求大部分的生命都是在網絡傳輸中，因此實際上花費在nginx 服務器上的時間並很少，這就是它幾進程就能解決高併發的祕密所在。

三、已知nginx和php-fpm安裝在同一臺服務器上，nginx鏈接php-fpm有兩種方式：一種是相似127.0.0.1:9000的TCP socket，另外一種是相似/tmp/php-fpm.sock的Unix domain socket，請問如何選擇？須要注意什麼？

Unix domain socket的流程不會走到TCP那層，直接以文件的形式，以stream socket通訊。若是是TCP Socket，則須要走到IP層。說的通俗一點，追求可靠性就是選擇TCP（須要佔用一個端口，更穩定，如：127.0.0.1:9000），追求高性能就是Unix Socket（不須要佔用端口，更快，但可靠性不如TCP的方式）。

四、nginx和Apache的區別？

二者最核心的區別在於apache是同步多進程模型，一個request對應一個進程，而nginx是異步的，多個鏈接（萬級別）能夠對應一個進程。

通常來講，須要性能的web服務，用nginx，若是不須要性能只求穩定，更考慮Apache，後者的各類模塊實現的比前者好不少，epoll網絡IO模型是nginx處理性能高的根本，但並非全部狀況下epoll大獲全勝的，若是自己提供靜態服務的只有幾個文件，apache的select模型或許比epoll更高性能。固然，這只是一個假設，真正還須要實測了再說。

更通用的方案是，前端nginx抗併發，後端apache集羣，配合起來會更好。

五、nginx的調度算法有哪些？

• sticky：經過nginx-sticky模塊，來實現cookie黏貼的方式未來自同一個客戶端的請求發送到同一個後端服務器上處理，這樣必定程度上能夠解決多個後端服務器的session會話同步的問題；
• round-robin（RR）：輪詢，每一個請求按時間順序依次分配到不一樣的後端服務器，若是後端某臺服務器死機，自動剔除故障系統，使用戶訪問不受影響；
• weight：輪詢權重，weight的值越大分配到的訪問機率就越高，主要用於後端每臺服務器性能不均衡的狀況下，或者僅僅爲在主從的狀況下設置不一樣的權重，達到合理有效的利用主機資源。
• least_conn：請求被髮送到當前活躍鏈接最少的realserver上，會考慮到weight的值；
• ip_hash：每一個請求按照IP的哈希結果分配，使來自同一個IP的訪客固定訪問後端服務器，能夠有效的解決動態網頁存在的session共享問題。
• fair：比weight、ip_hash更加智能的負載均衡算法，fair算法能夠根據頁面的大小和加載時間長短智能地進行負載均衡，也就是根據後端服務器的響應時間來分配請求，相應時間短的優先分配。nginx自己不支持fair，若是須要使用這種調度算法，則必須安裝upstream_fair模塊。
• url_hash：按訪問的URL的哈希結果來分配請求，使每一個URL定向到後端服務器，能夠進一步提升後端緩存服務器的效率。一樣，nginx自己不支持url_hash，若是須要這種調度算法，則必須安裝nginx的hash軟件包。

六、nginx負載均衡調度狀態

在nginx upstream模塊中，能夠設定每臺後端服務器在負載均衡調度中的狀態。

經常使用的狀態有：

• down：表示當前的server暫時不參與負載均衡；
• backup：預留的備份機器。當其餘全部的非backup機器出現故障或者繁忙的時候，纔會請求backup機器，所以這臺機器的訪問壓力最低；
• max_fails：容許請求失敗的次數，默認爲1，當超過最大次數時，返回proxy_next_upstraem模塊定義的錯誤；
• fail_timeout：請求失敗超時時間，在經歷了max_fails次失敗後，暫停服務的時間。max_fails和fail_timeout能夠一塊兒使用。

七、如何查看nginx已添加的模塊？若是須要添加某個模塊，應該如何實現？

查看已添加的模塊：nginx -V；
若是須要添加某個模塊，須要將工做目錄切換至nginx的源碼包中，執行「nginx -V」命令查看以前配置時的選項進行復制，而後增長鬚要添加的模塊配置項，進行配置並編譯，將新生成的nginx命令覆蓋掉原有的nginx命令，而後重載nginx服務，便可實如今線添加模塊。

八、能夠從哪些方面來優化nginx服務？

• 配置nginx的proxy緩存；
• 對靜態頁面開啓壓縮功能，如br壓縮或者gzip壓縮；
• 調整nginx運行工做進程個數，最多開啓8個，8個以上話性能就不會再提高了，並且穩定性變得更低，因此8個足夠用了；
• 調整nginx運行CPU的親和力；
• 修改nginx最多可打開的文件數，若超過系統限制的最多打開文件數（ulimit -n命令查看系統的最多打開文件數），還須要修改系統默認的文件數；
• 修改單個worker的最大鏈接數；
• 開啓高效傳輸；
• 設置鏈接超時時間，以便保護服務器資源，由於創建鏈接也是須要消耗資源的；
• 優化fastCGI的一個超時時間，也能夠根據實際狀況對其配置緩存動態頁面；
• expires緩存調優，主要針對圖片、css、js等元素更改較少的狀況下使用。
• 配置防盜鏈；
• 優化內核參數，如進程能夠同時打開的最大句柄數；開啓tcp重用機制，以便容許TIME_WAIT sockets從新用於新的TCP鏈接....還有好多，記不住。