php多核

㈠ php 如何在多核伺服器上發揮性能

IBM有篇文章簡述線程數,CPU數量(核心)對性能的影響曲線
不過是一年前看到的,剛去找了找沒找到...我僅就我記得的一部分說下

IBM根據大量實際任務中的數據畫了個曲線圖(所統計的程序都是能盡可能多的利用cpu核心的程序)
在4個核心以內的機器上運行,程序性能幾乎與核心數成正比
而在4-8個核心的機器上,其性能雖然也隨核心數量增長而增長,但增長幅度一步步減弱
直到8個核心及以後,即便再增加核心,性能幾乎不會再增長.(一般的程序比這更糟糕)

------(以上這部分我記得比較清,下邊的比較模糊)-------
原因是同步等等因素的存在,導致cup核心數量在增長到一定程度後,多線程已經無法完全把cpu的性能發揮出來了
後來,文章說了一些規則以及一些新的關於鎖的演算法等等,卻依然只說有一定的幫助,但效果不是很明顯...

------(這部分是個人意見)------
然後再來說說線程數量的問題
不同的操作系統所允許一個進程的線程數量不同
而靠增加線程數量是比較好的完全利用上cpu資源的手段
但是假設是只有一個核心的cpu,一個程序開單線程就可以完全耗盡cpu資源,那麼它開雙線程就無法獲得性能的提升,甚至由於啟動一個線程的開銷,性能還會有下降.
那麼,是不是有多少個核心就只開多少線程就是最佳效果,倒也不至於...因為現在的cpu資源,普通程序,單靠一個線程很難利用完...那就可以再多開幾個互不影響的線程來壓榨cpu,具體多開的比例是多少,可以看看單線程對cpu的利用率以及實際情況而定...
不過,再來看看IBM的那個曲線圖,恐怕也就8個線程的樣子(這還得你優化的好),再往後提升就不大了...
但是,是不是就只能開這么多,那肯定不是
比如你開啟某個服務,給很多人用,你是只允許每次8個人同時使用來獲得最優整體性能,還是犧牲一部分整體性能來服務更多的人?

只是個人見解...如有錯誤還請包涵指正

㈡ phpstorm支持多核么

是的，PhpStorm支持多核處理器。PhpStorm是基於Java平台開發的IDE，它使用了Java虛擬機來運行，能夠自動利用多核處理器來提高輪搜畝其性能。在進行編譯、代碼分析等操作時，PhpStorm會自動使用多核處漏汪理器來並行處理臘森任務，加快程序的運行速度和響應速度。此外，PhpStorm還提供了一些性能調優選項，您可以根據自己的需要進行設置，進一步提升其性能。

㈢ 大型的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應用，通常使用什麼應用做消息隊列

