2018年11月22日 星期四

《面試官別再問》ES6中的Promise以及Promise/A+規範

在Promise的知識體系中,jquery當然是必不可少的一環,所以本篇就來講講jquery中的Promise,也就是我們所知道的Deferred對象。

事實上,在此之前網上有很多文章在講jquery Deferred對象了,但是總喜歡把ajax和Deferred混在一起講,容易把人搞混。 when、done、promise、success、error、fail、then、resolve、reject、always這麼多方法不能揉在一起講,需要把他們捋一捋,哪些是Deferred對象的方法,哪些是ajax的語法糖,我們需要心知肚明。

先講$.Deferred
jquery用$.Deferred實現了Promise規範,$.Deferred是個什麼玩意呢?還是老方法,打印出來看看,先有個直觀印象:
var def = $.Deferred();
console.log(def);
輸出如下:

$.Deferred()返回一個對象,我們可以稱之為Deferred對象,上面掛著一些熟悉的方法如:done、fail、then等。jquery就是用這個Deferred對象來註冊異步操作的回調函數,修改並傳遞異步操作的狀態。

Deferred對象的基本用法如下,為了不與ajax混淆,我們依舊舉setTimeout的例子:
複製代碼
function runAsync(){
     var def = $.Deferred();
     // 做一些異步操作
    setTimeout( function (){
        console.log( '執行完成' );
        def.resolve( '隨便什麼數據' );
    }, 2000 );
     return def;
}
runAsync().then( function (data){
    console.log(data)
});

在runAsync函數中,我們首先定義了一個def對象,然後進行一個延時操作,在2秒後調用def.resolve(),最後把def作為函數的返回。調用runAsync的時候將返回def對象,然後我們就可以.then來執行回調函數。

是不是感覺和ES6的Promise很像呢?我們來回憶一下第一篇中ES6的例子:
複製代碼
function runAsync(){
     var p = new Promise( function (resolve, reject){
         // 做一些異步操作
        setTimeout( function (){
            console.log( '執行完成' );
            resolve( '隨便什麼數據' );
        }, 2000 );
    });
    return p;
}
runAsync()
區別在何處一看便知。由於jquery的def對象本身就有resolve方法,所以我們在創建def對象的時候並未像ES6這樣傳入了一個函數參數,是空的。在後面可以直接def.resolve()這樣調用。

這樣也有一個弊端,因為執行runAsync()可以拿到def對象,而def對像上又有resolve方法,那麼豈不是可以在外部就修改def的狀態了?比如我把上面的代碼修改如下:
複製代碼
var d = runAsync();
d.then( function (data){
    console.log(data)
});
d.resolve( '在外部結束');
複製代碼
現象會如何呢?並不會在2秒後輸出“執行完成”,而是直接輸出“在外部結束”。因為我們在異步操作執行完成之前,沒等他自己resolve,就在外部給resolve了。這顯然是有風險的,比如你定義的一個異步操作並指定好回調函數,有可能被別人給提前結束掉,你的回調函數也就不能執行了。

怎麼辦?jquery提供了一個promise方法,就在def對像上,他可以返回一個受限的Deferred對象,所謂受限就是沒有resolve、reject等方法,無法從外部來改變他的狀態,用法如下:
複製代碼
function runAsync(){
     var def = $.Deferred();
     // 做一些異步操作
    setTimeout( function (){
        console.log( '執行完成' );
        def.resolve( '隨便什麼數據' );
    }, 2000 );
     return def.promise(); // 就在這裡調用
}
複製代碼
這樣返回的對像上就沒有resolve方法了,也就無法從外部改變他的狀態了。這個promise名字起的有點奇葩,容易讓我們搞混,其實他就是一個返回受限Deferred對象的方法,與Promise規範沒有任何關係,僅僅是名字叫做promise罷了。雖然名字奇葩,但是推薦使用。

then的鍊式調用
既然Deferred也是Promise規範的實現者,那麼其他特性也必須是支持的。鍊式調用的用法如下:
複製代碼
var d = runAsync();

d.then( function (data){
    console.log(data);
    return runAsync2();
})
.then( function (data){
    console.log(data);
    return runAsync3();
})
.then( function (data){
    console.log(data);
});
複製代碼
與我們第一篇中的例子基本一樣,可以參照。

