nginx面試要點

首先列出一些面試題目包括nginx和redis的。

1.、nginx 框架是怎樣的

2. nginx負載均衡的算法怎麼實現的，懵逼，說沒看過  。

nginx 的 upstream目前支持 4 種方式的分配 
1)、輪詢（默認） 
      每一個請求按時間順序逐一分配到不一樣的後端服務器，若是後端服務器down掉，能自動剔除。 
2)、weight 
      指定輪詢概率，weight和訪問比率成正比，用於後端服務器性能不均的狀況。 
2)、ip_hash 
      每一個請求按訪問ip的hash結果分配，這樣每一個訪客固定訪問一個後端服務器，能夠解決session的問題。  
3)、fair（第三方） 
      按後端服務器的響應時間來分配請求，響應時間短的優先分配。  
4)、url_hash（第三方）

nginx內置策略包含加權輪詢和ip hash

加權輪詢算法分爲先深搜索和先廣搜索，那麼nginx採用的是先深搜索算法，即將首先將請求都分給高權重的機器，直到該機器的權值降到了比其餘機器低，纔開始將請求分給下一個高權重的機器；

3. redis主從是怎麼選取的  

       四、redis插槽的分配  
     五、redis複製的過程  
     六、redis主節點宕機了怎麼辦，還有沒有同步的數據怎麼辦  
     .....反正一大堆redis的問題  
     七、重入鎖是怎麼計數的  

八、如何解決驚羣現象？

驚羣是多個子進程在同一時刻監聽同一個端口引發的；

Nginx解決方法：同一個時刻只能有惟一一個worker子進程監聽web端口，此時新鏈接事件只能喚醒惟一正在監聽端口的worker子進程。

採用鎖，互斥量實現！！

 

1、Nginx優秀模塊 模塊設計：

高度模塊化設計，除了少許核心代碼，其餘一切接模塊。官方Nginx共有五大類型模塊：核心模塊、配置模塊、事件模塊、HTTP模塊、mail模塊。

要注意的是：nginx的模塊是靜態的，添加和刪除模塊都要對nginx進行從新編譯，這一點與Apache的動態模塊徹底不一樣。

 

2、事件驅動框架：

nginx事件驅動框架（書本p254）：所謂事件驅動架構，簡單來講，就是由一些事件發生源來產生事件，由一個或多個事件收集器（epolld等）來收集、分發事件，而後許多事件處理器會註冊本身感興趣的事件，同時會「消費」這些事件。nginx不會使用進程或線程做爲事件消費者，只能是某個模塊，當前進程調用模塊。

 

 傳統web服務器（如Apache）的，所謂事件侷限在TCP鏈接創建、關閉上，其餘讀寫都不在是事件驅動，這時會退化成按序執行每一個操做的批處理模式，這樣每一個請求在鏈接創建後都將始終佔用系統資源，直到鏈接關閉纔會釋放資源。大大浪費了內存、cpu等資源。而且把一個進程或線程做爲事件消費者。

  傳統web服務器與Nginx間重要差異：

 前者每一個事件消費者獨佔一個進程資源，後者只是被事件分發者進程短時間調用而已。

 

3、請求的多階段異步處理

請求的多階段異步處理只能基於事件驅動框架實現，就是把一個請求的處理過程按照事件的觸發方式分爲多個階段，每一個階段均可以有事件收集、分發器（epoll等）來觸發。好比一個http請求能夠分爲七個階段

 

    4、一個master進程（管理），多個work（工做）進程。

        master對work進程採用信號進行控制

 

   5、平臺無關的代碼實現：

     在覈心代碼都使用了與操做系統無關的代碼實現，在與操做系統相關的系統調用上則分別針對各個操做系統都有獨立實現，這最終造就了Nginx的可移植性。

  6、內存池的設計

     爲了減小避免出現內存碎片、減小向操做系統申請內存的次數、下降各個模塊的開發複雜度，Nginx採用了簡單的內存池（統一申請，統一釋放）。好比爲每一個http請求分配一個內存池，請求結束時銷燬整個內存池。

一、什麼是Nginx？
    Nginx是一個高性能的HTTP和反向代理服務器，及電子郵件（IMAP/POP3）代理服務器，同時也是一個很是高效的反向代理、負載平衡。

