① php swoole 只能運行在php-cli 環境嗎
一直想寫點Swoole的東西，畢竟它重新定義了php，卻一直不知道怎麼下手寫Swoole涉及的知識點非常多，互為表裡，每次想寫都發現根本理不出一個頭緒Swoole是一個php的擴展，它的核心目的就是解決php在實現server服務中可能遇到的一系列問題，這些問題用源生的php往往並不能很高效（執行效率）的解決，一般也不會使用php來解決，所以會有說swolle重新定義的php的說法。
其實swoole也提供了一個框架，swoole framework是基於swoole extension設計的一個框架，要用好這個框架，還是要先了解swoole extension。
擴展的英文名稱是Extension，php擴展是用C語言作為開發語言，基於Zend引擎提供的API，編譯成的一個動態庫。
如果曾經做過類似動態庫調用開發的童鞋可能會更好理解一些，例如Android中的NDK開發在php的配置文件中配置好extension的屬性後，就可以引用這個動態庫了。
也就是說，swoole本身是用C語言編寫的，它可以讓php獲得一些額外的function。
然後是運行方式，swoole的許多功能都只能運行在cli模式下，而cli模式往往是很多剛接觸swoole的phper遇到的第一個問題。
有時候其實只是需要轉變一下思路
我們現在整理一下最常見的php代碼執行方式：
安裝apache、php
配置apache對那個目錄進行php解析
用瀏覽器訪問那個目錄的php文件
更多的細節這里就不提了，畢竟我相信每個phper對這個都是很熟悉的。
但這里就開始出現了第一個問題，我們知道，php是一個腳本語言，腳本語言的核心特點在於不用編譯，隨時執行，而執行腳本的工具就是解析器，而php的解析器就是zend引擎。
嚴格來說，zend並不是唯一的選擇，不過，zend是最官方的。另外，Zend Studio和Zend Engine不是同一個東西，本文中的Zend全部指Zend Engine。
換個角度講，只要有解析器，寫好的php腳本就是可以執行的，而zend引擎與apache之間並沒有絕對的關系實際上，apahce是調用了zend對php腳本進行執行，然後將執行結果輸出給了瀏覽器所以所謂cli模式（CommandLine，命令行模式），其實就是在命令行下直接調用zend引擎對php腳本進行解析並執行，並獲得程序輸出結果的php腳本執行方式。
其實php也可以作為shell腳本來使用哦，就像bash shell一樣既然問題講清楚了，在一個系統中具體怎麼操作呢？
本文以CentOS 7.5作為系統環境，swoole是針對linux系統開發的，windows下並不適用。學習swoole的一個前題是懂得基本的linux系統使用。
當安裝好php的時候，找到php的安裝目錄，如果是默認安裝的話，可以試試whereis命令# 某種簡單的方法
whereis php
> /usr/local/bin/php;
locate whereis find這些命令都可以試試，目的是找到php然後我們來寫一個最經典的php腳本：
<?php
//vi hello_cli.php
echo 'Hello PHP Cli';
編寫純php腳本時，php標簽不要封口
然後我們在shell里執行它：
/usr/local/bin/php hello_cli.php
> Hello PHP Cli
這段代碼中的第一個php，是一個可執行文件，它接受一個php腳本文件作為輸入參數，並解析執行這個php腳本文件（通過zend）。
沒有錯，第一個cli模式下的php程序就被你執行成功了！
默認情況下，php都會被安裝在了$PATH的目錄下，那就可以直接省略路徑前綴了，下文中調用php的時候，全都省略了路徑前綴。
因為swoole是pecl的項目，所以使用pecl安裝是最簡單的方法，強烈推薦第一次接觸的童鞋先使用pecl安裝，在熟悉了swoole之後，再考慮使用編譯安裝的方式以獲取更多進階功能。
pecl這個工具基本都會被安裝在與php相同的目錄下（往往也都是$PATH目錄）pecl install swoole
執行以下命令查看是否安裝成功：
php -m | grep swoole
> swoole
如果正確的輸出了swoole，那麼恭喜你，這次安裝很成功另一個常見的比較麻煩的問題是，有些童鞋的電腦里安裝了多個php，而安裝的時候沒有正確的安裝到預期的php的擴展目錄中，就會導致無法正常工作，解決方案就是弄清楚各個php安裝目錄及配置關系，選擇正確的目錄進行安裝。
其實本文還沒正式開始介紹swoole，都是在學習swoole之前的准備工作，swoole的上手門檻比一般的php應用要高的多，如果沒有網路開發和操作系統方面的一些知識，學習它並不是一件容易的事情，學習曲線很陡峭。
這句話我在群里說了無數次
很多新手會詬病swoole的手冊寫的太模糊，其實是前置知識不足，而手冊也給出了需要的前置知識列表，以下引用至官網的手冊-學習swoole需要哪些知識？
多進程/多線程
了解Linux操作系統進程和線程的概念
了解Linux進程/線程切換調度的基本知識
了解進程間通信的基本知識，如管道、UnixSocket、消息隊列、共享內存socket
了解SOCKET的基本操作如accept/connect、send/recv、close、listen、bind了解SOCKET的接收緩存區、發送緩存區、阻塞/非阻塞、超時等概念IO復用
了解select/poll/epoll
了解基於select/epoll實現的事件循環，Reactor模型了解可讀事件、可寫事件
TCP/IP網路協議
了解TCP/IP協議
了解TCP、UDP傳輸協議
調試工具
使用gdb調試Linux程序
使用strace跟蹤進程的系統調用
使用tcpmp跟蹤網路通信過程
其他Linux系統工具，如ps、lsof、top、vmstat、netstat、sar、ss等學習並理解一個新事務並不是一個容易的事情，特別對於swoole這種具備一定顛覆性的工具，要有耐心和實踐。
淡定的把手冊看完，遇到不理解的名詞學會使用搜索引擎學習，swoole的手冊其實是個大寶庫，網路開發常見的問題其實里邊都涉及到了。
② 幾種常見的PHP超時處理方法
【Web伺服器超時處理】
[ Apache ]
一般在性能很高的情況下，預設所有超時配置都是30秒，但是在上傳文件，或者網路速度很慢的情況下，那麼可能觸發超時操作。
目前apachefastcgiphp-fpm模式下有三個超時設置：
fastcgi超時設置：
修改的fastcgi連接配置，類似如下：
復制代碼 代碼如下:
<IfMolemod_fastcgi.c>
FastCgiExternalServer/home/forum/apache/apache_php/cgi-bin/php-cgi-socket/home/forum/php5/etc/php-fpm.sock
ScriptAlias/fcgi-bin/"/home/forum/apache/apache_php/cgi-bin/"
AddHandlerphp-fastcgi.php
Actionphp-fastcgi/fcgi-bin/php-cgi
AddTypeapplication/x-
</IfMole>
預設配置是30s，如果需要定製自己的配置，需要修改配置，比如修改為100秒：(修改後重啟apache)：
復制代碼 代碼如下:
<IfMolemod_fastcgi.c>
FastCgiExternalServer/home/forum/apache/apache_php/cgi-bin/php-cgi-socket/home/forum/php5/etc/php-fpm.sock-idle-timeout100
ScriptAlias/fcgi-bin/"/home/forum/apache/apache_php/cgi-bin/"
AddHandlerphp-fastcgi.php
Actionphp-fastcgi/fcgi-bin/php-cgi
AddTypeapplication/x-
</IfMole>
如果超時會返回500錯誤，斷開跟後端php服務的連接，同時記錄一條apache錯誤日誌：
[ThuJan2718:30:152011][error][client10.81.41.110]FastCGI:commwithserver"/home/forum/apache/apache_php/cgi-bin/php-cgi"aborted:idletimeout(30sec)
[ThuJan2718:30:152011][error][client10.81.41.110]FastCGI:incompleteheaders(0bytes)receivedfromserver"/home/forum/apache/apache_php/cgi-bin/php-cgi"
其他fastcgi配置參數說明：
復制代碼 代碼如下:
IdleTimeout發呆時限
ProcessLifeTime一個進程的最長生命周期，過期之後無條件kill
MaxProcessCount最大進程個數
DefaultMinClassProcessCount每個程序啟動的最小進程個數
DefaultMaxClassProcessCount每個程序啟動的最大進程個數
IPCConnectTimeout程序響應超時時間
IPCCommTimeout與程序通訊的最長時間，上面的錯誤有可能就是這個值設置過小造成的
MaxRequestsPerProcess每個進程最多完成處理個數，達成後自殺
[ Lighttpd ]
配置：lig
Lighttpd配置中，關於超時的參數有如下幾個（篇幅考慮，只寫讀超時，寫超時參數同理）：
主要涉及選項：
server.max-keep-alive-idle=5
server.max-read-idle=60
server.read-timeout=0
server.max-connection-idle=360
復制代碼 代碼如下:
#每次keep-alive的最大請求數,默認值是16
server.max-keep-alive-requests=100
#keep-alive的最長等待時間,單位是秒，默認值是5
server.max-keep-alive-idle=1200
#lighttpd的work子進程數，默認值是0，單進程運行
server.max-worker=2
#限制用戶在發送請求的過程中，最大的中間停頓時間(單位是秒)，
#如果用戶在發送請求的過程中(沒發完請求)，中間停頓的時間太長，lighttpd會主動斷開連接
#默認值是60(秒)
server.max-read-idle=1200
#限制用戶在接收應答的過程中，最大的中間停頓時間(單位是秒)，
#如果用戶在接收應答的過程中(沒接完)，中間停頓的時間太長，lighttpd會主動斷開連接
#默認值是360(秒)
server.max-write-idle=12000
#讀客戶端請求的超時限制，單位是秒,配為0表示不作限制
#設置小於max-read-idle時，read-timeout生效
server.read-timeout=0
#寫應答頁面給客戶端的超時限制，單位是秒，配為0表示不作限制
#設置小於max-write-idle時，write-timeout生效
server.write-timeout=0
#請求的處理時間上限，如果用了mod_proxy_core，那就是和後端的交互時間限制,單位是秒
server.max-connection-idle=1200
說明：
對於一個keep-alive連接上的連續請求，發送第一個請求內容的最大間隔由參數max-read-idle決定，從第二個請求起，發送請求內容的最大間隔由參數max-keep-alive-idle決定。請求間的間隔超時也由max-keep-alive-idle決定。發送請求內容的總時間超時由參數read-timeout決定。Lighttpd與後端交互數據的超時由max-connection-idle決定。
延伸閱讀：
[ Nginx ]
配置：nf
復制代碼 代碼如下:
http{
#Fastcgi:(針對後端的fastcgi生效,fastcgi不屬於proxy模式)
fastcgi_connect_timeout5;#連接超時
fastcgi_send_timeout10; #寫超時
fastcgi_read_timeout10;#讀取超時
#Proxy:(針對proxy/upstreams的生效)
proxy_connect_timeout15s;#連接超時
proxy_read_timeout24s;#讀超時
proxy_send_timeout10s; #寫超時
}
說明：
Nginx 的超時設置倒是非常清晰容易理解，上面超時針對不同工作模式，但是因為超時帶來的問題是非常多的。
延伸閱讀：
ml
ml
ml
【PHP本身超時處理】
[ PHP-fpm ]
配置：nf
復制代碼 代碼如下:
<?xmlversion="1.0"?>
<configuration>
//...
.
.
EquivalenttoPHP_FCGI_.fcgi
Usedwithanypm_style.
#php-cgi的進程數量
<valuename="max_children">128</value>
Thetimeout(inseconds)
Shouldbeusedwhen'max_execution_time'
'0s'means'off'
#php-fpm 請求執行超時時間，0s為永不超時，否則設置一個 Ns 為超時的秒數
<valuename="request_terminate_timeout">0s</value>
Thetimeout(inseconds).logfile
'0s'means'off'
<valuename="request_slowlog_timeout">0s</value>
</configuration>
說明：
在php.ini中，有一個參數max_execution_time可以設置PHP腳本的最大執行時間，但是，在php-cgi(php-fpm)中，該參數不會起效。真正能夠控制PHP腳本最大執行時：
<valuename="request_terminate_timeout">0s</value>
就是說如果是使用mod_php5.so的模式運行max_execution_time是會生效的，但是如果是php-fpm模式中運行時不生效的。
延伸閱讀：
[ PHP ]
配置：php.ini
選項：
max_execution_time=30
或者在代碼里設置：
ini_set("max_execution_time",30);
set_time_limit(30);
說明：
對當前會話生效，比如設置0一直不超時，但是如果php的safe_mode打開了，這些設置都會不生效。
效果一樣，但是具體內容需要參考php-fpm部分內容，如果php-fpm中設置了request_terminate_timeout的話，那麼max_execution_time就不生效。
【後端&介面訪問超時】
【HTTP訪問】
一般我們訪問HTTP方式很多，主要是：curl,socket,file_get_contents()等方法。
如果碰到對方伺服器一直沒有響應的時候，我們就悲劇了，很容易把整個伺服器搞死，所以在訪問http的時候也需要考慮超時的問題。
[ CURL 訪問HTTP]
CURL 是我們常用的一種比較靠譜的訪問HTTP協議介面的lib庫，性能高，還有一些並發支持的功能等。
CURL:
curl_setopt($ch,opt)可以設置一些超時的設置，主要包括：
*(重要)CURLOPT_TIMEOUT設置cURL允許執行的最長秒數。
*(重要)CURLOPT_TIMEOUT_MS設置cURL允許執行的最長毫秒數。(在cURL7.16.2中被加入。從PHP5.2.3起可使用。)
CURLOPT_CONNECTTIMEOUT在發起連接前等待的時間，如果設置為0，則無限等待。
CURLOPT_CONNECTTIMEOUT_MS嘗試連接等待的時間，以毫秒為單位。如果設置為0，則無限等待。在cURL7.16.2中被加入。從PHP5.2.3開始可用。
CURLOPT_DNS_CACHE_TIMEOUT設置在內存中保存DNS信息的時間，默認為120秒。
curl普通秒級超時：
$ch=curl_init();
curl_setopt($ch,CURLOPT_URL,$url);
curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch,CURLOPT_TIMEOUT,60);//只需要設置一個秒的數量就可以
curl_setopt($ch,CURLOPT_HTTPHEADER,$headers);
curl_setopt($ch,CURLOPT_USERAGENT,$defined_vars['HTTP_USER_AGENT']);
curl普通秒級超時使用：
curl_setopt($ch,CURLOPT_TIMEOUT,60);
curl如果需要進行毫秒超時，需要增加：
curl_easy_setopt(curl,CURLOPT_NOSIGNAL,1L);
或者是：
curl_setopt($ch,CURLOPT_NOSIGNAL,true);是可以支持毫秒級別超時設置的
curl一個毫秒級超時的例子：
復制代碼 代碼如下:
<?php
if(!isset($_GET['foo'])){
//Client
$ch=curl_init('');
curl_setopt($ch,CURLOPT_RETURNTRANSFER,true);
curl_setopt($ch,CURLOPT_NOSIGNAL,1);//注意，毫秒超時一定要設置這個
curl_setopt($ch,CURLOPT_TIMEOUT_MS,200);//超時毫秒，cURL7.16.2中被加入。從PHP5.2.3起可使用
$data=curl_exec($ch);
$curl_errno=curl_errno($ch);
$curl_error=curl_error($ch);
curl_close($ch);
if($curl_errno>0){
echo"cURLError($curl_errno):$curl_errorn";
}else{
echo"Datareceived:$datan";
}
}else{
//Server
sleep(10);
echo"Done.";
}
?>
其他一些技巧：
1. 按照經驗總結是：cURL版本>=libcurl/7.21.0版本，毫秒級超時是一定生效的，切記。
2. curl_multi的毫秒級超時也有問題。。單次訪問是支持ms級超時的，curl_multi並行調多個會不準
[流處理方式訪問HTTP]
除了curl，我們還經常自己使用fsockopen、或者是file操作函數來進行HTTP協議的處理，所以，我們對這塊的超時處理也是必須的。
一般連接超時可以直接設置，但是流讀取超時需要單獨處理。
自己寫代碼處理:
復制代碼 代碼如下:
$tmCurrent=gettimeofday();
$intUSGone=($tmCurrent['sec']-$tmStart['sec'])*1000000
+($tmCurrent['usec']-$tmStart['usec']);
if($intUSGone>$this->_intReadTimeoutUS){
returnfalse;
}
或者使用內置流處理函數stream_set_timeout()和stream_get_meta_data()處理：
復制代碼 代碼如下:
<?php
//Timeoutinseconds
$timeout=5;
$fp=fsockopen("",80,$errno,$errstr,$timeout);
if($fp){
fwrite($fp,"GET/HTTP/1.0rn");
fwrite($fp,"Host:rn");
fwrite($fp,"Connection:Closernrn");
stream_set_blocking($fp,true);//重要，設置為非阻塞模式
stream_set_timeout($fp,$timeout);//設置超時
$info=stream_get_meta_data($fp);
while((!feof($fp))&&(!$info['timed_out'])){
$data.=fgets($fp,4096);
$info=stream_get_meta_data($fp);
ob_flush;
flush();
}
if($info['timed_out']){
echo"ConnectionTimedOut!";
}else{
echo$data;
}
}
file_get_contents超時：
復制代碼 代碼如下:
<?php
$timeout=array(
'http'=>array(
'timeout'=>5//設置一個超時時間，單位為秒
)
);
$ctx=stream_context_create($timeout);
$text=file_get_contents("",0,$ctx);
?>
fopen超時：
復制代碼 代碼如下:
<?php
$timeout=array(
'http'=>array(
'timeout'=>5//設置一個超時時間，單位為秒
)
);
$ctx=stream_context_create($timeout);
if($fp=fopen("","r",false,$ctx)){
while($c=fread($fp,8192)){
echo$c;
}
fclose($fp);
}
?>
【MySQL】
php中的mysql客戶端都沒有設置超時的選項，mysqli和mysql都沒有，但是libmysql是提供超時選項的，只是我們在php中隱藏了而已。
那麼如何在PHP中使用這個操作捏，就需要我們自己定義一些MySQL操作常量，主要涉及的常量有：
MYSQL_OPT_READ_TIMEOUT=11;
MYSQL_OPT_WRITE_TIMEOUT=12;
這兩個，定義以後，可以使用options設置相應的值。
不過有個注意點，mysql內部實現：
1.超時設置單位為秒，最少配置1秒
2.但mysql底層的read會重試兩次，所以實際會是3秒
重試兩次+自身一次=3倍超時時間，那麼就是說最少超時時間是3秒，不會低於這個值，對於大部分應用來說可以接受，但是對於小部分應用需要優化。
查看一個設置訪問mysql超時的php實例：
復制代碼 代碼如下:
<?php
//自己定義讀寫超時常量
if(!defined('MYSQL_OPT_READ_TIMEOUT')){
define('MYSQL_OPT_READ_TIMEOUT',11);
}
if(!defined('MYSQL_OPT_WRITE_TIMEOUT')){
define('MYSQL_OPT_WRITE_TIMEOUT',12);
}
//設置超時
$mysqli=mysqli_init();
$mysqli->options(MYSQL_OPT_READ_TIMEOUT,3);
$mysqli->options(MYSQL_OPT_WRITE_TIMEOUT,1);
//連接資料庫
$mysqli->real_connect("localhost","root","root","test");
if(mysqli_connect_errno()){
printf("Connectfailed:%s/n",mysqli_connect_error());
exit();
}
//執行查詢sleep1秒不超時
printf("Hostinformation:%s/n",$mysqli->host_info);
if(!($res=$mysqli->query('selectsleep(1)'))){
echo"query1error:".$mysqli->error."/n";
}else{
echo"Query1:querysuccess/n";
}
//執行查詢sleep9秒會超時
if(!($res=$mysqli->query('selectsleep(9)'))){
echo"query2error:".$mysqli->error."/n";
}else{
echo"Query2:querysuccess/n";
}
$mysqli->close();
echo"closemysqlconnection/n";
?>
延伸閱讀：
【Memcached】
[PHP擴展]
php_memcache客戶端：
連接超時：boolMemcache::connect(string$host[,int$port[,int$timeout]])
在get和set的時候，都沒有明確的超時設置參數。
libmemcached客戶端：在php介面沒有明顯的超時參數。
說明：所以說，在PHP中訪問Memcached是存在很多問題的，需要自己hack部分操作，或者是參考網上補丁。
[C&C++訪問Memcached]
客戶端：libmemcached客戶端
說明：memcache超時配置可以配置小點，比如5，10個毫秒已經夠用了，超過這個時間還不如從資料庫查詢。
下面是一個連接和讀取set數據的超時的C++示例：
復制代碼 代碼如下:
//創建連接超時（連接到Memcached）
memcached_st*MemCacheProxy::_create_handle()
{
memcached_st*mmc=NULL;
memcached_return_tprc;
if(_mpool!=NULL){//getfrompool
mmc=memcached_pool_pop(_mpool,false,&prc);
if(mmc==NULL){
__LOG_WARNING__("MemCacheProxy","gethandlefrompoolerror[%d]",(int)prc);
}
returnmmc;
}
memcached_st*handle=memcached_create(NULL);
if(handle==NULL){
__LOG_WARNING__("MemCacheProxy","create_handleerror");
returnNULL;
}
//設置連接/讀取超時
memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_HASH,MEMCACHED_HASH_DEFAULT);
memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_NO_BLOCK,_noblock);//參數MEMCACHED_BEHAVIOR_NO_BLOCK為1使超時配置生效，不設置超時會不生效，關鍵時候會悲劇的，容易引起雪崩
memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_CONNECT_TIMEOUT,_connect_timeout);//連接超時
memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_RCV_TIMEOUT,_read_timeout);//讀超時
memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_SND_TIMEOUT,_send_timeout);//寫超時
memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_POLL_TIMEOUT,_poll_timeout);
//設置一致hash
//memcached_behavior_set_distribution(handle,MEMCACHED_DISTRIBUTION_CONSISTENT);
memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_DISTRIBUTION,MEMCACHED_DISTRIBUTION_CONSISTENT);
memcached_returnrc;
for(uinti=0;i<_server_count;i++){
rc=memcached_server_add(handle,_ips[i],_ports[i]);
if(MEMCACHED_SUCCESS!=rc){
__LOG_WARNING__("MemCacheProxy","addserver[%s:%d]failed.",_ips[i],_ports[i]);
}
}
_mpool=memcached_pool_create(handle,_min_connect,_max_connect);
if(_mpool==NULL){
__LOG_WARNING__("MemCacheProxy","create_poolerror");
returnNULL;
}
mmc=memcached_pool_pop(_mpool,false,&prc);
if(mmc==NULL){
__LOG_WARNING__("MyMemCacheProxy","gethandlefrompoolerror[%d]",(int)prc);
}
//__LOG_DEBUG__("MemCacheProxy","gethandle[%p]",handle);
returnmmc;
}
//設置一個key超時（set一個數據到memcached）
boolMemCacheProxy::_add(memcached_st*handle,unsignedint*key,constchar*value,intlen,unsignedinttimeout)
{
memcached_returnrc;
chartmp[1024];
snprintf(tmp,sizeof(tmp),"%u#%u",key[0],key[1]);
//有個timeout值
rc=memcached_set(handle,tmp,strlen(tmp),(char*)value,len,timeout,0);
if(MEMCACHED_SUCCESS!=rc){
returnfalse;
}
returntrue;
}
//Memcache讀取數據超時(沒有設置)
libmemcahed源碼中介面定義：
LIBMEMCACHED_APIchar*memcached_get(memcached_st*ptr,constchar*key,size_tkey_length,size_t*value_length,uint32_t*flags,memcached_return_t*error);
LIBMEMCACHED_APImemcached_return_tmemcached_mget(memcached_st*ptr,constchar*const*keys,constsize_t*key_length,size_tnumber_of_keys);
從介面中可以看出在讀取數據的時候，是沒有超時設置的。
延伸閱讀：
【如何實現超時】
程序中需要有超時這種功能，比如你單獨訪問一個後端Socket模塊，Socket模塊不屬於我們上面描述的任何一種的時候，它的協議也是私有的，那麼這個時候可能需要自己去實現一些超時處理策略，這個時候就需要一些處理代碼了。
[PHP中超時實現]
一、初級：最簡單的超時實現 （秒級超時）
思路很簡單：鏈接一個後端，然後設置為非阻塞模式，如果沒有連接上就一直循環，判斷當前時間和超時時間之間的差異。
phpsocket中實現原始的超時：(每次循環都當前時間去減，性能會很差，cpu佔用會較高)
復制代碼 代碼如下:
<?
$host="127.0.0.1";
$port="80";
$timeout=15;//timeoutinseconds
$socket=socket_create(AF_INET,SOCK_STREAM,SOL_TCP)
ordie("Unabletocreatesocketn");
socket_set_nonblock($socket) //務必設置為阻塞模式
ordie("Unabletosetnonblockonsocketn");
$time=time();
//循環的時候每次都減去相應值
while(!@socket_connect($socket,$host,$port))//如果沒有連接上就一直死循環
{
$err=socket_last_error($socket);
if($err==115||$err==114)
{
if((time()-$time)>=$timeout)//每次都需要去判斷一下是否超時了
{
socket_close($socket);
die("Connectiontimedout.n");
}
sleep(1);
continue;
}
die(socket_strerror($err)."n");
}
socket_set_block($this->socket)//還原阻塞模式
ordie("Unabletosetblockonsocketn");
?>
二、升級：使用PHP自帶非同步IO去實現（毫秒級超時）
說明：
非同步IO：非同步IO的概念和同步IO相對。當一個非同步過程調用發出後，調用者不能立刻得到結果。實際處理這個調用的部件在完成後，通過狀態、通知和回調來通知調用者。非同步IO將比特分成小組進行傳送，小組可以是8位的1個字元或更長。發送方可以在任何時刻發送這些比特組，而接收方從不知道它們會在什麼時候到達。
多路復用：復用模型是對多個IO操作進行檢測，返回可操作集合，這樣就可以對其進行操作了。這樣就避免了阻塞IO不能隨時處理各個IO和非阻塞佔用系統資源的確定。
使用socket_select()實現超時
socket_select(...,floor($timeout),ceil($timeout*1000000));
select的特點：能夠設置到微秒級別的超時！
使用socket_select()的超時代碼（需要了解一些非同步IO編程的知識去理解）
復制代碼 代碼如下:
編程 調用類 編程#
<?php
$server=newServer;
$client=newClient;
for(;;){
foreach($select->can_read(0)as$socket){
if($socket==$client->socket){
//NewClientSocket
$select->add(socket_accept($client->socket));
}
else{
//there'ssomethingtoreadon$socket
}
}
}
?>
編程 非同步多路復用IO & 超時連接處理類 編程
<?php
classselect{
var$sockets;
functionselect($sockets){
$this->sockets=array();
foreach($socketsas$socket){
$this->add($socket);
}
}
functionadd($add_socket){
array_push($this->sockets,$add_socket);
}
functionremove($remove_socket){
$sockets=array();
foreach($this->socketsas$socket){
if($remove_socket!=$socket)
$sockets[]=$socket;
}
$this->sockets=$sockets;
}
functioncan_read($timeout){
$read=$this->sockets;
socket_select($read,$write=NULL,$except=NULL,$timeout);
return$read;
}
functioncan_write($timeout){
$write=$this->sockets;
socket_select($read=NULL,$write,$except=NULL,$timeout);
return$write;
}
}
?>
[C&C++中超時實現]
一般在LinuxC/C++中，可以使用：alarm()設置定時器的方式實現秒級超時，或者：select()、poll()、epoll()之類的非同步復用IO實現毫秒級超時。也可以使用二次封裝的非同步io庫（libevent,libev）也能實現。
一、使用alarm中用信號實現超時 （秒級超時）
說明：Linux內核connect超時通常為75秒，我們可以設置更小的時間如10秒來提前從connect中返回。這里用使用信號處理機制，調用alarm，超時後產生SIGALRM信號（也可使用select實現）
用alarym秒級實現connect設置超時代碼示例：
復制代碼 代碼如下:
//信號處理函數
staticvoidconnect_alarm(intsigno)
{
debug_printf("SignalHandler");
return;
}
//alarm超時連接實現
staticvoidconn_alarm()
{
Sigfunc*sigfunc;//現有信號處理函數
sigfunc=signal(SIGALRM,connect_alarm);//建立信號處理函數connect_alarm,(如果有)保存現有的信號處理函數
inttimeout=5;
//設置鬧鍾
if(alarm(timeout)!=0){
//...鬧鍾已經設置處理
}
//進行連接操作
if(connect(m_Socket,(structsockaddr*)&addr,sizeof(addr))<0){
if(errno==EINTR){//如果錯誤號設置為EINTR，說明超時中斷了
debug_printf("Timeout");
③ php socket 怎麼實現非阻塞讀取數據
使用 socket_set_nonblock 可以將 socket 設置成非阻塞模式，不過PHP不是並發處理的，並沒有一種很好的方式來實現非阻塞讀取，實際上並沒有多大意義。非阻塞寫入使用的意義更大一些。
④ php部署到新浪雲sae不能正常運行了,求解
sae文檔
運行環境
基本環境
新浪雲 PHP 運行環境目前的 Web 伺服器使用的是：
CentOS-6.x
Apache-2.2.x
PHP-5.3.x / PHP-5.6.x
Web 伺服器運行在 64 位 Linux 環境下。
Apache 運行在 Prefork 模式下，即每個請求都會對應一個 Apache 進程，請求結束後該進程才能服務於下一個請求。平台通過模塊方式擴展了 Apache 和 PHP 的相關功能。
禁用函數和類
出於平台安全性考慮，我們禁用了以下函數和類，禁用的標准主要有四點：
出於對安全性的考慮
出於對資源管理的考慮
不常用的 API
我們提供更好替代方案的 API
禁用的函數：
symlink
link
exec
system
escapeshellcmd
escapeshellarg
passthru
shell_exec
proc_open
proc_close
proc_terminate
proc_get_status
proc_nice
dl
pclose
popen
stream_socket_server
stream_socket_accept
stream_socket_pair
stream_wrapper_restore
mb_send_mail
posix_kill
apache_child_terminate
apache_lookup_uri
apache_reset_timeout
apache_setenv
virtual
socket_create
socket_create_pair
realpath_cache_get
禁用的類：
SQLiteDatabase
SQLiteResult
SQLiteUnbuffered
SQLiteException
沙箱
代碼和數據的隔離：每個應用在運行期間，只能「看」到自己的代碼和數據，即 A 應用無法訪問 B 應用的代碼和數據。注意，這里提到的在 Web 伺服器上的數據，往往指一些中間處理過程的臨時數據，並非最終落地的數據，比如用戶上傳照片會臨時存儲到 TmpFS。
連接數的隔離：我們知道，程序寫的不好，很容易導致阻塞，並進一步導致連接數的飆升。單個應用過多佔用 Apache 連接數，原因往往是多方面的，應用請求外部資源被阻塞是一個最為常見的因素，另外應用頁面過大瀏覽器下載慢也是常見因素之一。公有雲平台同一時刻往往運行著大量的應用，如果某一應用出現連接數異常，最直接的後果是整個平台上的所有應用都將陷入癱瘓。新浪雲平台目前有設置「應用最大 HTTP 並發連接數」，目前這個值是 500，如果應用平均單個請求處理時長是 100ms，那麼該應用每秒的 HTTP 並發連接將可以到達 5000，每天的請求超過 1 億沒有問題。但如果您的應用平均每個請求處理時長 2 秒，那麼該應用每秒的 HTTP 並發連接只能到達 250，每天支撐的請求數將在千萬。總體而言，盡量迅速處理完請求對應用是有利的，而且也是平台所鼓勵的。
內存隔離：目前新浪雲平台上對單個 PHP 腳本的處理，設置了 128MB 的上限 (max_memory，ini_set 不可修改），我們認為這個設置是一個相對很高的值，可以說能夠滿足絕大部分應用的需求。設想一台伺服器 8G 內存，如果每個 PHP 處理都消耗 64M 內存，那麼該伺服器最多隻能同時運行 128 個 PHP 腳本。新浪雲引入了」應用最大並發內存數「的概念，目前的設置是 4GB。如果應用程序單個請求的內存消耗平均在 16MB，那麼可同時運行 256 個請求，這和上面的並發連接數的設定是基本一致的。
CPU 隔離：這主要是通過新浪雲的配額系統來達到 CPU 時間的隔離。每個應用都有 CPU 時間消耗的分鍾速度限制，避免了某一應用過多非法獲取 CPU 資源導致其它應用響應慢的問題。
目前新浪雲平台上允許的「單請求最大存活時長」是 300 秒 。
註解
當應用並發超過限制，系統會返回 508 錯誤，並顯示 Connections out of quota。當應用內存佔用超過限制，系統會返回 509 錯誤，並顯示 Memory usage out of quota。
環境變數
您可以通過列印 PHP 的全局變數$_SERVER來獲取跟新浪雲相關的環境變數信息，每個環境變數的信息如下：
變數名
說明
HTTP_APPNAME 標志該請求屬於哪個應用
HTTP_APPVERSION 標志該請求對應該應用的哪個版本
HTTP_ACCESSKEY 該應用訪問各種服務資源的帳號
HTTP_SECRETKEY 該應用訪問各種服務資源的密碼
HTTP_APPCOOKIE 一些和 app 管理相關信息
警告
不要直接列印出$_SERVER變數，這樣可能會造成應用的 AccessKey 和 SecretKey 的泄露。為了應用的安全考慮，請保護好自己的 AccessKey 和 SecretKey。
常用字體文件路徑：
constantSAE_Font_Sun
宋體字體文件路徑
constantSAE_Font_Kai
楷體字體文件路徑
constantSAE_Font_Hei
文泉驛正黑字體文件路徑
constantSAE_Font_MicroHei
文泉驛微米黑字體文件路徑
全局函數
is_https()
判斷客戶端是以 http 還是以 https 的方式連接。
返回:
如果是 https 連接返回 true，否則返回 false。⑤ PHP中的（偽）多線程與多進程
利用WEB伺服器本身的多線程來處理，從WEB伺服器多次調用我們需要實現多線程的程序。
PHP中也能多線程了，那麼問題也來了，那就是同步的問題。回龍觀電腦培訓知道PHP本身是不支持多線程的，所以更不會有什麼像java中亂改茄synchronize的方法了。那我們該如何做呢？
1.盡量不訪問同一個資源。以避免沖突。但是可以同時像資料庫操作。因為數據殲敗庫是支持並發操作的。所以在多線程的PHP中不要向同一個文件中寫入數據。如果必須要寫的話，用別的方法進行同步。如調用flock對文件進行加鎖等。或建立臨時文件，並在另外的線程中等待這個文件的消失while(file_exits('xxx'));這樣就等於這個臨時文件存在時，表示其實線程正在操作。如果沒有了這個文件，說明其它線程已經釋放了這個。
2.盡量不要從runThread在執行fputs後取這個socket中讀取數據。因為要實現嘩察多線程，需要的用非阻塞模式。即在像fgets這樣的函數時立即返回。。所以讀寫數據就會出問題。如果使用阻塞模式的話，程序就不算是多線程了。他要等上面的返回才執行下面的程序。所以如果需要交換數據最後利用外面文件或數據中完成。實在想要的話就用socket_set_nonblock($fp)來實現。
說了這么多，倒底這個有沒有實際的意義呢？在什麼時候需要這種用這種方法呢？
答案是肯定的。大家知道。在一個不斷讀取網路資源的應用中，網路的速度是瓶頸。如果采多這種形式就可以同時以多個線程對不同的頁面進行讀取。
⑥ php-fpm的工作機制
概括來說，fpm 的實現就是創建一個 master 進程，在 master 進程中創建並監聽 socket，然後 fork 出多個子進程，這些子進程各自 accept 請求，子進程的處理非常簡單，它在啟動後阻塞在 accept 上，有請求到達後開始讀取請求數據，讀取完成後開始處理然後再返回，在這期間是不會接收其它請求的，也就是說 fpm 的子進程同時只能響應一個請求，只有把這個請求處理完成後才會 accept 下一個請求，這一點與 nginx 的事件驅動有很大的區別，nginx 的子進程通過 epoll 管理套接字，如果一個請求數據還未發送完成則會處理下一個請求，即一個進程會同時連接多個請求，它是非阻塞的模型，只處理活躍的套接字。
fpm 的 master 進程與 worker 進程之間不會直接進行通信，master 通過共享內存獲取 worker 進程的信息，比如 worker 進程當前狀態、已處理請求數等，當 master 進程要殺掉一個 worker 進程時則通過發送信號的方式通知 worker 進程。
fpm 可以同時監聽多個埠，每個埠對應一個 worker pool，而每個 pool 下對應多個 worker 進程，類似 nginx 中 server 概念。
在 php-fpm.conf 中通過[pool name]聲明一個 worker pool：
啟動 fpm 後查看進程：
具體實現上 worker pool 通過fpm_worker_pool_s這個結構表示，多個 worker pool 組成一個單鏈表
接下來看下 fpm 的啟動流程，從main()函數開始：
fpm_init()主要有以下幾個關鍵操作：
(1) fpm_conf_init_main():
解析 php-fpm.conf 配置文件，分配 worker pool 內存結構並保存到全局變數中：fpm_worker_all_pools，各 worker pool 配置解析到fpm_worker_pool_s->config中。
(2)fpm_scoreboard_init_main():
分配用於記錄 worker 進程運行信息的共享內存，按照 worker pool 的最大 worker 進程數分配，每個 worker pool 分配一個fpm_scoreboard_s結構，pool 下對應的每個 worker 進程分配一個fpm_scoreboard_proc_s結構。
(3)fpm_signals_init_main():
這里會通過socketpair()創建一個管道，這個管道並不是用於 master 與 worker 進程通信的，它只在 master 進程中使用，具體用途在稍後介紹 event 事件處理時再作說明。另外設置 master 的信號處理 handler，當 master 收到 SIGTERM、SIGINT、SIGUSR1、SIGUSR2、SIGCHLD、SIGQUIT 這些信號時將調用sig_handler()處理：
(4)fpm_sockets_init_main()
創建每個 worker pool 的 socket 套接字。
(5)fpm_event_init_main():
啟動 master 的事件管理，fpm 實現了一個事件管理器用於管理 IO、定時事件，其中 IO 事件通過 kqueue、epoll、poll、select 等管理，定時事件就是定時器，一定時間後觸發某個事件。
在fpm_init()初始化完成後接下來就是最關鍵的fpm_run()操作了，此環節將 fork 子進程，啟動進程管理器，另外 master 進程將不會再返回，只有各 worker 進程會返回，也就是說fpm_run()之後的操作均是 worker 進程的。
在 fork 後 worker 進程返回了監聽的套接字繼續 main() 後面的處理，而 master 將永遠阻塞在fpm_event_loop()，接下來分別介紹 master、worker 進程的後續操作。
fpm_run()執行後將 fork 出 worker 進程，worker 進程返回main()中繼續向下執行，後面的流程就是 worker 進程不斷 accept 請求，然後執行 PHP 腳本並返回。整體流程如下：
worker 進程一次請求的處理被劃分為 5 個階段：
worker 處理到各個階段時將會把當前階段更新到fpm_scoreboard_proc_s->request_stage，master 進程正是通過這個標識判斷 worker 進程是否空閑的。
接下來我們來看下 master 是如何管理 worker 進程的，首先介紹下三種不同的進程管理方式：
前面介紹到在fpm_run()中 master 進程將進入fpm_event_loop()：
這就是 master 整體的處理，其進程管理主要依賴注冊的幾個事件，接下來我們詳細分析下這幾個事件的功能。
(1)sp[1]管道可讀事件：
在 fpm_init() 階段 master 曾創建了一個全雙工的管道：sp，然後在這里創建了一個 sp[0] 可讀的事件，當 sp[0] 可讀時將交由 fpm_got_signal() 處理，向 sp[1] 寫數據時 sp[0] 才會可讀，那麼什麼時機會向 sp[1] 寫數據呢？前面已經提到了：當 master 收到注冊的那幾種信號時會寫入 sp[1] 端，這個時候將觸發 sp[0] 可讀事件。
這個事件是 master 用於處理信號的，我們根據 master 注冊的信號逐個看下不同用途：
具體處理邏輯在 fpm_got_signal() 函數中，這里不再羅列。
(2)fpm_pctl_perform_idle_server_maintenance_heartbeat():
這是進程管理實現的主要事件，master 啟動了一個定時器，每隔 1s 觸發一次，主要用於 dynamic、ondemand 模式下的 worker 管理，master 會定時檢查各 worker pool 的 worker 進程數，通過此定時器實現 worker 數量的控制，處理邏輯如下：
(3)fpm_pctl_heartbeat():
這個事件是用於限制 worker 處理單個請求最大耗時的，php-fpm.conf 中有一個request_terminate_timeout的配置項，如果 worker 處理一個請求的總時長超過了這個值那麼 master 將會向此 worker 進程發送kill -TERM信號殺掉 worker 進程，此配置單位為秒，默認值為 0 表示關閉此機制，另外 fpm 列印的 slow log 也是在這里完成的。
除了上面這幾個事件外還有一個沒有提到，那就是 ondemand 模式下 master 監聽的新請求到達的事件，因為 ondemand 模式下 fpm 啟動時是不會預創建 worker 的，有請求時才會生成子進程，所以請求到達時需要通知 master 進程，這個事件是在fpm_children_create_initial()時注冊的，事件處理函數為fpm_pctl_on_socket_accept()，具體邏輯這里不再展開，比較容易理解。
原文出處： https://www.fanhao.com/2017/10/internal-php-fpm.html
⑦ 大型的 PHP應用 通常使用什麼應用做 消息隊列 的
一、消息隊列概述
消息隊列中間件是分布式系統中重要的組件，主要解決應用耦合，非同步消息，流量削鋒等問題。實現高性能，高可用，可伸縮和最終一致性架構。是大型分布式系統不可缺少的中間件。
目前在生產環境，使用較多的消息隊列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。
二、消息隊列應用場景
以下介紹消息隊列在實際應用中常用的使用場景。非同步處理，應用解耦，流量削鋒和消息通訊四個場景。
2.1非同步處理
場景說明：用戶注冊後，需要發注冊郵件和注冊簡訊。傳統的做法有兩種1.串列的方式；2.並行方式。
（1）串列方式：將注冊信息寫入資料庫成功後，發送注冊郵件，再發送注冊簡訊。以上三個任務全部完成後，返回給客戶端。（架構KKQ：466097527，歡迎加入）
（2）並行方式：將注冊信息寫入資料庫成功後，發送注冊郵件的同時，發送注冊簡訊。以上三個任務完成後，返回給客戶端。與串列的差別是，並行的方式可以提高處理的時間。
假設三個業務節點每個使用50毫秒鍾，不考慮網路等其他開銷，則串列方式的時間是150毫秒，並行的時間可能是100毫秒。
因為CPU在單位時間內處理的請求數是一定的，假設CPU1秒內吞吐量是100次。則串列方式1秒內CPU可處理的請求量是7次（1000/150）。並行方式處理的請求量是10次（1000/100）。
小結：如以上案例描述，傳統的方式系統的性能（並發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？
引入消息隊列，將不是必須的業務邏輯，非同步處理。改造後的架構如下：
按照以上約定，用戶的響應時間相當於是注冊信息寫入資料庫的時間，也就是50毫秒。注冊郵件，發送簡訊寫入消息隊列後，直接返回，因此寫入消息隊列的速度很快，基本可以忽略，因此用戶的響應時間可能是50毫秒。因此架構改變後，系統的吞吐量提高到每秒20 QPS。比串列提高了3倍，比並行提高了兩倍。
2.2應用解耦
場景說明：用戶下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用庫存系統的介面。如下圖：
傳統模式的缺點：
1） 假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗；
2） 訂單系統與庫存系統耦合；
如何解決以上問題呢？引入應用消息隊列後的方案，如下圖：
訂單系統：用戶下單後，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功。
庫存系統：訂閱下單的消息，採用拉/推的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操作。
假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單後，訂單系統寫入消息隊列就不再關心其他的後續操作了。實現訂單系統與庫存系統的應用解耦。
2.3流量削鋒
流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。
應用場景：秒殺活動，一般會因為流量過大，導致流量暴增，應用掛掉。為解決這個問題，一般需要在應用前端加入消息隊列。
可以控制活動的人數；
可以緩解短時間內高流量壓垮應用；
用戶的請求，伺服器接收後，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面；
秒殺業務根據消息隊列中的請求信息，再做後續處理。
2.4日誌處理
日誌處理是指將消息隊列用在日誌處理中，比如Kafka的應用，解決大量日誌傳輸的問題。架構簡化如下：
日誌採集客戶端，負責日誌數據採集，定時寫受寫入Kafka隊列；
Kafka消息隊列，負責日誌數據的接收，存儲和轉發；
日誌處理應用：訂閱並消費kafka隊列中的日誌數據；
以下是新浪kafka日誌處理應用案例：
(1)Kafka：接收用戶日誌的消息隊列。
(2)Logstash：做日誌解析，統一成JSON輸出給Elasticsearch。
(3)Elasticsearch：實時日誌分析服務的核心技術，一個schemaless，實時的數據存儲服務，通過index組織數據，兼具強大的搜索和統計功能。
(4)Kibana：基於Elasticsearch的數據可視化組件，超強的數據可視化能力是眾多公司選擇ELK stack的重要原因。
2.5消息通訊
消息通訊是指，消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。比如實現點對點消息隊列，或者聊天室等。
點對點通訊：
客戶端A和客戶端B使用同一隊列，進行消息通訊。
聊天室通訊：
客戶端A，客戶端B，客戶端N訂閱同一主題，進行消息發布和接收。實現類似聊天室效果。
以上實際是消息隊列的兩種消息模式，點對點或發布訂閱模式。模型為示意圖，供參考。
三、消息中間件示例
3.1電商系統
消息隊列採用高可用，可持久化的消息中間件。比如Active MQ，Rabbit MQ，Rocket Mq。（1）應用將主幹邏輯處理完成後，寫入消息隊列。消息發送是否成功可以開啟消息的確認模式。（消息隊列返回消息接收成功狀態後，應用再返回，這樣保障消息的完整性）
（2）擴展流程（發簡訊，配送處理）訂閱隊列消息。採用推或拉的方式獲取消息並處理。
（3）消息將應用解耦的同時，帶來了數據一致性問題，可以採用最終一致性方式解決。比如主數據寫入資料庫，擴展應用根據消息隊列，並結合資料庫方式實現基於消息隊列的後續處理。
3.2日誌收集系統
分為Zookeeper注冊中心，日誌收集客戶端，Kafka集群和Storm集群（OtherApp）四部分組成。
Zookeeper注冊中心，提出負載均衡和地址查找服務；
日誌收集客戶端，用於採集應用系統的日誌，並將數據推送到kafka隊列；
四、JMS消息服務
講消息隊列就不得不提JMS 。JMS（Java Message Service,Java消息服務）API是一個消息服務的標准/規范，允許應用程序組件基於JavaEE平台創建、發送、接收和讀取消息。它使分布式通信耦合度更低，消息服務更加可靠以及非同步性。
在EJB架構中，有消息bean可以無縫的與JM消息服務集成。在J2EE架構模式中，有消息服務者模式，用於實現消息與應用直接的解耦。
4.1消息模型
在JMS標准中，有兩種消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。
4.1.1 P2P模式
P2P模式包含三個角色：消息隊列（Queue），發送者(Sender)，接收者(Receiver)。每個消息都被發送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留著消息，直到他們被消費或超時。
P2P的特點
每個消息只有一個消費者（Consumer）(即一旦被消費，消息就不再在消息隊列中)
發送者和接收者之間在時間上沒有依賴性，也就是說當發送者發送了消息之後，不管接收者有沒有正在運行，它不會影響到消息被發送到隊列
接收者在成功接收消息之後需向隊列應答成功
如果希望發送的每個消息都會被成功處理的話，那麼需要P2P模式。（架構KKQ：466097527，歡迎加入）
4.1.2 Pub/sub模式
包含三個角色主題（Topic），發布者（Publisher），訂閱者（Subscriber） 。多個發布者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。
Pub/Sub的特點
每個消息可以有多個消費者
發布者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之後，才能消費發布者的消息。
為了消費消息，訂閱者必須保持運行的狀態。
為了緩和這樣嚴格的時間相關性，JMS允許訂閱者創建一個可持久化的訂閱。這樣，即使訂閱者沒有被激活（運行），它也能接收到發布者的消息。
如果希望發送的消息可以不被做任何處理、或者只被一個消息者處理、或者可以被多個消費者處理的話，那麼可以採用Pub/Sub模型。
4.2消息消費
在JMS中，消息的產生和消費都是非同步的。對於消費來說，JMS的消息者可以通過兩種方式來消費消息。
（1）同步
訂閱者或接收者通過receive方法來接收消息，receive方法在接收到消息之前（或超時之前）將一直阻塞；
（2）非同步
訂閱者或接收者可以注冊為一個消息監聽器。當消息到達之後，系統自動調用監聽器的onMessage方法。
JNDI：Java命名和目錄介面,是一種標準的Java命名系統介面。可以在網路上查找和訪問服務。通過指定一個資源名稱，該名稱對應於資料庫或命名服務中的一個記錄，同時返回資源連接建立所必須的信息。
JNDI在JMS中起到查找和訪問發送目標或消息來源的作用。（架構KKQ：466097527，歡迎加入）
4.3JMS編程模型
(1) ConnectionFactory
創建Connection對象的工廠，針對兩種不同的jms消息模型，分別有QueueConnectionFactory和TopicConnectionFactory兩種。可以通過JNDI來查找ConnectionFactory對象。
(2) Destination
Destination的意思是消息生產者的消息發送目標或者說消息消費者的消息來源。對於消息生產者來說，它的Destination是某個隊列（Queue）或某個主題（Topic）;對於消息消費者來說，它的Destination也是某個隊列或主題（即消息來源）。
所以，Destination實際上就是兩種類型的對象：Queue、Topic可以通過JNDI來查找Destination。
(3) Connection
Connection表示在客戶端和JMS系統之間建立的鏈接（對TCP/IP socket的包裝）。Connection可以產生一個或多個Session。跟ConnectionFactory一樣，Connection也有兩種類型：QueueConnection和TopicConnection。
(4) Session
Session是操作消息的介面。可以通過session創建生產者、消費者、消息等。Session提供了事務的功能。當需要使用session發送/接收多個消息時，可以將這些發送/接收動作放到一個事務中。同樣，也分QueueSession和TopicSession。
(5) 消息的生產者
消息生產者由Session創建，並用於將消息發送到Destination。同樣，消息生產者分兩種類型：QueueSender和TopicPublisher。可以調用消息生產者的方法（send或publish方法）發送消息。
(6) 消息消費者
消息消費者由Session創建，用於接收被發送到Destination的消息。兩種類型：QueueReceiver和TopicSubscriber。可分別通過session的createReceiver(Queue)或createSubscriber(Topic)來創建。當然，也可以session的creatDurableSubscriber方法來創建持久化的訂閱者。
(7) MessageListener
消息監聽器。如果注冊了消息監聽器，一旦消息到達，將自動調用監聽器的onMessage方法。EJB中的MDB（Message-Driven Bean）就是一種MessageListener。
深入學習JMS對掌握JAVA架構，EJB架構有很好的幫助，消息中間件也是大型分布式系統必須的組件。本次分享主要做全局性介紹，具體的深入需要大家學習，實踐，總結，領會。
五、常用消息隊列
一般商用的容器，比如WebLogic，JBoss，都支持JMS標准，開發上很方便。但免費的比如Tomcat，Jetty等則需要使用第三方的消息中間件。本部分內容介紹常用的消息中間件（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他們的特點。
5.1 ActiveMQ
ActiveMQ 是Apache出品，最流行的，能力強勁的開源消息匯流排。ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規范的 JMS Provider實現，盡管JMS規范出台已經是很久的事情了，但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。
ActiveMQ特性如下：
⒈ 多種語言和協議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應用協議： OpenWire,Stomp REST,WS Notification,XMPP,AMQP
⒉ 完全支持JMS1.1和J2EE 1.4規范 （持久化，XA消息，事務)
⒊ 對spring的支持，ActiveMQ可以很容易內嵌到使用Spring的系統裡面去，而且也支持Spring2.0的特性
⒋ 通過了常見J2EE伺服器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業伺服器上
⒌ 支持多種傳送協議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
⒍ 支持通過JDBC和journal提供高速的消息持久化
⒎ 從設計上保證了高性能的集群，客戶端-伺服器，點對點
⒏ 支持Ajax
⒐ 支持與Axis的整合
⒑ 可以很容易得調用內嵌JMS provider，進行測試
5.2 RabbitMQ
RabbitMQ是流行的開源消息隊列系統，用erlang語言開發。RabbitMQ是AMQP（高級消息隊列協議）的標准實現。支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。
幾個重要概念：
Broker：簡單來說就是消息隊列伺服器實體。
Exchange：消息交換機，它指定消息按什麼規則，路由到哪個隊列。
Queue：消息隊列載體，每個消息都會被投入到一個或多個隊列。
Binding：綁定，它的作用就是把exchange和queue按照路由規則綁定起來。
Routing Key：路由關鍵字，exchange根據這個關鍵字進行消息投遞。
vhost：虛擬主機，一個broker里可以開設多個vhost，用作不同用戶的許可權分離。
procer：消息生產者，就是投遞消息的程序。
consumer：消息消費者，就是接受消息的程序。
channel：消息通道，在客戶端的每個連接里，可建立多個channel，每個channel代表一個會話任務。
消息隊列的使用過程，如下：
（1）客戶端連接到消息隊列伺服器，打開一個channel。
（2）客戶端聲明一個exchange，並設置相關屬性。
（3）客戶端聲明一個queue，並設置相關屬性。
（4）客戶端使用routing key，在exchange和queue之間建立好綁定關系。
（5）客戶端投遞消息到exchange。
exchange接收到消息後，就根據消息的key和已經設置的binding，進行消息路由，將消息投遞到一個或多個隊列里。
5.3 ZeroMQ
號稱史上最快的消息隊列，它實際類似於Socket的一系列介面，他跟Socket的區別是：普通的socket是端到端的（1:1的關系），而ZMQ卻是可以N：M 的關系，人們對BSD套接字的了解較多的是點對點的連接，點對點連接需要顯式地建立連接、銷毀連接、選擇協議（TCP/UDP）和處理錯誤等，而ZMQ屏蔽了這些細節，讓你的網路編程更為簡單。ZMQ用於node與node間的通信，node可以是主機或者是進程。
引用官方的說法： 「ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內核和主機盒之間彈性伸縮。ZMQ的明確目標是「成為標准網路協議棧的一部分，之後進入Linux內核」。現在還未看到它們的成功。但是，它無疑是極具前景的、並且是人們更加需要的「傳統」BSD套接字之上的一 層封裝。ZMQ讓編寫高性能網路應用程序極為簡單和有趣。」
特點是：
高性能，非持久化；
跨平台：支持Linux、Windows、OS X等。
多語言支持； C、C++、Java、.NET、Python等30多種開發語言。
可單獨部署或集成到應用中使用；
可作為Socket通信庫使用。
與RabbitMQ相比，ZMQ並不像是一個傳統意義上的消息隊列伺服器，事實上，它也根本不是一個伺服器，更像一個底層的網路通訊庫，在Socket API之上做了一層封裝，將網路通訊、進程通訊和線程通訊抽象為統一的API介面。支持「Request-Reply 「，」Publisher-Subscriber「，」Parallel Pipeline」三種基本模型和擴展模型。
ZeroMQ高性能設計要點：
1、無鎖的隊列模型
對於跨線程間的交互（用戶端和session）之間的數據交換通道pipe，採用無鎖的隊列演算法CAS；在pipe兩端注冊有非同步事件，在讀或者寫消息到pipe的時，會自動觸發讀寫事件。
2、批量處理的演算法
對於傳統的消息處理，每個消息在發送和接收的時候，都需要系統的調用，這樣對於大量的消息，系統的開銷比較大，zeroMQ對於批量的消息，進行了適應性的優化，可以批量的接收和發送消息。
3、多核下的線程綁定，無須CPU切換
區別於傳統的多線程並發模式，信號量或者臨界區， zeroMQ充分利用多核的優勢，每個核綁定運行一個工作者線程，避免多線程之間的CPU切換開銷。
5.4 Kafka
Kafka是一種高吞吐量的分布式發布訂閱消息系統，它可以處理消費者規模的網站中的所有動作流數據。 這種動作（網頁瀏覽，搜索和其他用戶的行動）是在現代網路上的許多社會功能的一個關鍵因素。 這些數據通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。 對於像Hadoop的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的消息處理，也是為了通過集群機來提供實時的消費。
Kafka是一種高吞吐量的分布式發布訂閱消息系統，有如下特性：
通過O(1)的磁碟數據結構提供消息的持久化，這種結構對於即使數以TB的消息存儲也能夠保持長時間的穩定性能。（文件追加的方式寫入數據，過期的數據定期刪除）
高吞吐量：即使是非常普通的硬體Kafka也可以支持每秒數百萬的消息。
支持通過Kafka伺服器和消費機集群來分區消息。
支持Hadoop並行數據載入。
Kafka相關概念
Broker
Kafka集群包含一個或多個伺服器，這種伺服器被稱為broker[5]
Topic
每條發布到Kafka集群的消息都有一個類別，這個類別被稱為Topic。（物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存於何處）
Partition
Parition是物理上的概念，每個Topic包含一個或多個Partition.
Procer
負責發布消息到Kafka broker
Consumer
消息消費者，向Kafka broker讀取消息的客戶端。
Consumer Group
每個Consumer屬於一個特定的Consumer Group（可為每個Consumer指定group name，若不指定group name則屬於默認的group）。
一般應用在大數據日誌處理或對實時性（少量延遲），可靠性（少量丟數據）要求稍低的場景使用。
⑧ php是什麼什麼作用
PHP（HypertextPreprocessor）是一種通用開源腳本語言。PHP語法吸收了C語言、Java和Perl的特點，利於學習，使用廣泛，主要適用於Web開發領域。PHP獨特的語法混合了C、Java、Perl以及PHP自創的語法。它可以比CGI或者Perl更快速地執行動態網頁。用PHP做出的動態頁面與其他的編程語言相比，PHP是將程序嵌入到HTML（標准通用標記語言下的一個應用）文檔中去執行，執行效率比完全生成HTML標記的CGI要高許多；PHP還可以執行編譯後代碼，編譯可以達到加密和優化代碼運行，使代碼運行更快。
1.PHP獨特的語法混合了C、Java、Perl以及PHP自創新的語法。
2.PHP可以比CGI或者Perl更快速的執行動態網頁——動態頁面方面，與其他的編程語言相比，
PHP是將程序嵌入到HTML文檔中去執行，執行效率比完全生成htmL標記的CGI要高許多；
PHP具有非常強大的功能，所有的CGI的功能PHP都能實現。
3.PHP支持幾乎所有流行的資料庫以及操作系統。
4.最重要的是PHP可以用C、C++進行程序的擴展！
PHP腳本主要用於以下三個領域：
（1）服務端腳本。這是PHP最傳統，也是最主要的目標領域。開展這項工作需要具備以下三點：PHP解析器（CGI或者伺服器模塊）、web伺服器和web瀏覽器。需要在運行web伺服器時，安裝並配置PHP，然後，可以用web瀏覽器來訪問PHP程序的輸出，即瀏覽服務端的PHP頁面。如果只是實驗PHP編程，所有的這些都可以運行在自己家裡的電腦中。請查閱安裝一章以獲取更多信息。
（2）命令行腳本。可以編寫一段PHP腳本，並且不需要任何伺服器或者瀏覽器來運行它。通過這種方式，僅僅只需要PHP解析器來執行。這種用法對於依賴cron（Unix或者Linux環境）或者TaskScheler（Windows環境）的日常運行的腳本來說是理想的選擇。這些腳本也可以用來處理簡單的文本。請參閱PHP的命令行模式以獲取更多信息。
編寫桌面應用程序。對於有著圖形界面的桌面應用程序來說，PHP或許不是一種最好的語言，但是如果用戶非常精通PHP，並且希望在客戶端應用程序中使用PHP的一些高級特性，可以利用PHP-GTK來編寫這些程序。用這種方法，還可以編寫跨平台的應用程序。PHP-GTK是PHP的一個擴展，在通常發布的PHP包中並不包含它。
（3）PHP能夠用在所有的主流操作系統上，包括Linux、Unix的各種變種（包括HP-UX、Solaris和OpenBSD）、microsoftWindows、MacOSX、RISCOS等。今天，PHP已經支持了大多數的web伺服器，包括Apache、（IIS）、PersonalwebServer（PWS）、Netscape以及iPlantserver、OreillyWebsiteProServer、Caudium、Xitami、OmniHTTPd等。對於大多數的伺服器，PHP提供了一個模塊；還有一些PHP支持CGI標准，使得PHP能夠作為CGI處理器來工作。
插件豐富，網上的解決方案有很多，而且還有龐大的開源社區可以提供幫助。
跨平台性強效率高圖像處理
面向對象
[在php4,php5中，面向對象方面都有了很大的改進，php完全可以用來開發大型商業程序。]
PHP性能很強.配合簡單、穩定、容易部署，總的來說php能幫你低成本完成事情
1)函數命名不規范駝峰法和下滑線，傳參位置不一你知道的
2)單線程；PHP本身，一直以來php就是個單進程的程序；雖然php的pthreads擴展早就有了。但是它不夠穩定，運行運行著就會莫名其妙的自己掛掉；php的擴展都是C寫的，這也就意味著任何一個擴展出現線程競爭資源控制問題都能讓整個掛掉
3）核心非同步網路不支持（當然在linux只有同步非阻塞網路模型）。卻少了這個使得很難開發一個能夠承受大並發的網路應用。傳統的網路模型和io都阻塞的。這樣基本的編程的做法就是一個進程（或者線程）響應一個用戶鏈接請求。因此無法完成像實時網游那樣需要成千上萬網路連接的任務。盡管php也有Libevent、eio擴展對此算是某種程度上面的彌補，但是感覺都不是那麼完善
4）只支持web開發，不方便做.exe文件,不方便做桌面應用程序.不方便做手機程序.
5）不適合做爬蟲、自動運行腳本.科學運算項目,這語言基本構架就不適合，雖然有很多方法實現。
6)後期維護困難。後期提速空間局限性較大。
今朝全球5000萬互聯網網站中，有60%以上使用著PHP手藝；
PHP也當選是全球五大最受接待的編程說話，而且是唯一當選的劇本說話；
國際80%以上的靜態網站都在使用PHP開拓，網路、網易、新浪、搜狐、阿里巴巴、騰訊、金山等，都有PHP的影子；
AlexaTOP500中國網站排名，有394家使用了PHP手藝，比例為78.8%。（火爆不？）
以下是某支流搜索引擎在某時辰收錄各WEB說話頁面個數的斗勁：
Php：2,150,000,000
ASPX：1,370,000,000
Java：6,710,000,00
Asp：1,140,000,000
各類類型在搜索引擎的收錄景象證實：可以或許開拓網站的說話良多，能做到精曉的只需一種；在Web手藝方面，PhP利用更遍及。
2015年6月份PHP新浪科技等諸多大媒體都在轉載了「互聯網十大搶手人材」，PHP排名後端說話第一位。據統計，PHP人材供求比抵達1:10，php高端人材特別稀缺。
PHP、C++、java這三種說話都是相當優良的劇本說話，為什麼PHP能大行其道，位居榜首呢？
從概略下去看，這是就業景象使然。越來越多的新公司或新項目使用PHP，這使得PHP相關社區越來越活躍，而這又反過來影響到良多項目或公司的挑選，構成一個良性的輪回。就我們今朝體味到的景象，PHP是國際大部門web項手段首選，而且有良多公司從其它說話（如ASP，JAVA）轉到了PHP。適合的就是最好的，PHP的快速，開拓成本低，周期短，前期保護費用低，開源產物豐盛，這些都是另外兩種說話沒法對照的。
以上各種消息都在給我們傳送一種旌旗燈號：PHP手藝今朝很給力。
薪資也是反映PHP手藝是不是給力的一個很首要的身分，PHP是不是很有前景，看中立網站職友集顯現的薪資即可！
總之，在全球前一百萬的網站中，大約有70%的站點使用PHP開拓，PHP的用武之地不只僅只是在網站開拓，在游戲開拓、廣告系統開拓、API介面開拓、移動端後台開拓，內部OA系統開拓上都能使用PHP。所以不管是斟酌開拓周期，仍是合計開拓成本,PHP都是值得優先斟酌的。不管另外說話若何興衰，但企業會一向需求PHP。