cli執行php

Ⅰ linux伺服器上運行php，除了PHP-FPM還有其他的方式嗎

運行模式
關於PHP目前比較常見的五大運行模式：
1）CGI（通用網關介面/ Common Gateway Interface）
2）FastCGI（常駐型CGI / Long-Live CGI）
3）CLI（命令行運行 / Command Line Interface）
4）Web模塊模式（Apache等Web伺服器運行的模式）
5）ISAPI（Internet Server Application Program Interface）

備註：在PHP5.3以後，PHP不再有ISAPI模式，安裝後也不再有php5isapi.dll這個文件。要在IIS6上使用高版本PHP，必須安裝FastCGI 擴展，然後使IIS6支持FastCGI。

1.1、CGI模式
CGI即通用網關介面（Common Gateway Interface），它是一段程序，通俗的講CGI就象是一座橋，把網頁和Web伺服器中的執行程序連接起來，它把HTML接收的指令傳遞給伺服器的執行程序，再把伺服器執行程序的結果返還給HTML頁。CGI 的跨平台性能極佳，幾乎可以在任何操作系統上實現。CGI已經是比較老的模式了，這幾年都很少用了。
每有一個用戶請求，都會先要創建CGI的子進程，然後處理請求，處理完後結束這個子進程，這就是Fork-And-Execute模式。 當用戶請求數量非常多時，會大量擠占系統的資源如內存，CPU時間等，造成效能低下。所以用CGI方式的伺服器有多少連接請求就會有多少CGI子進程，子進程反復載入是CGI性能低下的主要原因。
如果不想把 PHP 嵌入到伺服器端軟體（如 Apache）作為一個模塊安裝的話，可以選擇以 CGI 的模式安裝。或者把 PHP 用於不同的 CGI 封裝以便為代碼創建安全的 chroot 和 setuid 環境。這樣每個客戶機請求一個PHP文件，Web伺服器就調用php.exe（win下是php.exe,linux是php）去解釋這個文件，然後再把解釋的結果以網頁的形式返回給客戶機。 這種安裝方式通常會把 PHP 的可執行文件安裝到 web 伺服器的 cgi-bin 目錄。CERT 建議書 CA-96.11 建議不要把任何的解釋器放到 cgi-bin 目錄。 這種方式的好處是把Web Server和具體的程序處理獨立開來，結構清晰，可控性強，同時缺點就是如果在高訪問需求的情況下，CGI的進程Fork就會成為很大的伺服器負擔，想 象一下數百個並發請求導致伺服器Fork出數百個進程就明白了。這也是為什麼CGI一直背負性能低下，高資源消耗的惡名的原因。

1.2、FastCGI模式
FastCGI是CGI的升級版本，FastCGI像是一個常駐 (long-live)型的 CGI，它可以一直執行著，只要激活後，不會每次都要花費時間去 Fork 一次 （這是 CGI 最為人詬病的 fork-and-execute 模式）。
FastCGI是一個可伸縮地、高速地在HTTP server和動態腳本語言間通信的介面。多數流行的HTTP server都支持FastCGI，包括Apache、Nginx和lighttpd等，同時，FastCGI也被許多腳本語言所支持，其中就有PHP。
FastCGI介面方式採用C/S結構，可以將HTTP伺服器和腳本解析伺服器分開，同時在腳本解析伺服器上啟動一個或者多個腳本解析守護進程。當HTTP伺服器每次遇到動態程序時，可以將其直接交付給FastCGI進程來執行，然後將得到的結果返回給瀏覽器。這種方式可以讓HTTP伺服器專一地處理靜態請求或者將動態腳本伺服器的結果返回給客戶端，這在很大程度上提高了整個應用系統的性能。