一、消息隊列概述x0dx0a消息隊列中間件是分布式系統中重要的組件，主要解決應用耦合，非同步消息，流量削鋒等問題。實現高性能，高可用，可伸縮和最終一致性架構。是大型分布式系統不可缺少的中間件。x0dx0a目前在生產環境，使用較多的消息隊列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。x0dx0a二、消息隊列應用場景x0dx0a以下介紹消息隊列在實際應用中常用的使用場景。非同步處理，應用解耦，流量削鋒和消息通訊四個場景。x0dx0a2.1非同步處理x0dx0a場景說明：用戶注冊後，需要發注冊郵件和注冊簡訊。傳統的做法有兩種1.串列的方式；2.並行方式。x0dx0a（1）串列方式：將注冊信息寫入資料庫成功後，發送注冊郵件，再發送注冊簡訊。以上三個任務全部完成後，返回給客戶端。（架構KKQ：466097527，歡迎加入）x0dx0a（2）並行方式：將注冊信息寫入資料庫成功後，發送注冊郵件的同時，發送注冊簡訊。以上三個任務完成後，返回給客戶端。與串列的差別是，並行的方式可以提高處理的時間。x0dx0a假設三個業務節點每個使用50毫秒鍾，不考慮網路等其他開銷，則串列方式的時間是150毫秒，並行的時間可能是100毫秒。x0dx0a因為CPU在單位時間內處理的請求數是一定的，假設CPU1秒內吞吐量是100次。則串列方式1秒內CPU可處理的請求量是7次（1000/150）。並行方式處理的請求量是10次（1000/100）。x0dx0a小結：如以上案例描述，傳統的方式系統的性能（並發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？x0dx0a引入消息隊列，將不是必須的業務邏輯，非同步處理。改造後的架構如下：x0dx0a按照以上約定，用戶的響應時間相當於是注冊信息寫入資料庫的時間，也就是50毫秒。注冊郵件，發送簡訊寫入消息隊列後，直接返回，因此寫入消息隊列的速度很快，基本可以忽略，因此用戶的響應時間可能是50毫秒。因此架構改變後，系統的吞吐量提高到每秒20 QPS。比串列提高了3倍，比並行提高了兩倍。x0dx0a2.2應用解耦x0dx0a場景說明：用戶下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用庫存系統的介面。如下圖：x0dx0a傳統模式的缺點：x0dx0a1） 假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗；x0dx0a2） 訂單系統與庫存系統耦合；x0dx0a如何解決以上問題呢？引入應用消息隊列後的方案，如下圖：x0dx0a訂單系統：用戶下單後，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功。x0dx0a庫存系統：訂閱下單的消息，採用拉/推的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操作。x0dx0a假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單後，訂單系統寫入消息隊列就不再關心其他的後續操作了。實現訂單系統與庫存系統的應用解耦。x0dx0a2.3流量削鋒x0dx0a流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。x0dx0a應用場景：秒殺活動，一般會因為流量過大，導致流量暴增，應用掛掉。為解決這個問題，一般需要在應用前端加入消息隊列。x0dx0a可以控制活動的人數；x0dx0a可以緩解短時間內高流量壓垮應用；x0dx0a用戶的請求，伺服器接收後，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面；x0dx0a秒殺業務根據消息隊列中的請求信息，再做後續處理。x0dx0a2.4日誌處理x0dx0a日誌處理是指將消息隊列用在日誌處理中，比如Kafka的應用，解決大量日誌傳輸的問題。架構簡化如下：x0dx0a日誌採集客戶端，負責日誌數據採集，定時寫受寫入Kafka隊列；x0dx0aKafka消息隊列，負責日誌數據的接收，存儲和轉發；x0dx0a日誌處理應用：訂閱並消費kafka隊列中的日誌數據；x0dx0a以下是新浪kafka日誌處理應用案例：x0dx0a(1)Kafka：接收用戶日誌的消息隊列。x0dx0a(2)Logstash：做日誌解析，統一成JSON輸出給Elasticsearch。x0dx0a(3)Elasticsearch：實時日誌分析服務的核心技術，一個schemaless，實時的數據存儲服務，通過index組織數據，兼具強大的搜索和統計功能。x0dx0a(4)Kibana：基於Elasticsearch的數據可視化組件，超強的數據可視化能力是眾多公司選擇ELK stack的重要原因。x0dx0a2.5消息通訊x0dx0a消息通訊是指，消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。比如實現點對點消息隊列，或者聊天室等。x0dx0a點對點通訊：x0dx0a客戶端A和客戶端B使用同一隊列，進行消息通訊。x0dx0a聊天室通訊：x0dx0a客戶端A，客戶端B，客戶端N訂閱同一主題，進行消息發布和接收。實現類似聊天室效果。x0dx0a以上實際是消息隊列的兩種消息模式，點對點或發布訂閱模式。模型為示意圖，供參考。x0dx0a三、消息中間件示例x0dx0a3.1電商系統x0dx0a消息隊列採用高可用，可持久化的消息中間件。比如Active MQ，Rabbit MQ，Rocket Mq。（1）應用將主幹邏輯處理完成後，寫入消息隊列。消息發送是否成功可以開啟消息的確認模式。（消息隊列返回消息接收成功狀態後，應用再返回，這樣保障消息的完整性）x0dx0a（2）擴展流程（發簡訊，配送處理）訂閱隊列消息。採用推或拉的方式獲取消息並處理。x0dx0a（3）消息將應用解耦的同時，帶來了數據一致性問題，可以採用最終一致性方式解決。比如主數據寫入資料庫，擴展應用根據消息隊列，並結合資料庫方式實現基於消息隊列的後續處理。x0dx0a3.2日誌收集系統x0dx0a分為Zookeeper注冊中心，日誌收集客戶端，Kafka集群和Storm集群（OtherApp）四部分組成。x0dx0aZookeeper注冊中心，提出負載均衡和地址查找服務；x0dx0a日誌收集客戶端，用於採集應用系統的日誌，並將數據推送到kafka隊列；x0dx0a四、JMS消息服務x0dx0a講消息隊列就不得不提JMS 。JMS（Java Message Service,Java消息服務）API是一個消息服務的標准/規范，允許應用程序組件基於JavaEE平台創建、發送、接收和讀取消息。它使分布式通信耦合度更低，消息服務更加可靠以及非同步性。x0dx0a在EJB架構中，有消息bean可以無縫的與JM消息服務集成。在J2EE架構模式中，有消息服務者模式，用於實現消息與應用直接的解耦。x0dx0a4.1消息模型x0dx0a在JMS標准中，有兩種消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。x0dx0a4.1.1 P2P模式x0dx0aP2P模式包含三個角色：消息隊列（Queue），發送者(Sender)，接收者(Receiver)。每個消息都被發送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留著消息，直到他們被消費或超時。x0dx0aP2P的特點x0dx0a每個消息只有一個消費者（Consumer）(即一旦被消費，消息就不再在消息隊列中)x0dx0a發送者和接收者之間在時間上沒有依賴性，也就是說當發送者發送了消息之後，不管接收者有沒有正在運行，它不會影響到消息被發送到隊列x0dx0a接收者在成功接收消息之後需向隊列應答成功x0dx0a如果希望發送的每個消息都會被成功處理的話，那麼需要P2P模式。（架構KKQ：466097527，歡迎加入）x0dx0a4.1.2 Pub/sub模式x0dx0a包含三個角色主題（Topic），發布者（Publisher），訂閱者（Subscriber） 。多個發布者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。x0dx0aPub/Sub的特點x0dx0a每個消息可以有多個消費者x0dx0a發布者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之後，才能消費發布者的消息。x0dx0a為了消費消息，訂閱者必須保持運行的狀態。x0dx0a為了緩和這樣嚴格的時間相關性，JMS允許訂閱者創建一個可持久化的訂閱。這樣，即使訂閱者沒有被激活（運行），它也能接收到發布者的消息。x0dx0a如果希望發送的消息可以不被做任何處理、或者只被一個消息者處理、或者可以被多個消費者處理的話，那麼可以採用Pub/Sub模型。x0dx0a4.2消息消費x0dx0a在JMS中，消息的產生和消費都是非同步的。對於消費來說，JMS的消息者可以通過兩種方式來消費消息。x0dx0a（1）同步x0dx0a訂閱者或接收者通過receive方法來接收消息，receive方法在接收到消息之前（或超時之前）將一直阻塞；x0dx0a（2）非同步x0dx0a訂閱者或接收者可以注冊為一個消息監聽器。當消息到達之後，系統自動調用監聽器的onMessage方法。x0dx0aJNDI：Java命名和目錄介面,是一種標準的Java命名系統介面。可以在網路上查找和訪問服務。通過指定一個資源名稱，該名稱對應於資料庫或命名服務中的一個記錄，同時返回資源連接建立所必須的信息。x0dx0aJNDI在JMS中起到查找和訪問發送目標或消息來源的作用。（架構KKQ：466097527，歡迎加入）x0dx0a4.3JMS編程模型x0dx0a(1) ConnectionFactoryx0dx0a創建Connection對象的工廠，針對兩種不同的jms消息模型，分別有QueueConnectionFactory和TopicConnectionFactory兩種。可以通過JNDI來查找ConnectionFactory對象。x0dx0a(2) Destinationx0dx0aDestination的意思是消息生產者的消息發送目標或者說消息消費者的消息來源。對於消息生產者來說，它的Destination是某個隊列（Queue）或某個主題（Topic）;對於消息消費者來說，它的Destination也是某個隊列或主題（即消息來源）。x0dx0a所以，Destination實際上就是兩種類型的對象：Queue、Topic可以通過JNDI來查找Destination。x0dx0a(3) Connectionx0dx0aConnection表示在客戶端和JMS系統之間建立的鏈接（對TCP/IP socket的包裝）。Connection可以產生一個或多個Session。跟ConnectionFactory一樣，Connection也有兩種類型：QueueConnection和TopicConnection。x0dx0a(4) Sessionx0dx0aSession是操作消息的介面。可以通過session創建生產者、消費者、消息等。Session提供了事務的功能。當需要使用session發送/接收多個消息時，可以將這些發送/接收動作放到一個事務中。同樣，也分QueueSession和TopicSession。x0dx0a(5) 消息的生產者x0dx0a消息生產者由Session創建，並用於將消息發送到Destination。同樣，消息生產者分兩種類型：QueueSender和TopicPublisher。可以調用消息生產者的方法（send或publish方法）發送消息。x0dx0a(6) 消息消費者x0dx0a消息消費者由Session創建，用於接收被發送到Destination的消息。兩種類型：QueueReceiver和TopicSubscriber。可分別通過session的createReceiver(Queue)或createSubscriber(Topic)來創建。當然，也可以session的creatDurableSubscriber方法來創建持久化的訂閱者。x0dx0a(7) MessageListenerx0dx0a消息監聽器。如果注冊了消息監聽器，一旦消息到達，將自動調用監聽器的onMessage方法。EJB中的MDB（Message-Driven Bean）就是一種MessageListener。x0dx0a深入學習JMS對掌握JAVA架構，EJB架構有很好的幫助，消息中間件也是大型分布式系統必須的組件。本次分享主要做全局性介紹，具體的深入需要大家學習，實踐，總結，領會。x0dx0a五、常用消息隊列x0dx0a一般商用的容器，比如WebLogic，JBoss，都支持JMS標准，開發上很方便。但免費的比如Tomcat，Jetty等則需要使用第三方的消息中間件。本部分內容介紹常用的消息中間件（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他們的特點。x0dx0a5.1 ActiveMQx0dx0aActiveMQ 是Apache出品，最流行的，能力強勁的開源消息匯流排。ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規范的 JMS Provider實現，盡管JMS規范出台已經是很久的事情了，但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。x0dx0aActiveMQ特性如下：x0dx0a⒈ 多種語言和協議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應用協議： OpenWire,Stomp REST,WS Notification,XMPP,AMQPx0dx0a⒉ 完全支持JMS1.1和J2EE 1.4規范 （持久化，XA消息，事務)x0dx0a⒊ 對spring的支持，ActiveMQ可以很容易內嵌到使用Spring的系統裡面去，而且也支持Spring2.0的特性x0dx0a⒋ 通過了常見J2EE伺服器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業伺服器上x0dx0a⒌ 支持多種傳送協議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTAx0dx0a⒍ 支持通過JDBC和journal提供高速的消息持久化x0dx0a⒎ 從設計上保證了高性能的集群，客戶端-伺服器，點對點x0dx0a⒏ 支持Ajaxx0dx0a⒐ 支持與Axis的整合x0dx0a⒑ 可以很容易得調用內嵌JMS provider，進行測試x0dx0a5.2 RabbitMQx0dx0aRabbitMQ是流行的開源消息隊列系統，用erlang語言開發。RabbitMQ是AMQP（高級消息隊列協議）的標准實現。支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。x0dx0a幾個重要概念：x0dx0aBroker：簡單來說就是消息隊列伺服器實體。x0dx0aExchange：消息交換機，它指定消息按什麼規則，路由到哪個隊列。x0dx0aQueue：消息隊列載體，每個消息都會被投入到一個或多個隊列。x0dx0aBinding：綁定，它的作用就是把exchange和queue按照路由規則綁定起來。x0dx0aRouting Key：路由關鍵字，exchange根據這個關鍵字進行消息投遞。x0dx0avhost：虛擬主機，一個broker里可以開設多個vhost，用作不同用戶的許可權分離。x0dx0aprocer：消息生產者，就是投遞消息的程序。x0dx0aconsumer：消息消費者，就是接受消息的程序。x0dx0achannel：消息通道，在客戶端的每個連接里，可建立多個channel，每個channel代表一個會話任務。x0dx0a消息隊列的使用過程，如下：x0dx0a（1）客戶端連接到消息隊列伺服器，打開一個channel。x0dx0a（2）客戶端聲明一個exchange，並設置相關屬性。x0dx0a（3）客戶端聲明一個queue，並設置相關屬性。x0dx0a（4）客戶端使用routing key，在exchange和queue之間建立好綁定關系。x0dx0a（5）客戶端投遞消息到exchange。x0dx0aexchange接收到消息後，就根據消息的key和已經設置的binding，進行消息路由，將消息投遞到一個或多個隊列里。x0dx0a5.3 ZeroMQx0dx0a號稱史上最快的消息隊列，它實際類似於Socket的一系列介面，他跟Socket的區別是：普通的socket是端到端的（1:1的關系），而ZMQ卻是可以N：M 的關系，人們對BSD套接字的了解較多的是點對點的連接，點對點連接需要顯式地建立連接、銷毀連接、選擇協議（TCP/UDP）和處理錯誤等，而ZMQ屏蔽了這些細節，讓你的網路編程更為簡單。ZMQ用於node與node間的通信，node可以是主機或者是進程。x0dx0a引用官方的說法： 「ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內核和主機盒之間彈性伸縮。ZMQ的明確目標是「成為標准網路協議棧的一部分，之後進入Linux內核」。現在還未看到它們的成功。但是，它無疑是極具前景的、並且是人們更加需要的「傳統」BSD套接字之上的一 層封裝。ZMQ讓編寫高性能網路應用程序極為簡單和有趣。」x0dx0a特點是：x0dx0a高性能，非持久化；x0dx0a跨平台：支持Linux、Windows、OS X等。x0dx0a多語言支持； C、C++、Java、.NET、Python等30多種開發語言。x0dx0a可單獨部署或集成到應用中使用；x0dx0a可作為Socket通信庫使用。x0dx0a與RabbitMQ相比，ZMQ並不像是一個傳統意義上的消息隊列伺服器，事實上，它也根本不是一個伺服器，更像一個底層的網路通訊庫，在Socket API之上做了一層封裝，將網路通訊、進程通訊和線程通訊抽象為統一的API介面。支持「Request-Reply 「，」Publisher-Subscriber「，」Parallel Pipeline」三種基本模型和擴展模型。x0dx0aZeroMQ高性能設計要點：x0dx0a1、無鎖的隊列模型x0dx0a對於跨線程間的交互（用戶端和session）之間的數據交換通道pipe，採用無鎖的隊列演算法CAS；在pipe兩端注冊有非同步事件，在讀或者寫消息到pipe的時，會自動觸發讀寫事件。x0dx0a2、批量處理的演算法x0dx0a對於傳統的消息處理，每個消息在發送和接收的時候，都需要系統的調用，這樣對於大量的消息，系統的開銷比較大，zeroMQ對於批量的消息，進行了適應性的優化，可以批量的接收和發送消息。x0dx0a3、多核下的線程綁定，無須CPU切換x0dx0a區別於傳統的多線程並發模式，信號量或者臨界區， zeroMQ充分利用多核的優勢，每個核綁定運行一個工作者線程，避免多線程之間的CPU切換開銷。x0dx0a5.4 Kafkax0dx0aKafka是一種高吞吐量的分布式發布訂閱消息系統，它可以處理消費者規模的網站中的所有動作流數據。 這種動作（網頁瀏覽，搜索和其他用戶的行動）是在現代網路上的許多社會功能的一個關鍵因素。 這些數據通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。 對於像Hadoop的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的消息處理，也是為了通過集群機來提供實時的消費。x0dx0aKafka是一種高吞吐量的分布式發布訂閱消息系統，有如下特性：x0dx0a通過O(1)的磁碟數據結構提供消息的持久化，這種結構對於即使數以TB的消息存儲也能夠保持長時間的穩定性能。（文件追加的方式寫入數據，過期的數據定期刪除）x0dx0a高吞吐量：即使是非常普通的硬體Kafka也可以支持每秒數百萬的消息。x0dx0a支持通過Kafka伺服器和消費機集群來分區消息。x0dx0a支持Hadoop並行數據載入。x0dx0aKafka相關概念x0dx0aBrokerx0dx0aKafka集群包含一個或多個伺服器，這種伺服器被稱為broker[5]x0dx0aTopicx0dx0a每條發布到Kafka集群的消息都有一個類別，這個類別被稱為Topic。（物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存於何處）x0dx0aPartitionx0dx0aParition是物理上的概念，每個Topic包含一個或多個Partition.x0dx0aProcerx0dx0a負責發布消息到Kafka brokerx0dx0aConsumerx0dx0a消息消費者，向Kafka broker讀取消息的客戶端。x0dx0aConsumer Groupx0dx0a每個Consumer屬於一個特定的Consumer Group（可為每個Consumer指定group name，若不指定group name則屬於默認的group）。x0dx0a一般應用在大數據日誌處理或對實時性（少量延遲），可靠性（少量丟數據）要求稍低的場景使用。