多進程異步非阻塞事件處理機制：運用了epoll模型

    
      二、爲何要用Nginx？
    優勢：
        跨平臺、配置簡單
       非阻塞、高併發鏈接：處理2-3萬併發鏈接數，官方監測能支持5萬併發
        內存消耗小：開啓10個nginx才佔150M內存，Nginx採起了分階段資源分配技術
        nginx處理靜態文件好,耗費內存少
        內置的健康檢查功能：若是有一個服務器宕機，會作一個健康檢查，再發送的請求就不會發送到宕機的服務器了。從新將請求提交到其餘的節點上。
        節省寬帶：支持GZIP壓縮，能夠添加瀏覽器本地緩存
        穩定性高：宕機的機率很是小
       master/worker結構：一個master進程，生成一個或者多個worker進程
        接收用戶請求是異步的：瀏覽器將請求發送到nginx服務器，它先將用戶請求所有接收下來，再一次性發送給後端web服務器，極大減輕了web服務器的壓力
        一邊接收web服務器的返回數據，一邊發送給瀏覽器客戶端
        網絡依賴性比較低，只要ping通就能夠負載均衡
        能夠有多臺nginx服務器
        事件驅動：通訊機制採用epoll模型

    三、爲何Nginx性能這麼高？
    得益於它的事件處理機制：
        異步非阻塞事件處理機制：運用了epoll模型，提供了一個隊列，排隊解決

    四、爲何不使用多線程？

Apache: 建立多個進程或線程，而每一個進程或線程都會爲其分配cpu和內存（線程要比進程小的多，因此worker支持比perfork高的併發），併發過大會榨乾服務器資源。

Nginx: 採用單線程來異步非阻塞處理請求（管理員能夠配置Nginx主進程的工做進程的數量）(epoll)，不會爲每一個請求分配cpu和內存資源，節省了大量資源，同時也減小了大量的CPU的上下文切換。因此才使得Nginx支持更高的併發。

    五、Nginx是如何處理一個請求的呢？
    首先，nginx在啓動時，會解析配置文件，獲得須要監聽的端口與ip地址，而後在nginx的master進程裏面
    先初始化好這個監控的socket，再進行listen
    而後再fork出多個子進程出來,  子進程會競爭accept新的鏈接。

此時，客戶端就能夠向nginx發起鏈接了。當客戶端與nginx進行三次握手，與nginx創建好一個鏈接後

    此時，某一個子進程會accept成功，而後建立nginx對鏈接的封裝，即ngx_connection_t結構體
    接着，根據事件調用相應的事件處理模塊，如http模塊與客戶端進行數據的交換。

最後，nginx或客戶端來主動關掉鏈接，到此，一個鏈接就壽終正寢了

六、正向代理
    一個位於客戶端和原始服務器(origin server)之間的服務器，爲了從原始服務器取得內容，客戶端向代理髮送一個請求並指定目標(原始服務器)，而後代理向原始服務器轉交請求並將得到的內容返回給客戶端。客戶端才能使用正向代理
   正向代理總結就一句話：代理端代理的是客戶端
    七、反向代理
    反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的鏈接請求，而後將請求，發給內部網絡上的服務器
    並將從服務器上獲得的結果返回給internet上請求鏈接的客戶端，此時代理服務器對外就表現爲一個反向代理服務器
    反向代理總結就一句話：代理端代理的是服務端
    八、動態資源、靜態資源分離
    動態資源、靜態資源分離是讓動態網站裏的動態網頁根據必定規則把不變的資源和常常變的資源區分開來，動靜資源作好了拆分之後，咱們就能夠根據靜態資源的特色將其作緩存操做，這就是網站靜態化處理的核心思路
    動態資源、靜態資源分離簡單的歸納是：動態文件與靜態文件的分離
    九、爲何要作動、靜分離？
    在咱們的軟件開發中，有些請求是須要後臺處理的（如：.jsp,.do等等），有些請求是不須要通過後臺處理的（如：css、html、jpg、js等等文件）
    這些不須要通過後臺處理的文件稱爲靜態文件，不然動態文件。所以咱們後臺處理忽略靜態文件。這會有人又說那我後臺忽略靜態文件不就完了嗎
    固然這是能夠的，可是這樣後臺的請求次數就明顯增多了。在咱們對資源的響應速度有要求的時候，咱們應該使用這種動靜分離的策略去解決
    動、靜分離將網站靜態資源（HTML，JavaScript，CSS，img等文件）與後臺應用分開部署，提升用戶訪問靜態代碼的速度，下降對後臺應用訪問
    這裏咱們將靜態資源放到nginx中，動態資源轉發到tomcat服務器中

十、負載均衡    負載均衡便是代理服務器將接收的請求均衡的分發到各服務器中    負載均衡主要解決網絡擁塞問題，提升服務器響應速度，服務就近提供，達到更好的訪問質量，減小後臺服務器大併發壓力