【原理】
1）Web Server啟動時載入FastCGI進程管理器（IIS ISAPI或Apache Mole)；
2）FastCGI進程管理器自身初始化，啟動多個CGI解釋器進程 (可見多個php-cgi.exe或php-cig)並等待來自Web Server的連接；
3）當客戶端請求到達Web Server時，FastCGI進程管理器選擇並連接到一個CGI解釋器。Web server將CGI環境變數和標准輸入發送到FastCGI子進程php-cgi；
4）FastCGI子進程完成處理後將標准輸出和錯誤信息從同一連接返回Web Server。當FastCGI子進程關閉連接時，請求便告處理完成。FastCGI子進程接著等待並處理來自FastCGI進程管理器（運行在 WebServer中）的下一個連接。在正常的CGI模式中，php-cgi.exe在此便退出了。
在CGI模式中，你可以想像 CGI通常有多慢。每一個Web請求PHP都必須重新解析php.ini、重新載入全部dll擴展並重初始化全部數據結構。使用FastCGI，所有這些都只在進程啟動時發生一次。一個額外的好處是，持續資料庫連接（Persistent database connection）可以工作。

備註：PHP的FastCGI進程管理器是PHP-FPM（PHP-FastCGI Process Manager）
【優點】
1）從穩定性上看，FastCGI是以獨立的進程池來運行CGI，單獨一個進程死掉，系統可以很輕易的丟棄，然後重新分配新的進程來運行邏輯；
2）從安全性上看，FastCGI支持分布式運算。FastCGI和宿主的Server完全獨立，FastCGI怎麼down也不會把Server搞垮；
3）從性能上看，FastCGI把動態邏輯的處理從Server中分離出來，大負荷的IO處理還是留給宿主Server，這樣宿主Server可以一心一意作IO，對於一個普通的動態網頁來說, 邏輯處理可能只有一小部分，大量的是圖片等靜態。

【缺點】
說完了好處，也來說說缺點。從我的實際使用來看，用FastCGI模式更適合生產環境的伺服器。但對於開發用機器來說就不太合適。因為當使用 Zend Studio調試程序時，由於 FastCGI會認為 PHP進程超時，從而在頁面返回 500錯誤。這一點讓人非常惱火，所以我在開發機器上還是換回了 ISAPI模式。對某些伺服器的新版本支持不好，對分布式負載均衡沒要求的模塊化安裝是否是更好的選擇。目前的FastCGI和Server溝通還不夠智能，一個FastCGI進程如果執行時間過長會被當成是死進程殺掉重起，這樣在處理長時間任務的時候很麻煩，這樣做也使得FastCGI無法允許聯機調試。因為是多進程，所以比CGI多線程消耗更多的伺服器內存，PHP-CGI解釋器每進程消耗7至25兆內存，將這個數字乘以50或100就是很大的內存數。

1.3 CLI模式
PHP-CLI是PHP Command Line Interface的簡稱，如同它名字的意思，就是PHP在命令行運行的介面，區別於在Web伺服器上運行的PHP環境（PHP-CGI，ISAPI等）。 也就是說，PHP不單可以寫前台網頁，它還可以用來寫後台的程序。 PHP的CLI Shell腳本適用於所有的PHP優勢，使創建要麼支持腳本或系統甚至與GUI應用程序的服務端，在Windows和Linux下都是支持PHP-CLI模式的。
【優點】
1）使用多進程，子進程結束以後，內核會負責回收資源；
2）使用多進程，子進程異常退出不會導致整個進程Thread退出，父進程還有機會重建流程；
3）一個常駐主進程，只負責任務分發，邏輯更清楚。
我們在Linux下經常使用"php –m"查找PHP安裝了那些擴展就是PHP命令行運行模式；有興趣的同學可以輸入"php –h"去深入研究該運行模式。