㈤ PHP如何解決網站的大數據大流量與高並發

1. 使用緩存，比如memcache,redis,因為它們是在內存中運行，所以處理數據，返回數據非常快，所以可以應對高並發。

2.增加帶寬和機器性能，1M的帶寬同時處理的流量肯定有限，所以在資源允許的情況下，大帶寬，多核cpu,高內存是一個解決方案。

3.分布式，讓多個訪問分到不同的機器上去處理，每個機器處理的請求就相對減少了。

簡單說些常用技術，負載均衡，限流，加速器等

㈥ php是什麼意思

php通常指超文本預處理器，用於面向對象、命令式編程，是一種通用開源腳本語言。

主要特點:

為開源性和免費性、快捷性、資料庫連接的廣泛性、面向過程和面向對象並用。優點是利於學習，使用廣泛。此外，php還可以指菲律賓比索的標准貨幣代碼符號，MPLS網路中的倒數第二跳彈出功能。是英文超級文本預處理語言Hypertext Preprocessor的縮寫。PHP 是一種HTML 內嵌式的語言，是一種在伺服器端執行嵌入HTML文檔的腳本語言，語言風格有些類似於C語言，被廣泛的運用。

簡介:

PHP(外文名:PHP: Hypertext Preprocessor，中文名：「超文本預處理器」)是一種通用開源腳本語言。語法吸收了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是一個受眾大並且擁有眾多開發者的開源軟體項目，Linux + Nginx + Mysql + PHP是它的經典安裝部署方式，相關的軟體全部都是開源免費的，所以使用PHP可以節約大量的正版授權費用。不過PHP作為一個開源軟體，它缺乏大型科技公司的支持背景，網路上對它的唱衰也是經久不衰，不過它的持續迭代和性能持續增強的現實卻是鼓舞人心的，PHP社區用實際行動給予各種質疑強有力的回擊。

