面試官：Nginx和Apache（在性能上）的區別是什么？

Nginx和Apache在性能上的區別主要體現在以下幾個方面：

1. 并發連接處理能力

Nginx：

• Nginx采用了事件驅動的異步非阻塞架構，這種設計使得Nginx能夠高效地處理大量并發連接。
• Nginx在處理并發連接時，資源消耗較低，能夠保持較高的性能和穩定性。

Apache：

• Apache使用基于進程或線程的模型來處理請求，每個請求通常會創建一個獨立的進程或線程。
• 在處理大量并發連接時，Apache可能會因為創建過多的進程或線程而導致資源消耗增加，進而影響性能。

2. 內存消耗

Nginx：

• Nginx的架構更為輕量化，代碼量較少，因此通常比Apache消耗更少的內存。
• 這種低內存消耗的特性使得Nginx在處理大量請求時更為高效。

Apache：

• 相較于Nginx，Apache的內存消耗可能會更高，尤其是在處理大量并發連接時。
• 不過，Apache的內存消耗也取決于其配置和加載的模塊數量。

3. 靜態文件處理

Nginx：

• Nginx在處理靜態文件時表現非常出色，能夠高效地提供靜態內容。
• Nginx的靜態文件處理能力得益于其高效的I/O處理機制和優化的內存管理。

Apache：

• 雖然Apache也能處理靜態文件，但相比之下，其性能可能稍遜于Nginx。
• Apache在處理靜態文件時可能需要更多的資源，尤其是在高并發場景下。

4. 動態內容處理

Nginx：

• Nginx本身并不擅長處理動態內容，但可以通過配置反向代理和負載均衡等功能，將動態內容處理的請求轉發給后端的應用服務器。
• Nginx也支持一些模塊來處理簡單的動態內容，但功能相對有限。

Apache：

• Apache在處理動態內容方面更具優勢，因為它支持多種編程語言和模塊擴展。
• Apache可以通過加載不同的模塊來支持不同的動態內容處理需求，如PHP、Python等。

面試官：如何用Nginx解決前端跨域問題？

前端跨域問題是指瀏覽器出于安全考慮，限制從一個域的網頁直接訪問另一個域中的資源，從而導致AJAX請求失敗。Nginx可以通過配置HTTP響應頭來解決前端跨域問題。

以下是用Nginx解決前端跨域問題的詳細步驟：

1. 理解CORS和同源策略

CORS（Cross-Origin Resource Sharing，跨源資源共享）和同源策略是Web安全領域中兩個重要的概念，它們在處理跨域請求時起著至關重要的作用。以下是對這兩個概念的詳細解釋：

(1) 同源策略（Same-Origin Policy）

① 定義：

同源策略是一種安全機制，用于防止不同來源的文檔或腳本相互干擾。它基于域名、協議和端口來定義一個“源”，只有當兩個URL具有相同的協議、主機名和端口號時，它們才被認為是同源的。

② 限制：

• DOM訪問限制：一個頁面中的腳本不能讀取或操作另一個頁面的內容。
• Cookie限制：一個頁面中的腳本不能訪問另一個頁面的Cookie。
• AJAX請求限制：一個頁面中的腳本不能向另一個域名發送AJAX請求。

③ 目的：這種策略的目的是防止惡意網站竊取數據，例如，防止一個網站通過JavaScript訪問另一個網站的用戶數據。

(2) CORS（跨源資源共享）

① 定義：

CORS是一種機制，它使用額外的HTTP頭來告訴瀏覽器允許來自不同源的Web應用訪問該資源。通過配置CORS，服務器可以指定哪些源可以訪問其資源，以及允許哪些類型的請求方法（如GET、POST等）。

② 工作原理：

• 預檢請求（Preflight Request）：對于某些類型的請求（如PUT、DELETE等），瀏覽器會先發送一個OPTIONS請求到服務器，詢問服務器是否允許實際的請求。這個過程稱為預檢請求。
• 響應頭：服務器通過設置特定的HTTP響應頭來表明是否允許跨域請求。這些響應頭包括Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers等。
• 實際請求：如果預檢請求被批準，瀏覽器將發送實際的請求。

2. Nginx配置CORS

Nginx可以通過配置HTTP響應頭來支持CORS。這些頭信息包括Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers和Access-Control-Allow-Credentials等。