1.4 模塊模式
模塊模式是以mod_php5模塊的形式集成，此時mod_php5模塊的作用是接收Apache傳遞過來的PHP文件請求，並處理這些請求，然後將處理後的結果返回給Apache。如果我們在Apache啟動前在其配置文件中配置好了PHP模塊
（mod_php5）， PHP模塊通過注冊apache2的ap_hook_post_config掛鉤，在Apache啟動的時候啟動此模塊以接受PHP文件的請求。
除了這種啟動時的載入方式，Apache的模塊可以在運行的時候動態裝載，這意味著對伺服器可以進行功能擴展而不需要重新對源代碼進行編譯，甚至根本不需要停止伺服器。我們所需要做的僅僅是給伺服器發送信號HUP或者AP_SIG_GRACEFUL通知伺服器重新載入模塊。但是在動態載入之前，我們需要將模塊編譯成為動態鏈接庫。此時的動態載入就是載入動態鏈接庫。 Apache中對動態鏈接庫的處理是通過模塊mod_so來完成的，因此mod_so模塊不能被動態載入，它只能被靜態編譯進Apache的核心。這意味著它是隨著Apache一起啟動的。
Apache是如何載入模塊的呢？我們以前面提到的mod_php5模塊為例。首先我們需要在Apache的配置文件httpd.conf中添加一行：
LoadMole php5_mole moles/mod_php5.so

這里我們使用了LoadMole命令，該命令的第一個參數是模塊的名稱，名稱可以在模塊實現的源碼中找到。第二個選項是該模塊所處的路徑。如果需要在伺服器運行時載入模塊，可以通過發送信號HUP或者AP_SIG_GRACEFUL給伺服器，一旦接受到該信號，Apache將重新裝載模塊，而不需要重新啟動伺服器。
該運行模式是我們以前在windows環境下使用apache伺服器經常使用的，而在模塊化（DLL）中，PHP是與Web伺服器一起啟動並運行的。（它是apache在CGI的基礎上進行的一種擴展，加快PHP的運行效率）。

1.5 ISAPI模式
ISAPI（Internet Server Application Program Interface）是微軟提供的一套面向Internet服務的API介面，一個ISAPI的DLL，可以在被用戶請求激活後長駐內存，等待用戶的另一個請求，還可以在一個DLL里設置多個用戶請求處理函數，此外，ISAPI的DLL應用程序和WWW伺服器處於同一個進程中，效率要顯著高於CGI。（由於微軟的排他性，只能運行於windows環境）
PHP作為Apache模塊，Apache伺服器在系統啟動後，預先生成多個進程副本駐留在內存中，一旦有請求出現，就立即使用這些空餘的子進程進行處理，這樣就不存在生成子進程造成的延遲了。這些伺服器副本在處理完一次HTTP請求之後並不立即退出，而是停留在計算機中等待下次請求。對於客戶瀏覽器的請求反應更快，性能較高。

Ⅱ Php cli是守護進程的嗎

php_cli模式簡介

php-cli是php Command Line Interface的簡稱，如同它名字的意思，就是php在命令行運行的介面，區別於在Web伺服器上運行的php環境（php-cgi, isapi等） 也就是說，php不單可以寫前台網頁，它還可以用來寫後台的程序。 PHP的CLI shell腳本適用於所有的PHP優勢，使創建要麼支持腳本或系統甚至與GUI應用程序的服務端！——註：windows和linux下都支持php_cli模式

PHP-cli應用場景：

1.多線程應用
這方面的好處，引用鳥哥的話：

優點:
1. 使用多進程, 子進程結束以後, 內核會負責回收資源
2. 使用多進程,子進程異常退出不會導致整個進程Thread退出. 父進程還有機會重建流程.
3. 一個常駐主進程, 只負責任務分發, 邏輯更清楚.

php的多線程—沒錯就是php多線程應用，雖然大家都普遍認為php沒有多線程（curl屬於模擬多線程而不是真實的），但是在php_cli模式下的php徹底的是屬於多線程。這個時候php屬於linux的一個守護進程。 在本人之前寫過的《PHP多線程批量採集下載美女圖片(續)》的時候在採集程序里雖然使用curl來模擬多線程，但是在瀏覽器執行的時候也是會遇到執行超時或內存abort而導致程序中斷，（要嘗試幾次才可以徹底成功），但是如果在php-cli模式下執行，你就會發現這個程序執行的很快，php多線程執行的優勢被徹底表現出來了.

備注:這種多線程方式不是很成熟，不適合大規模的生成應用，偶爾使用還是可以的

2.定時執行php程序