快捷高效

PHP的內核是C語言編寫的基礎好效率高，可以用C語言開發高性能的擴展組件;PHP的核心包含了數量超過1000的內置函數，功能應有盡有很全面，開箱即用程序代碼簡潔； PHP數組支持動態擴容，支持以數字、字元串或者混合鍵名的關聯數組，能大幅提高開發效率； PHP是一門弱類型語言，程序編譯通過率高，相對其他強類型語言開發效率快；PHP天然熱部署，在php-fpm運行模式下代碼文件覆蓋即完成熱部署；PHP經過20多年的發展，在互聯網上可以搜到海量的參考資料供參考學習。

性能提升

PHP版本越高它的整體性能越高，根據官方介紹，PHP7.0.0 對比PHP5.6性能就提升了2倍，PHP7.4已經比PHP7.0快了約30％，PHP8.0在性能上又相對PHP7.4大約改進了10%。PHP 8.0 引入了 JIT編譯器特性，同時加入多種新的語言功能，例如命名參數、聯合類型、註解、Constructor Property Promotion、match 表達式、nullsafe 運算符以及對類型系統、錯誤處理和一致性的改進。PHP擁有自己的核心開發團隊，保持5年發布一個大版本、1個月發布2個小版本的頻率，最新的版本是PHP8.08 。