done與fail
我們知道,Promise規範中,then方法接受兩個參數,分別是執行完成和執行失敗的回調,而jquery中進行了增強,還可以接受第三個參數,就是在pending狀態時的回調,如下:
deferred.then( doneFilter [, failFilter ] [, progressFilter ] )
除此之外,jquery還增加了兩個語法糖方法,done和fail,分別用來指定執行完成和執行失敗的回調,也就是說這段代碼:
複製代碼
d.then( function (){
    console.log( '執行完成' );
}, function (){
    console.log( '執行失敗' );
});
複製代碼
與這段代碼是等價的:
複製代碼
d.done( function (){
    console.log( '執行完成' );
})
.fail( function (){
    console.log( '執行失敗' );
});
複製代碼

always的用法
jquery的Deferred對像上還有一個always方法,不論執行完成還是執行失敗,always都會執行,有點類似ajax中的complete。不贅述了。

$.when的用法
jquery中,還有一個$.when方法來實現Promise,與ES6中的all方法功能一樣,並行執行異步操作,在所有的異步操作執行完後才執行回調函數。不過$.when並沒有定義在$.Deferred中,看名字就知道,$.when,它是一個單獨的方法。與ES6的all的參數稍有區別,它接受的並不是數組,而是多個Deferred對象,如下:
複製代碼
$.when(runAsync(), runAsync2(), runAsync3())
.then( function (data1, data2, data3){
    console.log( '全部執行完成' );
    console.log(data1, data2, data3);
});
複製代碼
jquery中沒有像ES6中的race方法嗎?就是以跑的快的為準的那個方法。對的,jquery中沒有。

以上就是jquery中Deferred對象的常用方法了,還有一些其他的方法用的也不多,乾脆就不記它了。接下來該說說ajax了。

ajax與Deferred的關係
jquery的ajax返回一個受限的Deferred對象,還記得受限的Deferred對象吧,也就是沒有resolve方法和reject方法,不能從外部改變狀態。想想也是,你發一個ajax請求,別人從其他地方給你取消掉了,也是受不了的。

既然是Deferred對象,那麼我們上面講到的所有特性,ajax也都是可以用的。比如鍊式調用,連續發送多個請求:
複製代碼
req1 = function (){
     return $.ajax( /* ... */ );
}
req2 = function (){
     return $.ajax( /* ... */ );
}
req3 = function (){
     return $.ajax( /* ... */ );
}

req1().then(req2).then(req3).done( function (){
    console.log( '請求發送完畢' );
});
複製代碼
明白了ajax返回對象的實質,那我們用起來就得心應手了。

success、error與complete
這三個方法或許是我們用的最多的,使用起來是這樣的:
$.ajax( /* ... */ )
.success( function (){ /* ... */ })
.error( function (){ /* ... */ })
.complete( function (){ /* ... */ })
分別表示ajax請求成功、失敗、結束的回調。這三個方法與Deferred又是什麼關係呢?其實就是語法糖,success對應done,error對應fail,complete對應always,就這樣,只是為了與ajax的參數名字上保持一致而已,更方便大家記憶,看一眼源碼:
deferred.promise( jqXHR ).complete = completeDeferred.add;
jqXHR.success = jqXHR.done;
jqXHR.error = jqXHR.fail;
complete那一行那麼寫,是為了減少重複代碼,其實就是把done和fail又調用一次,與always中的代碼一樣。deferred.promise( jqXHR )這句也能看出,ajax返回的是受限的Deferred對象。

jquery加了這麼些個語法糖,雖然上手門檻更低了,但是卻造成了一定程度的混淆。一些人雖然這麼寫了很久,卻一直不知道其中的原理,在面試的時候只能答出一些皮毛,這是很不好的。這也是我寫這篇文章的緣由。

jquery中Deferred對象涉及到的方法很多,本文盡量分門別類的來介紹,希望能幫大家理清思路。總結一下就是:$.Deferred實現了Promise規範,then、done、fail、always是Deferred對象的方法。$.when是一個全局的方法,用來並行運行多個異步任務,與ES6的all是一個功能。ajax返回一個Deferred對象,success、error、complete是ajax提供的語法糖,功能與Deferred對象的done、fail、always一致。

《面試官別再問》php之api接口的設計

GET從服務器取出資源
POST在服務器新建一個資源
PUT在服務器更新資源(客戶端提供改變後的完整資源)
PATCH在服務器更新資源(客戶端提供改變的屬性)
DELETE從服務器刪除資源
HEAD獲取資源的源數據
OPTION獲取信息關於資源的那些屬性是客戶端可以改變的