利用linux的cron方式，那麼這個方式是如何定時執行php程序？請看下文

3.開發桌面程序

你可以做您的Windows或Linux中使用PHP的圖形用戶界面（GUI）應用！所有你需要的是PHP的命令行介面和一包GTK。這將允許建立真正的攜帶型圖形用戶界面應用程序（呵呵，之前只是知道php可以做桌面程序，現在才知道是使用php_cli模式），並且不需要學習別的。

4.編寫PHP的shell腳本
如果你不會bash shell或者Perl等的使用，但是你又需要一些腳本去執行的時候，怎麼辦？這個時候你完全可以使用你熟悉的php編寫shell腳本，這個時候你是不是突然感覺PHP是不是太強大了！—–真正做到一種語言，到處開發！

PHP_CLI使用方法

win下面的執行方法：
假設php.exe 在D:xamppphp在dos命令在可以這個執行：

復制代碼 代碼如下:D:xamppphpphp.exe D:xampphtdocstest.php

就可以執行test.php這個文件了 。這里推薦win平台下xampp集成環境，真正比wamp強大N倍，這個集成包可以直接進入dos模式。

linux下php_cli使用
首先找到你安裝php的路徑，以我為例：



當然實現的方法不止一個，大家可以嘗試其他方法實現！

例外關於php的cli還有很多參數可以加入：具體可以參考：http://php.net/manual/en/features.commandline.php

關於定時執行
cron是一個linux下的定時執行工具，可以在無需人工干預的情況下運行作業，周期性作業，比如備份數據 打開/etc/crontab，添加：
復制代碼 代碼如下:
/usr/bin/php -f /data/htdocs/test.php

Ⅲ 如何防止PHP進程異常退出

通常，在cli下運行的常駐後台PHP進程，可能異常退出，比如php執行過程中出現的致命錯誤，或被 kill 命令手動殺死等。如下面的php代碼：
while(1){
$content = fgets(STDIN);
if(empty($content)){
sleep(1);
}
//邏輯處理部分代碼省略
}
排查過程
我們使用register_shutdown_function來跟蹤下到底是什麼錯誤導致的進程退出。(想更多了解register_shutdown_function，請查看博文 妙用php中的register_shutdown_function和fastcgi_finish_request )加入了錯誤捕捉代碼。如下：
$is_end = false;
function catch_error(){
global $is_end;
$time = date('Y-m-d H:i:s');
$error = error_get_last();
$msg = "$time [error]";
if($is_end){
$msg .= "is_end[yes]";
}else{
$msg .= "is_end[no]";
}
if($error){
$msg .= var_export($error,1);
}
echo $msg."\r\n";
}
register_shutdown_function("catch_error");
可是，php進程再次退出。而在日誌中並沒有記錄任何信息。說明register_shutdown_function方法根本沒有執行。是什麼導致register_shutdown_function方法沒有運行呢？在php的官方文檔中又這樣一個注釋：
Shutdown functions will not be executed if the process is killed with a SIGTERM or SIGKILL signal. While you cannot intercept a SIGKILL, you can use pcntl_signal() to install a handler for a SIGTERM which uses exit() to end cleanly.
注釋的意思是當php進程獲得SIGTERM和SIGKILL信號而退出時，是不執行register_shutdown_function方法的。可以使用pcntl_signal()方法來捕獲信息，並調用相應的處理方法。
好，那是不是信號導致我們的php進程退出呢？我們加入如下代碼：
declare(ticks = 1);
function sig_handler($signo){
$time = date('Y-m-d H:i:s');
echo $time." exit signo[{$signo}]\r\n";
exit("");
}
pcntl_signal(SIGTERM, "sig_handler");
pcntl_signal(SIGHUP, "sig_handler");
pcntl_signal(SIGINT, "sig_handler");
pcntl_signal(SIGQUIT, "sig_handler");
pcntl_signal(SIGILL, "sig_handler");
pcntl_signal(SIGPIPE, "sig_handler");
pcntl_signal(SIGALRM, "sig_handler");
過一段時間，發現php進程退出了，日誌中出現了如下日誌信息：
2014-11-23 18:30:06 exit signo[14]
2014-11-23 18:30:06 [error]is_end[no]
看來是sigalarm信號導致php進程退出了。這個信號是可以捕獲和處理的。這樣無關緊要的信號，我們還是忽略吧。最終的代碼如下：
declare(ticks = 1);
$is_end = false;
function catch_error(){
global $is_end;
$time = date('Y-m-d H:i:s');
$error = error_get_last();
$msg = "$time [error]";
if($is_end){
$msg .= "is_end[yes]";
}else{
$msg .= "is_end[no]";
}
if($error){
$msg .= var_export($error,1);
}
echo $msg."\r\n";
}
register_shutdown_function("catch_error");
function sig_handler($signo){
$time = date('Y-m-d H:i:s');
if($signo == 14){
//忽略alarm信號
echo $time." ignore alarm signo[{$signo}]\r\n";
}else{
echo $time." exit signo[{$signo}]\r\n";
exit("");
}
}
pcntl_signal(SIGTERM, "sig_handler");
pcntl_signal(SIGHUP, "sig_handler");
pcntl_signal(SIGINT, "sig_handler");
pcntl_signal(SIGQUIT, "sig_handler");
pcntl_signal(SIGILL, "sig_handler");
pcntl_signal(SIGPIPE, "sig_handler");
pcntl_signal(SIGALRM, "sig_handler");
while(1){
$content = fgets(STDIN);
if(empty($content)){
sleep(1);
}
//邏輯處理部分代碼省略
}
$is_end = true;
經過一段觀察，在日誌中又發現了alarm相關的日誌，但是php進程依然在。看來我們的修改有作用了。