(1) 找到或創建Nginx的配置文件：通常位于/etc/nginx/nginx.conf或/etc/nginx/conf.d/目錄中。

(2) 在需要跨域的server塊或location塊中添加CORS相關的頭部配置

以下是一個配置示例：

server {
    listen 80;
    server_name api.example.com;
    location / {
        # 設置允許跨域的域名，可以使用通配符'*'允許所有域訪問
        add_header 'Access-Control-Allow-Origin' 'http://www.example.com';
        
        # 設置允許的HTTP方法
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE, PUT';
        
        # 設置允許的請求頭
        add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, Accept, Origin, X-Requested-With';
        
        # 如果需要支持cookie，可以設置以下header
        add_header 'Access-Control-Allow-Credentials' 'true';
        
        # 如果是預檢請求（OPTIONS請求），則直接返回204狀態碼
        if ($request_method = 'OPTIONS') {
            return 204;
        }
        
        # 其他正常請求的處理邏輯
        proxy_pass http://backend_server;
    }
}

在上述配置中：

• Access-Control-Allow-Origin：指定允許跨域請求的來源。可以設置為具體的域名（如http://www.example.com），或使用通配符*允許所有來源。但需要注意，使用通配符時，不允許設置Access-Control-Allow-Credentials為true。
• Access-Control-Allow-Methods：指定允許的HTTP請求方法，如GET、POST、OPTIONS、PUT、DELETE等。
• Access-Control-Allow-Headers：指定允許客戶端發送的自定義HTTP頭部，如Authorization、Content-Type等。
• Access-Control-Allow-Credentials：如果客戶端請求包括憑據（如Cookies），則該選項必須設置為true。此時Access-Control-Allow-Origin不能為*，必須為具體的域名

3. 處理預檢請求

預檢請求是CORS規范中定義的一種機制，用于在實際請求之前探測服務器是否允許某個跨域請求。瀏覽器在發送某些復雜請求之前，會發送一個OPTIONS請求進行預檢，詢問服務器是否允許該請求。Nginx可以通過簡單的配置處理這種預檢請求，例如：

location / {
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
        add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
        add_header 'Access-Control-Allow-Credentials' 'true';
        add_header 'Access-Control-Max-Age' 3600;
        return 204;
    }
    # 其余配置...
}

4. 配置通配符和動態設置

(1) 配置通配符：在某些場景中，如果需要允許所有域訪問（即不限制跨域請求的來源），可以將Access-Control-Allow-Origin設置為*。但如前所述，此時不能同時啟用Access-Control-Allow-Credentials。

(2) 動態設置：如果需要根據請求動態設置Access-Control-Allow-Origin，可以使用$http_origin變量來匹配請求來源。例如：

location / {
    if ($http_origin ~* 'https?://(www\.)?(example1\.com|example2\.com)') {
        add_header 'Access-Control-Allow-Origin' "$http_origin";
        add_header 'Access-Control-Allow-Credentials' 'true';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, Accept';
    }
    if ($request_method = 'OPTIONS') {
        return 204;
    }
    proxy_pass http://backend_server;
}

這種配置可以在滿足特定條件時，動態地允許多個域名進行跨域訪問。

面試題：漏桶流算法和令牌桶算法知道嗎？如何使用Nginx限流？

在限流中，有兩個關鍵概念需要了解：閾值（一個單位時間內允許的請求量）和拒絕策略（超過閾值的請求的拒絕策略，常見的拒絕策略有直接拒絕、排隊等待等）。

漏桶流算法和令牌桶算法是兩種常見的限流算法，以下是這兩種算法的具體介紹：

1. 漏桶流算法（Leaky Bucket Algorithm）

工作原理：

• 漏桶算法可以看作是一個帶有常量服務時間的單服務器隊列。如果漏桶（包緩存）溢出，那么數據包會被丟棄。
• 漏桶算法提供了一種機制，通過它，突發流量可以被整形以便為網絡提供一個穩定的流量。漏桶強制一個常量的輸出速率，而不管輸入數據流的突發性。
• 當數據包到達漏桶時，它們被放置在桶的底部。然后，數據包以固定的速率（漏出速率）從桶中漏出，注入網絡。如果到達速率超過漏出速率，并且桶已滿，則新的數據包將被丟棄。

優點：

• 保證嚴格的延遲界限，避免一切由緩沖區溢出引起的丟失。
• 網絡可以容易地驗證通信量是否符合規范。

應用場景：