接口的安全性

選https協議代替http協議這樣,避免明文傳輸數據

對一些開放的接口做數字簽名

對有登錄操作的接口,先通過登錄獲取訪問的令牌,之後訪問其他需要登錄的接口
通過攜帶這個令牌進行訪問。

登錄認證機制中session和jwt對比

session的登錄原理:客戶端(client)提交用戶名密碼(或驗證碼)給服務端(server),服務端校驗通過後,
服務端會生成身份認證相關的session數據,服務端將session數據保存在文件或者內存中,並且將session_id返
回給客戶端,客戶端將返回的session_id保存在cookie中。此後客戶端請求服務端時都會在cookie中攜帶session_id。
服務端通過校驗session信息是否存在,如果存在判斷用戶是否處於登錄狀態以及用戶具有的權限。通過校驗就返回該有的
數據,沒通過校驗返回登錄頁。
session的優勢和劣勢
優勢:
1. session可以主動清除
2. session保存在服務端相對安全
3.結合cookie使用較為靈活兼容性好
劣勢:
1. cookie+ session在跨域場景下表現不好
2.如果是分佈式部署,需要多機器共享session機制,實現方法可將session存儲到數據庫或者redis
中,這樣查詢session信息時需要進行數據庫的操作
3.基於cookie的機制很容易被CSRF攻擊

jwt的登錄原理:客戶端(client)提交用戶名密碼(或驗證碼)給服務端(server),服務端校驗通過後,將用戶的id和其它信息做為JWT playload(負載),將其與頭部分別進行Base64編碼拼接後簽名,形成一個JWT,形成的JWT就是形同,lll.zzz.xxx的字符串。後端將JWT字符串作為登錄成功的返回結果,返回給前端。前端可以將返回結果保存在localStorge或sessionStorage上,退出登錄前刪除保存的JWT即可。前端在每次請求時將JWT放在http header中的Authorization位(解決XSS和XSRF攻擊)。後端檢查是否存在,如果存在驗證JWT的有效性。例如檢查簽名是否正確,檢查token是否過期檢查token的接受方是否是自己(可選)驗證通過後,後端使用JWT中包含的用戶信息進行其他的邏輯操作,返回相應的結果。

jwt和session的區別
session的狀態是存儲在服務端的,客戶端只存儲session_id ,而token的狀態存儲在客戶端
(因為信息全部放在客戶端所以需要密碼學的方法進行簽名和加密)分佈式系統中session共享是一個問題,session存在服務端,隨著用戶數量增多,會大幅降低服務端的性能在多個域名下,會存在跨域問題,安全性方面cookie保存在本地,容易被人利用進行CSRF攻擊

2018年11月20日 星期二

《面試官別再問》什麼是索引,作用是什麼?常見索引類型有那些?Mysql 建立索引的原則?

索引是一種特殊的文件,它們包含著對數據表裡所有記錄的引用指針,相當於書本的目錄。其作用就是加快數據的檢索效率。常見索引類型有主鍵、唯一索引、複合索引、全文索引。

第一,通過創建唯一性的索引,可以保證數據庫表中每一行數據的唯一性。
第二,可以大大加快數據的檢索速度,這也使創建索引的最主要的原因。
第三,可以加速表和表之間的連接,特別是在實現數據的參考完整性方面特別有意義。
第四,在使用分組和排序子句進行數據檢索時,同樣可以顯著的減少查詢中查詢中分組和排序的時間。
第五,通過使用索引,可以在查詢的過程中,使用優化隱藏器,提高系統的性能。

增加索引也有許多不利的方面。
第一,創建索引和維護索引需要消耗時間,這種時間隨著數量的增加而增加。
第二,索引需要佔物理空間,除了數據表佔據數據空間之外,每一個索引還要佔一定的物理空間,如果要建立聚簇索引,那麼需要額空間就會更大。
第三,當對錶中的數據進行增加,刪除和修改的時候,索引也要動態的維護,這樣就降低了數據的維護速度。

應該對如下的列建立索引