Ⅳ 在記事本里寫好的PHP代碼 要怎樣運行

PHP的運行分兩種，一種是CLI，一種是CGI/FASTCGI。
第一種你只要在你的console里邊（win下是cmd，linux就是terminal）輸入php path_to_your_php_file.php就好了，如果你沒有把php.exe配置進你的系統變數里，還需要把php改成php/php.exe。
第二種如1樓，需要cgi運行環境，也就是要一個伺服器，也就是一樓介紹的，除了1樓的apache還可以選擇其他的如IIS,NGINX等server，至於如何配置，請自行檢索，很長，就不寫了。

Ⅳ php報錯，找不到指定模塊，Fatal error

如果你在使用命令行運行 `php -v` 時遇到 "Fatal error: 找不到指定模塊" 的錯誤，這可能是由於 PHP CLI（Command Line Interface）與你的本地伺服器環境存在差異導致的。
PHP CLI 和本地伺服器使用的 PHP 版本和配置可能不同。請嘗試以下解決方法：
1. 確認 PHP CLI 安裝：確保你已正確安裝了 PHP CLI，並且可以從命令行中訪問到它。你可以通過運行 `which php` 命令來查看 PHP CLI 的路徑。如果沒有找到，請檢查你的系統是否正確安裝了 PHP CLI。
2. 檢查 PHP 配置文件：PHP CLI 使用的配置文件可能與本地伺服器不同。你可以通過運行 `php --ini` 命令來查看 PHP CLI 使用的配置文件路徑。確保該配置文件存在並包含所需的模塊載入語句。
3. 檢查擴展模塊載入：如果報錯指明找不到某個特定的模塊，例如 MySQL 或 GD 等，那麼可能是因為 PHP CLI 缺少相應的擴展模塊。你可以編輯 PHP CLI 的配置文件（如上一步所示），啟用或載入所需的擴展模塊。具體操作方式取決於你的操作系統和 PHP 版本。
4. 更新 PHP 版本：如果以上方法都無效，你可以考慮更新你的 PHP 版本。較新的 PHP 版本通常包含更多功能和修復了一些問題。請注意，更新 PHP 版本可能需要你重新配置和調整你的代碼。
如果問題仍然存在，請提供更詳細的錯誤信息、PHP 版本以及操作系統等相關信息，我再幫你解決。