跨平台

每個平台都有對應的php解釋器版本，指針對不同平台均編譯出目標平台的二進制碼(PHP解釋器)，php開發的程序可以不經修改運行在windows、linux、unix等多個操作系統上。

常駐內存

php-cli模式下可以實現程序常駐內存，各種變數和資料庫連接都能長久保存在內存實現資源復用，比較常用的做法是結合swoole 組件編寫cli框架。

頁面生命周期

在php-fpm模式下，所有的變數都是頁面級的，無論是全局變數還是類的靜態成員，都會在頁面執行完畢後被清空，對程序員水平要求低，佔用內存非常少，特別適合中小型系統的開發。

運行機制:

PHP常見的運行模式有2種，分別是php-fpm 和php-cli 。當PHP 選擇運行在php-fpm模式下，所有的變數都是頁面級的，無論是全局變數還是類的靜態成員，都會在頁面執行完畢後被清空。運行在php-cli模式下可以實現程序常駐內存，各種變數和資料庫連接都能長久保存在內存 實現資源復用，性能可以得到很大的提升，php-cli開發比較復雜能但是能夠獲取更高的性能，對開發者的要求比較高需要比較高的開發水平，比較常用的模式是結合swoole 組件編寫cli框架，各種變數能保存在跨進程的高性能共享內存 Table ，可以開發出支持熱啟動的php-cli可靠各類應用系統。

php-fpm在PHP 5.3.3 版本成為了官方正式組件（2010-07-22），它提供了穩定可靠的進程管理服務，進程不足時候可以智能擴充數量，閑置時候可以自動回收銷毀多餘的進程，同時它對程序的容錯能力很強大運行非常穩定，可以應付企業級的開發需求。php-fpm友好的完成了使用HTTP/HTTPS等TCP/IP互聯網協議下進行的用戶的輸入輸出，頁面級生命周期各種資源用完即釋放，不存在內存泄漏的問題。php-fpm也提供有一些常駐內存的技術支持,例如PHP 7.4引入的opcache.preload也能實現局部的PHP類和函數的常駐內存，不過這個方法不夠靈活，和伺服器配置捆綁的太死了。

php-cli因為能實現各類資源的常駐內存，所以可以資源復用，更高效完成多進程編程和非同步編程，可以開發出負載能力更高的應用系統。但是相對php-fpm的簡單編程開發，開發者要注意很多的事項和需要做很多附加的控制器開發，否則就無法實現期待中的高性能。

首先開發者需要去實現可靠的進程管理服務，保證系統進程遇到各類錯誤退出運行後能夠自動創建新的進程，只有這樣才能保證後續的服務請求有足夠空閑進程可分配。每個業務代碼段都要做異常處理，讓進程遇到非致命錯誤時候不會退出，因為進程重啟意味程序和各類資源需要再次載入，這個過程性能消耗不小，所以只有進程穩定運行了常駐內存才有意義。

其次因為常駐內存,編寫的新的程序必須重啟服務才能生效，這一點習慣了fpm模式的開發者會感到比較陌生。另外開發者需要手工釋放內存，否則系統長時間運行後會出現內存泄露。同時在cli模式下，我們不能像fpm里直接用 $_SERVER、$_POST、$_GET、$_COOKI和$_FILES 進行編程工作，需要自己去解析各種互聯網通訊協議完成用戶的輸入輸出。要實現多進程編程利用多核CPU計算,還有學習使用pcntl和posix編程，這里涉及到了非同步編程邏輯，這塊難度還是比較大的。比較常用的模式是結合swoole 組件編寫cli框架。

PHP是一個活躍的社區開發語言，有專業的核心開發團隊在持續不斷的迭代，最近一個版本就是PHP 8.0.8 引入了很多的新特性。

語言參考:

內置函數

PHP 有很多標準的函數和結構。還有一些函數需要和特定的擴展模塊一起編譯，否則在使用它們的時候就會得到一個致命的「未定義函數」錯誤。例如，要使用 image 函數中的 imagecreatetrue，需要在編譯 PHP 的時候加上 GD 的支持。或者要使用 mysqli_connect函數，就需要在編譯 PHP 的時候加上 MySQLi 支持。有很多核心函數已包含在每個版本的 PHP 中如字元串和變數函數。調用 phpinfo或者 get_loaded_extensions可以得知 PHP 載入了那些擴展庫。同時還應該注意，很多擴展庫默認就是有效的。

靜態網站與動態網站的區別

靜態網站：web1.0 時代

動態網站：web2.0 時代

靜態網站特點：

1、網頁內容一經發布到網站伺服器，無論是否有用戶訪問，每個靜態頁面的內容都是保存在網站伺服器上的。也就是說，靜態網頁是實實在在保存在伺服器上的文件，每個網頁都是一個獨立的文件。

2、靜態網頁的內容相對穩定，因此容易被搜索引擎檢索。

3、 靜態網頁沒有資料庫的支持，在網站製作和維護方面工作量較大，因此當網站信息量很大時完全依靠靜態網頁製作方式比較困難。

4、靜態網頁的交互性較差，在功能方面有較大的限制。

㈦ php新手學習路線是怎樣的

第一階段：基礎階段（基礎PHP程序員）

重點：把LNMP搞熟練（核心是安裝配置基本操作） 目標：能夠完成基本的LNMP系統安裝，簡單配置維護；能夠做基本的簡單系統的PHP開發；能夠在PHP中型系統中支持某個PHP功能模塊的開發。

時間：完成本階段的時間因人而異，有的成長快半年一年就過了，成長慢的兩三年也有。

1. Linux

   基本命令、操作、啟動、基本服務配置（包括rpm安裝文件，各種服務配置等）；會寫簡單的shell腳本和awk/sed 腳本命令等。

2. Nginx

   做到能夠安裝配置nginx+php，知道基本的nginx核心配置選項，知道 server/fastcgi_pass/access_log 等基礎配置，目標是能夠讓nginx+php_fpm順利工作。