• 漏桶算法適用于需要嚴格控制輸出速率的場景，如網絡流量整形。

2. 令牌桶算法（Token Bucket Algorithm）

工作原理：

• 令牌桶算法使用一個虛擬的桶來存放令牌，每個令牌代表一個數據包的發送權限。
• 系統以固定的速率向桶中添加令牌，每當一個數據包發送時，就從桶中移除一個令牌。
• 如果桶中沒有令牌，數據包則需要等待，直到有令牌可用。如果桶中的令牌數量超過其容量，則新生成的令牌會被丟棄。

優點：

• 允許一定程度的突發傳輸，同時限制長時間內的傳輸速率。
• 更靈活地處理流量，能夠更好地利用網絡資源。

應用場景：

• 令牌桶算法廣泛應用于網絡流量管理、API請求限流等場景。

3. 漏桶流算法與令牌桶算法的比較

在實際應用中，選擇哪種限流算法取決于具體的需求和場景。例如，如果系統需要嚴格控制輸出速率并避免突發流量，則漏桶算法可能更合適。而如果系統需要允許一定程度的突發傳輸，并希望更靈活地處理流量，則令牌桶算法可能更合適。

在Nginx中配置限流，主要通過limit_req和limit_conn兩個模塊來實現。以下是具體的配置方法：

1. 使用limit_req模塊限制請求速率

limit_req模塊基于令牌桶算法來限制每秒的請求次數。配置步驟如下：

(1) 定義限流區域：

在http塊中，使用limit_req_zone指令來定義一個限流區域。這個區域會存儲在共享內存中，并用于跟蹤請求的速率。

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
    ...
}

這里，$binary_remote_addr是客戶端IP地址的二進制表示，znotallow=mylimit:10m定義了一個名為mylimit的共享內存區域，大小為10MB，rate=1r/s設置了每秒的請求速率限制為1個請求。

(2) 應用限速規則：

在server或location塊中，使用limit_req指令來應用限速規則。

server {
    ...
    location / {
        limit_req zone=mylimit burst=5 nodelay;
        ...
    }
    ...
}

這里，znotallow=mylimit指定了使用前面定義的mylimit區域，burst=5允許在超過速率限制后，突發處理最多5個請求，nodelay表示這些突發請求將立即處理，而不會等待新的令牌生成。

2. 使用limit_conn模塊限制并發連接數

limit_conn模塊用于限制同時連接數。配置步驟如下：

(1) 定義連接限制區域：

在http塊中，使用limit_conn_zone指令來定義一個連接限制區域。

http {
    limit_conn_zone $binary_remote_addr zone=addr:10m;
    ...
}

這里，$binary_remote_addr是客戶端IP地址的二進制表示，znotallow=addr:10m定義了一個名為addr的共享內存區域，大小為10MB。

(2) 應用連接限制規則：

在server或location塊中，使用limit_conn指令來應用連接限制規則。

server {
    ...
    location / {
        limit_conn addr 10;
        ...
    }
    ...
}

這里，addr引用了之前定義的limit_conn_zone的名稱，10表示最大并發連接數限制為10。

3. 其他限流配置

除了上述基本的限流配置外，Nginx還支持其他限流策略，如：

• 設置黑白名單：通過ngx_http_geo_module和ngx_http_map_module模塊，可以設置黑白名單來控制哪些客戶端IP地址可以訪問或禁止訪問特定的資源或整個服務器。
• 限制數據傳輸速度：使用limit_rate和limit_rate_after指令，可以限制對特定位置（location）的響應速度。

面試官：Nginx怎么判斷別的IP不可訪問？

Nginx判斷別的IP不可訪問的功能，通常是通過其內置的ngx_http_access_module模塊來實現的。該模塊允許基于客戶端的IP地址來允許或拒絕對網站資源的訪問。

1. 基本配置指令

• allow：允許指定的IP地址或IP地址段訪問服務器。
• deny：拒絕指定的IP地址或IP地址段訪問服務器。

2. 配置位置

這些指令可以配置在http、server、location、limit_except等上下文中，從而對整個服務器、特定虛擬主機或特定資源進行訪問控制。

3. 配置示例

(1) 拒絕單個IP地址

假設要拒絕IP地址為192.168.1.100的所有訪問請求，可以在Nginx配置文件中使用以下配置：

server {
    listen 80;
    server_name example.com;
    location / {
        deny 192.168.1.100;
        allow all;
    }
}