在作為主鍵的列上,強制該列的唯一性和組織表中數據的排列結構。
在經常用在連接的列上,這些列主要是一些外鍵,可以加快連接的速度。
在經常需要根據范圍進行搜索的列上創建索引,因為索引已經排序,其指定的範圍是連續的。
在經常需要排序的列上創建索引,因為索引已經排序,這樣查詢可以利用索引的排序,加快排序查詢時間。
在經常使用在where子句中的列上面創建索引,加快條件的判斷速度。
有些列不應該創建索引

在查詢中很少使用或者作為參考的列不應該創建索引。
對於那些只有很少數據值的列也不應該增加索引(比如性別,結果集的數據行佔了表中數據行的很大比例,即需要在表中搜索的數據行的比例很大。增加索引,並不能明顯加快檢索速度)。
對於那些定義為text,image和bit數據類型的列不應該增加索引。這是因為,這些列的數據量要么相當大,要么取值很少。
當修改性能遠遠大於檢索性能時,不應該創建索引,因為修改性能和檢索性能是矛盾的。
創建索引的方法:直接創建和間接創建(在表中定義主鍵約束或者唯一性約束時,同時也創建了索引)。
索引的特徵:
唯一性索引和復合索引。唯一性索引保證在索引列中的全部數據是唯一的,不會包含冗餘數據。複合索引就是一個索引創建在兩個列或者多個列上。可以減少一在一個表中所創建的索引數量。

《面試官別再問》Laravel框架一:原理機制篇

一. 請求週期

Laravel 採用了單一入口模式,應用的所有請求入口都是 public/index.php 文檔。

註冊類文檔自動加載器:Laravel通過composer進行依賴管理,並在bootstrap/autoload.php中註冊了Composer Auto Loader (PSR-4),應用中類的命名空間將被映射到類文檔實際路徑,不再需要開發者手動導入各種類文檔,而由自動加載器自行導入。因此,Laravel允許你在應用中定義的類可以自由放置在Composer Auto Loader能自動加載的任何目錄下,但大多數時候還是建議放置在app目錄下或app的某個子目錄下
創建服務容器:從 bootstrap/app.php 文檔中取得 Laravel 應用實例 $app (服務容器)
創建 HTTP / Console 內核:傳入的請求會被髮送給 HTTP 內核或者 console 內核進行處理,HTTP 內核繼承自 Illuminate\Foundation\Http\Kernel 類。它定義了一個bootstrappers 數組,數組中的類在請求真正執行前進行前置執行,這些引導進程配置了錯誤處理,日誌記錄,檢測應用進程環境,以及其他在請求被處理前需要完成的工作;HTTP內核同時定義了一個HTTP 中間件列表,所有的請求必須在處理前通過這些中間件處理HTTP session 的讀寫,判斷應用是否在維護模式, 驗證CSRF token 等等
載入服務提供者至容器:在內核引導啟動的過程中最重要的動作之一就是載入服務提供者到你的應用,服務提供者負責引導啟動框架的全部各種組件,例如數據庫、隊列、驗證器以及路由組件。因為這些組件引導和配置了框架的各種功能,所以服務提供者是整個 Laravel 啟動過程中最為重要的部分,所有的服務提供者都配置在 config/app.php 文檔中的 providers 數組中。首先,所有提供者的 register 方法會被調用;一旦所有提供者註冊完成,接下來,boot 方法將會被調用
分發請求:一旦應用完成引導和所有服務提供者都註冊完成,Request 將會移交給路由進行分發。路由將分發請求給一個路由或控制器,同時運行路由指定的中間件

二. 服務容器和服務提供者

服務容器是Laravel 管理類依賴和運行依賴注入的有力工具,在類中可通過$this->app 來訪問容器,在類之外通過$app 來訪問容器;服務提供者是Laravel 應用進程引導啟動的中心,關係到服務提供者自身、事件監聽器、路由以及中間件的啟動運行。應用進程中註冊的路由通過RouteServiceProvider實例來加載;事件監聽器在EventServiceProvider類中進行註冊;中間件又稱路由中間件,在app/Http/Kernel.php類文檔中註冊,調用時與路由進行綁定。在新創建的應用中,AppServiceProvider 文檔中方法實現都是空的,這個提供者是你添加應用專屬的引導和服務的最佳位置,當然,對於大型應用你可能希望創建幾個服務提供者,每個都具有粒度更精細的引導。服務提供者在 config/app.php 配置文檔中的providers數組中進行註冊

三、Artisan Console