3. MySQL

   會自己搭建mysql，知道基本的mysql配置選項；知道innodb和myisam的區別，知道針對InnoDB和MyISAM兩個引擎的不同配置選項；知道基本的兩個引擎的差異和選擇上面的區別；能夠純手工編譯搭建一個MySQL資料庫並且配置好編碼等正常穩定運行；核心主旨是能夠搭建一個可運行的MySQL資料庫。

4. PHP

   基本語法數組、字元串、資料庫、XML、Socket、GD/ImageMgk圖片處理等等；熟悉各種跟MySQL操作鏈接的api（mysql/mysqli/PDO)，知道各種編碼問題的解決；知道常規熟練使用的PHP框架（ThinkPHP、Zendframework、Yii、Yaf等）；了解基本MVC的運行機制和為什麼這么做，稍微知道不同的PHP框架之間的區別；能夠快速學習一個MVC框架。能夠知道開發工程中的文件目錄組織，有基本的良好的代碼結構和風格，能夠完成小系統的開發和中型系統中某個模塊的開發工作。

5. 前端

   如果條件時間允許，可以適當學習下 HTML/CSS/JS 等相關知識，知道什麼web標准，div+css的web/wap頁面模式，知道HTML5和HTML4的區別；了解一些基本的前端只是和JS框架（jQuery之類的）；了解一些基本的JavaScript編程知識；（本項不是必須項，如果有時間，稍微了解一下是可以的，不過不建議作為重點，除非個人有強烈興趣）。