在這個配置中，所有來自192.168.1.100的請求將被拒絕，而其他IP地址的請求將被允許。

(2) 拒絕多個IP地址或IP地址段

如果需要同時拒絕多個IP地址或一個IP地址段，可以使用多個deny指令或指定一個CIDR范圍。例如：

server {
    listen 80;
    server_name example.com;
    location / {
        deny 192.168.1.100;
        deny 192.168.1.101;
        deny 192.168.1.0/24; # 拒絕整個子網段
        allow all;
    }
}

上述配置會拒絕192.168.1.100、192.168.1.101以及192.168.1.0/24網段中的所有IP地址的訪問。

(3) 允許和拒絕的優先級

在Nginx中，allow和deny指令具有優先級。Nginx從上到下依次讀取配置，當有多個allow和deny指令時，首先匹配到的規則會生效。通常情況下，deny指令在allow指令之前時，拒絕的優先級更高。例如：

server {
    listen 80;
    server_name example.com;
    location / {
        allow 192.168.1.0/24;
        deny all;
    }
}

在這個配置中，盡管有一個允許192.168.1.0/24網段訪問的規則，但由于deny all指令在其后，所以該規則會被忽略，最終結果是拒絕所有IP地址的訪問（這里的配置邏輯實際上是有問題的，因為allow指令在deny之前會先匹配，但這里的示例是為了說明優先級的概念。正確的配置應該是先deny all，然后再根據需要allow特定的IP，或者將deny指令放在allow指令之前以確保拒絕的規則優先生效。不過，由于Nginx會按順序匹配第一個滿足條件的規則，因此通常我們會將更具體的規則（如allow）放在前面，然后用一個deny all作為兜底規則來拒絕所有未明確允許的訪問）。然而，為了避免混淆，通常建議按照邏輯順序和實際需求來配置allow和deny指令，以確保配置的正確性和有效性。

4. 基于HTTP頭部的IP信息

在某些情況下，客戶端的真實IP地址可能被隱藏在HTTP頭部中，如通過反向代理服務器時。在這種情況下，需要基于HTTP頭部中的IP信息來進行訪問控制。常見的HTTP頭部字段包括X-Forwarded-For和X-Real-IP。可以通過$http_x_forwarded_for變量來獲取該IP信息，并結合if語句進行訪問控制。例如：

server {
    listen 80;
    server_name example.com;
    location / {
        if ($http_x_forwarded_for = "192.168.1.100") {
            return 403;
        }
        proxy_pass http://backend;
    }
}

在這個配置中，如果請求的X-Forwarded-For頭部中包含192.168.1.100，則Nginx會返回403禁止訪問的狀態碼。

5. 訪問日志

為了進一步分析和控制IP地址的訪問情況，可以使用Nginx的訪問日志功能。通過日志記錄，可以跟蹤哪些IP地址頻繁訪問服務器，從而有助于做出相應的訪問控制策略。在Nginx配置中，可以自定義日志格式并將客戶端IP地址記錄到日志中。

6. 其他策略

除了使用deny指令直接拒絕訪問外，還可以通過以下方式進一步增強IP訪問的限制：

• 使用Nginx的limit_conn和limit_req模塊，根據IP地址限制請求的頻率或并發連接數。
• 使用Nginx社區提供的第三方模塊（如ngx_http_geoip_module）來基于地理位置限制IP訪問。
• 結合操作系統層面的防火墻（如iptables、firewalld）來限制IP地址的訪問。

面試官：什么是驚群效應，驚群效應消耗了什么，Nginx的驚群效應是如何發生的，又是如何應對的驚群效應？

驚群效應是一個在操作系統多線程或多進程環境中常見的現象。當多個線程或進程同時阻塞等待同一個事件（例如新連接的到來）時，如果該事件觸發，系統可能會喚醒所有等待的線程或進程。然而，實際上只有一個線程或進程能夠成功獲取資源或處理事件，而其他被喚醒的線程或進程則會重新進入休眠狀態。這種現象導致了資源的浪費，包括無效的上下文切換和調度，以及可能導致的緩存失效等問題。

對于 Nginx 的驚群問題，我們首先需要理解的是，在 Nginx 啟動過程中，master 進程會監聽配置文件中指定的各個端口，然后 master 進程就會調用 fork() 方法創建各個子進程，根據進程的工作原理，子進程是會繼承父進程的全部內存數據以及監聽的端口的，所以 worker 進程在啟動之后也是會監聽各個端口的。