Laravel利用PHP的CLI構建了強大的Console工具artisan,artisan幾乎能夠創建任何你想要的模板類以及管理配置你的應用,在開發和運維管理中扮演着極其重要的角色,artisan是Laravel開發不可或缺的工具。在Laravel根目錄下運行:PHP artisan list可查看所有命令行表。用好artisan能極大地簡化開發工作,並減少錯誤發生的可能;另外,還可以編寫自己的命令。下面列舉部分比較常用的命令:

啟用維護模式:php artisan down --message='Upgrading Database' --retry=60
關閉維護模式:php artisan up
生成路由緩存:php artisan route:cache
清除路由緩存:php artisan route:clear
數據庫遷移 Migrations:php artisan make:migration create_users_table --create=users
創建資源控制器:php artisan make:controller PhotoController --resource --model=Photo
創建模型及遷移:php artisan make:model User -m

四、表單驗證機制

  表單驗證在web開發中是不可或缺的,其重要性也不言而喻,也算是每個web框架的標配部件了。Laravel表單驗證擁有標準且龐大的規則集,通過規則調用來完成數據驗證,多個規則組合調用須以“|”符號連接,一旦驗證失敗將自動回退並可自動綁定視圖。

  下例中,附加bail規則至title屬性,在第一次驗證required失敗後將立即停止驗證;“.”語法符號在Laravel中通常表示嵌套包含關係,這個在其他語言或框架語法中也比較常見

$this->validate($request, [
    'title' => 'bail|required|unique:posts|max:255',
    'author.name' => 'required',
    'author.description' => 'required',
]);

五、Eloquent 模型

  Eloquent ORM 以ActiveRecord形式來和數據庫進行交互,擁有全部的數據表操作定義,單個模型實例對應數據表中的一行

1 $flights = App\Flight::where('active', 1)
2 ->orderBy('name', 'desc')
3 ->take(10)
4 ->get();

config/database.php中包含了模型的相關配置項。Eloquent 模型約定:

數據表名:模型以單數形式命名(CamelCase),對應的數據表為蛇形複數名(snake_cases),模型的$table屬性也可用來指定自定義的數據表名稱
主鍵:模型默認以id為主鍵且假定id是一個遞增的整數值,也可以通過$primaryKey來自定義;如果主鍵非遞增數字值,應設置$incrementing = false
時間戳:模型會默認在你的數據庫表有 created_at 和 updated_at 字段,設置$timestamps = false可關閉模型自動維護這兩個字段;$dateFormat 屬性用於在模型中設置自己的時間戳格式
數據庫連接:模型默認會使用應用進程中配置的數據庫連接,如果你想為模型指定不同的連接,可以使用 $connection 屬性自定義
批量賦值:當用户通過 HTTP 請求傳入了非預期的參數,並藉助這些參數 create 方法更改了數據庫中你並不打算要更改的字段,這時就會出現批量賦值(Mass-Assignment)漏洞,所以你需要先在模型上定義一個 $fillable(白名單,允許批量賦值字段名數組) 或 $guarded(黑名單,禁止批量賦值字段名數組)
1 // 用屬性取回航班,當結果不存在時創建它...
2 $flight = App\Flight::firstOrCreate(['name' => 'Flight 10']);
3
4 // 用屬性取回航班,當結果不存在時實例化一個新實例...
5 $flight = App\Flight::firstOrNew(['name' => 'Flight 10']);

六、Laravel的Restful風格

  一般認為Restful風格的資源定義不包含操作,但是在Laravel中操作(動詞)也可作為一種資源來定義。下圖是對Laravel中資源控制器操作原理的描述,可以看到,create、edit就直接出現在了URI中,它們是一種合法的資源。對於create和edit這兩種資源的訪問都採用GET方法來實現,第一眼看到頓感奇怪,後來嘗試通過artisan console生成資源控制器,並注意到其對create、edit給出註釋“ Show the form for ”字樣,方知它們只是用來展現表單而非提交表單的。

《面試官別再問》什麼是CGI?什麼是FastCGI?php-fpm,FastCGI,Nginx 之間是什麼關係?

CGI、FastCGI 與 PHP-FPM:從 Web 伺服器效能瓶頸說起

在現代 Web 開發中,高效能的伺服器架構是網站穩定運行的基石。然而,許多剛接觸後端開發的工程師,對於 NginxFastCGIPHP-FPM 這幾個關鍵詞的關係感到困惑。要真正理解它們,我們需要從 Web 伺服器與動態應用程式溝通的最原始方式——CGI 談起。