6. 系統設計

   能夠完成小型系統的基本設計，包括簡單的資料庫設計，能夠完成基本的：瀏覽器 -> Nginx+PHP -> 資料庫 架構的設計開發工作；能夠支撐每天幾十萬到數百萬流量網站的開發維護工作；

   第二階段：提高階段 （中級PHP程序員）

   重點：提高針對LNMP的技能，能夠更全面的對LNMP有熟練的應用。 目標：能夠隨時隨地搭建好LNMP環境，快速完成常規配置；能夠追查解決大部分遇到的開發和線上環境的問題；能夠獨立承擔中型系統的構架和開發工作；能夠在大型系統中承擔某個中型模塊的開發工作。

   1. Linux

   在第一階段的基礎上面，能夠流暢的使用Shell腳本來完成很多自動化的工作；awk/sed/perl 也操作的不錯，能夠完成很多文本處理和數據統計等工作；基本能夠安裝大部分非特殊的Linux程序（包括各種庫、包、第三方依賴等等，比如MongoDB/Redis/Sphinx/Luncene/SVN之類的）；了解基本的Linux服務，知道如何查看Linux的性能指標數據，知道基本的Linux下面的問題跟蹤等。

   2. Nginx

   在第一階段的基礎上面，了解復雜一些的Nginx配置；包括 多核配置、events、proxy_pass，sendfile/tcp_*配置，知道超時等相關配置和性能影響；知道nginx除了web server，還能夠承擔代理伺服器、反向靜態伺服器等配置；知道基本的nginx配置調優；知道如何配置許可權、編譯一個nginx擴展到nginx；知道基本的nginx運行原理（master/worker機制，epoll），知道為什麼nginx性能比apache性能好等知識。

   3. MySQL/MongoDB

   在第一階段的基礎上面，在MySQL開發方面，掌握很多小技巧，包括常規SQL優化（group by/order by/rand優化等）；除了能夠搭建MySQL，還能夠冷熱備份MySQL數據，還知道影響innodb/myisam性能的配置選項（比如key_buffer/query_cache/sort_buffer/innodb_buffer_pool_size/innodb_flush_log_at_trx_commit等），也知道這些選項配置成為多少值合適；另外也了解一些特殊的配置選項，比如 知道如何搭建mysql主從同步的環境，知道各個binlog_format的區別；知道MySQL的性能追查，包括slow_log/explain等，還能夠知道基本的索引建立處理等知識；原理方面了解基本的MySQL的架構（Server+存儲引擎），知道基本的InnoDB/MyISAM索引存儲結構和不同（聚簇索引，B樹）；知道基本的InnoDB事務處理機制；了解大部分MySQL異常情況的處理方案（或者知道哪兒找到處理方案）。條件允許的情況，建議了解一下NoSQL的代表MongoDB資料庫，順便對比跟MySQL的差別，同事能夠在合適的應用場景安全謹慎的使用MongoDB，知道基本的PHP與MongoDB的結合開發。

   4. Redis/Memcached

   在大部分中型系統裡面一定會涉及到緩存處理，所以一定要了解基本的緩存；知道Memcached和Redis的異同和應用場景，能夠獨立安裝 Redis/Memcached，了解Memcahed的一些基本特性和限制，比如最大的value值，知道PHP跟他們的使用結合；Redis了解基本工作原理和使用，了解常規的數據類型，知道什麼場景應用什麼類型，了解Redis的事務等等。原理部分，能夠大概了解Memcached的內存結構（slab機制），redis就了解常用數據類型底層實現存儲結構（SDS/鏈表/SkipList/HashTable）等等，順便了解一下Redis的事務、RDB、AOF等機制更好。

   5. PHP

   除了第一階段的能力，安裝配置方面能夠隨意安裝PHP和各種第三方擴展的編譯安裝配置；了解php-fpm的大部分配置選項和含義（如max_requests/max_children/request_terminate_timeout之類的影響性能的配置），知道mod_php/fastcgi的區別；在PHP方面已經能夠熟練各種基礎技術，還包括各種深入些的PHP，包括對PHP面向對象的深入理解/SPL/語法層面的特殊特性比如反射之類的；在框架方面已經閱讀過最少一個以上常規PHP MVC框架的代碼了，知道基本PHP框架內部實現機制和設計思想；在PHP開發中已經能夠熟練使用常規的設計模式來應用開發（抽象工廠/單例/觀察者/命令鏈/策略/適配器 等模式）；建議開發自己的PHP MVC框架來充分讓開發自由化，讓自己深入理解MVC模式，也讓自己能夠在業務項目開發里快速升級；熟悉PHP的各種代碼優化方法，熟悉大部分PHP安全方面問題的解決處理；熟悉基本的PHP執行的機制原理（Zend引擎/擴展基本工作機制）。

   6. C/C++

   開始涉獵一定的C/C++語言，能夠寫基本的C/C++代碼，對基本的C/C++語法熟悉（指針、數組操作、字元串、常規標准API）和數據結構（鏈表、樹、哈希、隊列）有一定的熟悉下；對Linux下面的C語言開發有基本的了解概念，會簡單的makefile文件編寫，能夠使用簡單的GCC/GDB的程序編譯簡單調試工作；對基本的網路編程有大概了解。（本項是為了向更高層次打下基礎）。

   7. 前端

   在第一階段的基礎上面，熟悉基本的HTTP協議（協議代碼200/300/400/500，基本的HTTP交互頭）；條件允許，可以在深入寫出稍微優雅的HTML+CSS+JavaScript，或者能夠大致簡單使用某些前端框架（jQuery/YUI/ExtJS/RequireJS/BootStrap之類）；如果條件允許，可以深入學習JavaScript編程，比如閉包機制、DOM處理；再深入些可以讀讀jQuery源碼做深入學習。（本項不做重點學習，除非對前端有興趣）。

   8. 系統設計

   能夠設計大部分中型系統的網站架構、資料庫、基本PHP框架選型；性能測試排查處理等；能夠完成類似：瀏覽器 -> CDN(Squid) -> Nginx+PHP -> 緩存 -> 資料庫 結構網站的基本設計開發維護；能夠支撐每天數百萬到千萬流量基本網站的開發維護工作；

   第三階段：高級階段 （高級PHP程序員）

   重點：除了基本的LNMP程序，還能夠在某個方向或領域有深入學習。（縱深維度發展） 目標：除了能夠完成基本的PHP業務開發，還能夠解決大部分深入復雜的技術問題，並且可以獨立設計完成中大型的系統設計和開發工作；自己能夠獨立hold深入某個技術方向，在這塊比較專業。（比如在MySQL、Nginx、PHP、Redis等等任一方向深入研究）

   1. Linux

   除了第二階段的能力，在Linux下面除了常規的操作和性能監控跟蹤，還能夠使用很多高級復雜的命令完成工作（watch/tcpmp/starce/ldd/ar等)；在shell腳本方面，已經能夠編寫比較復雜的shell腳本（超過500行）來協助完成很多包括備份、自動化處理、監控等工作的shell；對awk/sed/perl 等應用已經如火純青，能夠隨意操作控制處理文本統計分析各種復雜格式的數據；對Linux內部機制有一些了解，對內核模塊載入，啟動錯誤處理等等有個基本的處理；同時對一些其他相關的東西也了解，比如NFS、磁碟管理等等；

   2. Nginx

   在第二階段的基礎上面，已經能夠把Nginx操作的很熟練，能夠對Nginx進行更深入的運維工作，比如監控、性能優化，復雜問題處理等等；看個人興趣，更多方面可以考慮側重在關於Nginx工作原理部分的深入學習，主要表現在閱讀源碼開始，比如具體的master/worker工作機制，Nginx內部的事件處理，內存管理等等；同時可以學習Nginx擴展的開發，可以定製一些自己私有的擴展；同時可以對Nginx+Lua有一定程度的了解，看看是否可以結合應用出更好模式；這個階段的要求是對Nginx原理的深入理解，可以考慮成為Nginx方向的深入專業者。

   3. MySQL/MongoDB

   在第二階段的基礎上面，在MySQL應用方面，除了之前的基本SQL優化，還能夠在完成一些復雜操作，比如大批量數據的導入導出，線上大批量數據的更改表結構或者增刪索引欄位等等高危操作；除了安裝配置，已經能夠處理更多復雜的MySQL的問題，比如各種問題的追查，主從同步延遲問題的解決、跨機房同步數據方案、MySQL高可用架構等都有涉及了解；對MySQL應用層面，對MySQL的核心關鍵技術比較熟悉，比如事務機制（隔離級別、鎖等）、對觸發器、分區等技術有一定了解和應用；對MySQL性能方面，有包括磁碟優化（SAS遷移到SSD）、伺服器優化（內存、伺服器本身配置）、除了二階段的其他核心性能優化選項（innodb_log_buffer_size/back_log/table_open_cache/thread_cache_size/innodb_lock_wait_timeout等）、連接池軟體選擇應用，對show *（show status/show profile）類的操作語句有深入了解，能夠完成大部分的性能問題追查；MySQL備份技術的深入熟悉，包括災備還原、對Binlog的深入理解，冷熱備份，多IDC備份等；在MySQL原理方面，有更多了解，比如對MySQL的工作機制開始閱讀部分源碼，比如對主從同步（復制）技術的源碼學習，或者對某個存儲引擎（MyISAM/Innodb/TokuDB）等等的源碼學習理解，如果條件允許，可以參考CSV引擎開發自己簡單的存儲引擎來保存一些數據，增強對MySQL的理解；在這個過程，如果自己有興趣，也可以考慮往DBA方向發展。MongoDB層面，可以考慮比如說在寫少讀多的情況開始在線上應用MongoDB，或者是做一些線上的數據分析處理的操作，具體場景可以按照工作來，不過核心是要更好的深入理解RMDBS和NoSQL的不同場景下面的應用，如果條件或者興趣允許，可以開始深入學習一下MongoDB的工作機制。

   4. Redis/Memcached

   在第二階段的基礎上面，能夠更深入的應用和學習。因為Memcached不是特別復雜，建議可以把源碼進行閱讀，特別是內存管理部分，方便深入理解；Redis部分，可以多做一些復雜的數據結構的應用（zset來做排行榜排序操作/事務處理用來保證原子性在秒殺類場景應用之類的使用操作）；多涉及aof等同步機制的學習應用，設計一個高可用的Redis應用架構和集群；建議可以深入的學習一下Redis的源碼，把在第二階段積累的知識都可以應用上，特別可以閱讀一下包括核心事件管理、內存管理、內部核心數據結構等充分學習了解一下。如果興趣允許，可以成為一個Redis方面非常專業的使用者。

   5. PHP

   作為基礎核心技能，我們在第二階段的基礎上面，需要有更深入的學習和應用。從基本代碼應用上面來說，能夠解決在PHP開發中遇到95%的問題，了解大部分PHP的技巧；對大部分的PHP框架能夠迅速在一天內上手使用，並且了解各個主流PHP框架的優缺點，能夠迅速方便項目開發中做技術選型；在配置方面，除了常規第二階段會的知識，會了解一些比較偏門的配置選項（php auto_prepend_file/auto_append_file），包括擴展中的一些復雜高級配置和原理（比如memcached擴展配置中的memcache.hash_strategy、apc擴展配置中的apc.mmap_file_mask/apc.slam_defense/apc.file_update_protection之類的）；對php的工作機制比較了解，包括php-fpm工作機制（比如php-fpm在不同配置機器下面開啟進程數量計算以及原理），對zend引擎有基本熟悉（vm/gc/stream處理），閱讀過基本的PHP內核源碼（或者閱讀過相關文章），對PHP內部機制的大部分核心數據結構（基礎類型/Array/Object）實現有了解，對於核心基礎結構（zval/hashtable/gc）有深入學習了解；能夠進行基本的PHP擴展開發，了解一些擴展開發的中高級知識（minit/rinit等），熟悉php跟apache/nginx不同的通信交互方式細節（mod_php/fastcgi）；除了開發PHP擴展，可以考慮學習開發Zend擴展，從更底層去了解PHP。

   6. C/C++

   在第二階段基礎上面，能夠在C/C++語言方面有更深入的學習了解，能夠完成中小型C/C++系統的開發工作；除了基本第二階段的基礎C/C++語法和數據結構，也能夠學習一些特殊數據結構（b-tree/rb-tree/skiplist/lsm-tree/trie-tree等）方便在特殊工作中需求；在系統編程方面，熟悉多進程、多線程編程；多進程情況下面了解大部分多進程之間的通信方式，能夠靈活選擇通信方式（共享內存/信號量/管道等）；多線程編程能夠良好的解決鎖沖突問題，並且能夠進行多線程程序的開發調試工作；同時對網路編程比較熟悉，了解多進程模型/多線程模型/非同步網路IO模型的差別和選型，熟悉不同非同步網路IO模型的原理和差異（select/poll/epoll/iocp等），並且熟悉常見的非同步框架（ACE/ICE/libev/libevent/libuv/Boost.ASIO等）和使用，如果閑暇也可以看看一些國產自己開發的庫（比如muo）；同時能夠設計好的高並發程序架構（leader-follow/master-worker等）；了解大部分C/C++後端Server開發中的問題（內存管理、日誌列印、高並發、前後端通信協議、服務監控），知道各個後端服務RPC通信問題（struct/http/thirft/protobuf等）；能夠更熟絡的使用GCC和GDB來開發編譯調試程序，在線上程序core掉後能夠迅速追查跟蹤解決問題；通用模塊開發方面，可以積累或者開發一些通用的工具或庫（比如非同步網路框架、日誌庫、內存池、線程池等），不過開發後是否應用要謹慎，省的埋坑去追bug。

   7. 前端

   深入了解HTTP協議（包括各個細致協議特殊協議代碼和背後原因，比如302靜態文件緩存了，502是nginx後面php掛了之類的）；除了之前的前端方面的各種框架應用整合能力，前端方面的學習如果有興趣可以更深入，表現形式是，可以自己開發一些類似jQuery的前端框架，或者開發一個富文本編輯器之類的比較瑣碎考驗JavaScript功力。

   8. 其他領域語言學習

   在基礎的PHP/C/C++語言方面有基本積累，建議在當前階段可以嘗試學習不同的編程語言，看個人興趣愛好，腳本類語言可以學學 Python/Ruby 之類的，函數式編程語言可以試試 Lisp/Haskell/Scala/Erlang 之類的，靜態語言可以試試 Java/Golang，數據統計分析可以了解了解R語言，如果想換個視角做後端業務，可以試試 Node.js還有前面提到的跟Nginx結合的Nginx_Lua等。學習不同的語言主要是提升自己的視野和解決問題手段的差異，比如會了解除了進程/線程，還有輕量級協程；比如在跨機器通信場景下面，Erlang的解決方案簡單的驚人；比如在不想選擇C/C++的情況下，還有類似高效的Erlang/Golang可用等等；主要是提升視野。

   9. 其他專業方向學習

   在本階段裡面，會除了基本的LNMP技能之外，會考慮一些其他領域知識的學習，這些都是可以的，看個人興趣和長期的目標方向。目前情況能夠選擇的領域比較多，比如、雲計算（分布式存儲、分布式計算、虛擬機等），機器學習（數據挖掘、模式識別等，應用到統計、個性化推薦），自然語言處理（中文分詞等），搜索引擎技術、圖形圖像、語音識別等等。除了這些高大上的，也有很多偏工程方面可以學習的地方，比如高性能系統、移動開發（Android/IOS）、計算機安全、嵌入式系統、硬體等方向。

   10. 系統設計

   系統設計在第二階段的基礎之上，能夠應用掌握的經驗技能，設計出比較復雜的中大型系統，能夠解決大部分線上的各種復雜系統的問題，完成類似 瀏覽器 -> CDN -> 負載均衡 ->接入層 -> Nginx+PHP -> 業務緩存 -> 資料庫 -> 各路復雜後端RPC交互（存儲後端、邏輯後端、反作弊後端、外部服務） -> 更多後端 醬紫的復雜業務；能夠支撐每天數千萬到數億流量網站的正常開發維護工作。

㈧ 常用的php環境套件有哪些

護衛神.php套件。可以選擇7個版本。不過他們還有更好的選擇，護衛神.主機大師、護衛神.apache大師，都支持自動安裝PHP+MYSQL，而且支持7個版本的PHP同時使用。

㈨ PHP與Python在多核CPU上的比較

php和python對多核的支持都不太好，程序難以細分。 python可以用多進程來實現多核利用，不過PHP好像沒有辦法。 感覺主流腳本語言中，就nodejs對多核支持最好。