當客戶端有新建連接的請求到來時，就會觸發各個 worker 進程的連接建立事件，但是只有一個 worker 進程能夠正常處理該事件，而其他的 worker 進程會發現事件已經失效，從而重新循環進入等待狀態。這種由于一個連接事件的到來而 “驚” 起了所有 worker 進程的現象就是Nginx的驚群問題。

Nginx的解決方案是：每個 worker 進程被創建的時候，都會調用 ngx_worker_process_init() 方法初始化當前 worker 進程，每個 worker 進程都會調用 epoll_create() 方法為自己創建一個獨有的 epoll 句柄。

對于每一個需要監聽的端口，都有一個文件描述符與之對應，而 worker 進程只有將該文件描述符通過 epoll_ctl() 方法添加到當前進程的 epoll 句柄中，并且監聽 accept 事件，此時才會被客戶端的連接建立事件觸發。

基于這個原理，nginx 就使用了一個共享鎖來控制當前進程是否有權限將需要監聽的端口添加到當前進程的 epoll 句柄中。通過這種方式，就保證了每次事件發生時，只有一個 worker 進程會被觸發。如下圖所示為 worker 進程工作循環的一個示意圖：

這里關于圖中的流程，需要說明的一點是，每個 worker 進程在進入循環之后就會嘗試獲取共享鎖，如果沒有獲取到，就會將所監聽的端口的文件描述符從當前進程的 epoll 句柄中移除（即使并不存在也會移除），這么做的主要目的是防止丟失客戶端連接事件，即使這可能造成少量的驚群問題，但是并不嚴重。

面試題：Nginx如何實現后端服務的健康檢查？

Nginx本身不直接提供內置的后端服務健康檢查功能，但可以通過一些模塊和配置實現類似的效果。以下是一些常見的方法：

1. 使用 ngx_http_upstream_check_module 模塊

ngx_http_upstream_check_module 是一個第三方模塊，用于對后端服務進行健康檢查。它需要在編譯 Nginx 時包含這個模塊。

安裝和配置示例：

(1) 編譯 Nginx 并包含 ngx_http_upstream_check_module：

下載 Nginx 源代碼并編譯：

wget http://nginx.org/download/nginx-<version>.tar.gz
tar -zxvf nginx-<version>.tar.gz
cd nginx-<version>/
# 添加 --add-module 參數來包含第三方模塊
./configure --add-module=/path/to/ngx_http_upstream_check_module --prefix=/usr/local/nginx
make
sudo make install

(2) 配置 Nginx：

在 Nginx 配置文件中（通常是 /usr/local/nginx/conf/nginx.conf），添加健康檢查配置：

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
}
server {
    listen 80;
    location / {
        proxy_pass http://backend;
    }
    # 健康檢查配置
    location /check {
        check interval=3000 rise=2 fall=3 timeout=2000 type=http;
        check_http_send "HEAD / HTTP/1.0\r\n\r\n";
        check_http_expect_status 200-299;
    }
}

Nginx會根據/check location塊中的配置，定期（每3000毫秒）向backend1.example.com和backend2.example.com發送HTTP HEAD請求進行健康檢查。

如果backend1.example.com連續失敗3次（fall=3）健康檢查（每次檢查超時時間為2000毫秒，且期望的HTTP狀態碼為200-299），則Nginx會將backend1.example.com標記為不健康。

相反，如果backend1.example.com在標記為不健康后連續成功2次（rise=2）健康檢查，則它會被重新標記為健康。

如果backend1.example.com被標記為不健康，Nginx將只會將請求代理到backend2.example.com（假設它是健康的）。

如果backend2.example.com也變為不健康，那么Nginx將無法代理任何新的請求到該上游組，除非有服務器恢復健康或您添加了更多的服務器到上游組中。

2. 使用 proxy_next_upstream 和 proxy_connect_timeout 配置

雖然這種方法不是真正的健康檢查，但可以通過配置 Nginx 的代理行為來間接實現后端服務的故障轉移。

配置示例：

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
}
server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
        proxy_send_timeout 30s;
    }
}

在這個配置中，如果后端服務返回錯誤碼（如 500, 502, 503, 504），或者連接超時，Nginx 會嘗試將請求轉發到下一個后端服務器。