1. CGI:開創動態網頁的元老,但效率低落

CGI (Common Gateway Interface) 是 Web 伺服器與外部應用程式(如 PHP、Perl 腳本)互動的最初標準。它的工作模式簡單而粗暴:

  1. 使用者發送一個動態請求。

  2. Web 伺服器(如 Apache)接收請求後,為此請求啟動一個全新的進程

  3. 這個新進程負責執行腳本,處理業務邏輯,並產生 HTML 內容。

  4. 進程執行完畢後,立即終止

這種「一請求一進程」的模式,在流量低時還能應付,但當網站流量一高,Web 伺服器會不斷地重複「建立進程 -> 執行腳本 -> 銷毀進程」的動作。進程的啟動與銷毀本身就是一筆不小的系統開銷,這會迅速耗盡伺服器的 CPU 和記憶體資源,導致效能瓶頸。簡單來說,CGI 就像是每次接待一位客人,都要重新蓋一棟房子,用完就拆掉。這種方式顯然是無法規模化的。


2. FastCGI:持久化的進程,效能大幅提升

為了解決 CGI 的效能問題,FastCGI (Fast Common Gateway Interface) 應運而生。它是一種協議,核心思想是用持久化的進程來處理請求

FastCGI 的工作模式完全不同:

  1. Web 伺服器在啟動時,不會直接處理動態請求,而是將這些請求轉發給一個或多個已經在後台持續運行的 FastCGI 進程

  2. 這些 FastCGI 進程會形成一個「進程池」,隨時準備接收請求。

  3. Web 伺服器與這些 FastCGI 進程之間會建立一個長久存在的通訊介面(通常是 TCP/IP SocketUnix Domain Socket)。

  4. 當請求到達時,Web 伺服器透過這個介面將請求內容傳送給一個空閒的 FastCGI 進程。

  5. 進程處理完請求後,將結果回傳,然後繼續等待下一個請求,而不是結束。

這種方式避免了頻繁地創建和銷毀進程的開銷,極大地提升了伺服器處理動態請求的效能。FastCGI 就像是建了一座餐館,服務生(FastCGI 進程)隨時待命,客人一來就能馬上點餐,服務結束後服務生繼續等待下一位客人,無需重複建拆餐館。


3. Nginx、PHP-FPM 與 FastCGI 協議的完美協作

在現代的 Web 伺服器架構中,Nginx 搭配 PHP-FPM 是主流選擇。它們之間的關係可以這樣總結:

  • Nginx:高效能的 Web 伺服器。它的角色是門面反向代理,負責接收所有來自外部的 HTTP 請求。它擅長處理靜態檔案(如圖片、CSS、JS)和高效能的併發連接

  • PHP-FPM (PHP FastCGI Process Manager):PHP 的 FastCGI 進程管理器。它是一個實現了 FastCGI 協議的軟體,專門用來管理多個 PHP 解析器進程,形成一個進程池

  • FastCGI:Nginx 與 PHP-FPM 之間唯一的通訊語言

它們的協作流程如下:

  1. 使用者請求 http://example.com/index.php

  2. Nginx 接收到請求,判斷出這是一個 PHP 腳本。

  3. Nginx 知道自己無法執行 PHP,於是它根據設定檔(例如 fastcgi_pass 127.0.0.1:9000;),透過 FastCGI 協議,將這個請求轉發給運行在 9000 埠的 PHP-FPM

  4. PHP-FPM 從它的進程池中找到一個空閒的 PHP 工作進程,並將請求交給它。

  5. 這個 PHP 進程執行 index.php 腳本,處理完後將結果(HTML、JSON 等)回傳給 PHP-FPM。

  6. PHP-FPM 再將結果透過 FastCGI 協議回傳給 Nginx

  7. 最後,Nginx 將這個結果組合成一個完整的 HTTP 回應,發送給使用者的瀏覽器。

這個分工模型非常清晰且高效:Nginx 專注於處理網路 I/O 和靜態內容,PHP-FPM 專注於高效地處理 PHP 程式碼。兩者透過 FastCGI 協議無縫銜接,共同提供高效能的動態網頁服務。這也是為什麼 Nginx + PHP-FPM 成為當今主流 Web 伺服器架構的原因。

熱門文章