在php編程中，對于一些訪問沒有明顯錯(cuò)誤提示的php頁面，可以通過error_log來做進(jìn)一步的判定。
創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括象山網(wǎng)站建設(shè)、象山網(wǎng)站制作、象山網(wǎng)頁制作以及象山網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，象山網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到象山省份的部分城市，未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
但出于種種原因，有些服務(wù)器并沒有開啟PHP的error_log功能。
測試或其它需要時(shí)，可以打開一下，方法如下。
編輯php.ini，將log_errors設(shè)置為on：
log_errors = On
然后，重啟apache即可。
如成功開啟，就可以跟蹤到對應(yīng)的錯(cuò)誤提示：
[Mon Sep 24 16:57:01 2012] [error] [client 218.5.80.210] PHP Warning: fsockopen() has been disabled for security reasons in /home/bccgi-bin/fsockopen.php on line 2
[Mon Sep 24 16:57:02 2012] [error] [client 218.5.80.210] PHP Warning: fsockopen() has been disabled for security reasons in /home/bccgi-bin/fsockopen.php on line 2
[Mon Sep 24 16:57:03 2012] [error] [client 218.5.80.210] PHP Warning: fsockopen() has been disabled for security reasons in /home/bccgi-bin/fsockopen.php on line 2
[Mon Sep 24 16:57:04 2012] [error] [client 218.5.80.210] PHP Warning: fsockopen() has been disabled for security reasons in /home/bccgi-bin/fsockopen.php on line
另外，注意在Windows環(huán)境下，除了將log_errors設(shè)置為on外，還需要定義error_log的路徑及文件名：
error_log = d:/temp/error.log
（此目錄需要授予php標(biāo)識用戶的修改權(quán)限，否則日志文件無法生成）
IIS沒有error_log的概念，所以需要另外定義。
所謂的日志就是記錄系統(tǒng)運(yùn)行狀態(tài)的數(shù)據(jù)。
一般是將信息記錄到文本文件或數(shù)據(jù)庫中。
比如：
?php
function writeLog($msg){
$logFile = date('Y-m-d').'.txt';
$msg = date('Y-m-d H:i:s').' '.$msg."\r\n";
file_put_contents($logFile,$msg,FILE_APPEND );
}
//調(diào)用上面的函數(shù)，寫一條信息進(jìn)日志文件
writeLog('這是測試日志信息');
?
一、消息隊(duì)列概述
消息隊(duì)列中間件是分布式系統(tǒng)中重要的組件，主要解決應(yīng)用耦合，異步消息，流量削鋒等問題。實(shí)現(xiàn)高性能，高可用，可伸縮和最終一致性架構(gòu)。是大型分布式系統(tǒng)不可缺少的中間件。
目前在生產(chǎn)環(huán)境，使用較多的消息隊(duì)列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。
二、消息隊(duì)列應(yīng)用場景
以下介紹消息隊(duì)列在實(shí)際應(yīng)用中常用的使用場景。異步處理，應(yīng)用解耦，流量削鋒和消息通訊四個(gè)場景。
2.1異步處理
場景說明：用戶注冊后，需要發(fā)注冊郵件和注冊短信。傳統(tǒng)的做法有兩種1.串行的方式；2.并行方式。
（1）串行方式：將注冊信息寫入數(shù)據(jù)庫成功后，發(fā)送注冊郵件，再發(fā)送注冊短信。以上三個(gè)任務(wù)全部完成后，返回給客戶端。（架構(gòu)KKQ：466097527，歡迎加入）
（2）并行方式：將注冊信息寫入數(shù)據(jù)庫成功后，發(fā)送注冊郵件的同時(shí)，發(fā)送注冊短信。以上三個(gè)任務(wù)完成后，返回給客戶端。與串行的差別是，并行的方式可以提高處理的時(shí)間。
假設(shè)三個(gè)業(yè)務(wù)節(jié)點(diǎn)每個(gè)使用50毫秒鐘，不考慮網(wǎng)絡(luò)等其他開銷，則串行方式的時(shí)間是150毫秒，并行的時(shí)間可能是100毫秒。
因?yàn)镃PU在單位時(shí)間內(nèi)處理的請求數(shù)是一定的，假設(shè)CPU1秒內(nèi)吞吐量是100次。則串行方式1秒內(nèi)CPU可處理的請求量是7次（1000/150）。并行方式處理的請求量是10次（1000/100）。
小結(jié)：如以上案例描述，傳統(tǒng)的方式系統(tǒng)的性能（并發(fā)量，吞吐量，響應(yīng)時(shí)間）會有瓶頸。如何解決這個(gè)問題呢？
引入消息隊(duì)列，將不是必須的業(yè)務(wù)邏輯，異步處理。改造后的架構(gòu)如下：
按照以上約定，用戶的響應(yīng)時(shí)間相當(dāng)于是注冊信息寫入數(shù)據(jù)庫的時(shí)間，也就是50毫秒。注冊郵件，發(fā)送短信寫入消息隊(duì)列后，直接返回，因此寫入消息隊(duì)列的速度很快，基本可以忽略，因此用戶的響應(yīng)時(shí)間可能是50毫秒。因此架構(gòu)改變后，系統(tǒng)的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了兩倍。
2.2應(yīng)用解耦
場景說明：用戶下單后，訂單系統(tǒng)需要通知庫存系統(tǒng)。傳統(tǒng)的做法是，訂單系統(tǒng)調(diào)用庫存系統(tǒng)的接口。如下圖：
傳統(tǒng)模式的缺點(diǎn)：
1） 假如庫存系統(tǒng)無法訪問，則訂單減庫存將失敗，從而導(dǎo)致訂單失?。?/p>
2） 訂單系統(tǒng)與庫存系統(tǒng)耦合；
如何解決以上問題呢？引入應(yīng)用消息隊(duì)列后的方案，如下圖：
訂單系統(tǒng)：用戶下單后，訂單系統(tǒng)完成持久化處理，將消息寫入消息隊(duì)列，返回用戶訂單下單成功。
庫存系統(tǒng)：訂閱下單的消息，采用拉/推的方式，獲取下單信息，庫存系統(tǒng)根據(jù)下單信息，進(jìn)行庫存操作。
假如：在下單時(shí)庫存系統(tǒng)不能正常使用。也不影響正常下單，因?yàn)橄聠魏螅唵蜗到y(tǒng)寫入消息隊(duì)列就不再關(guān)心其他的后續(xù)操作了。實(shí)現(xiàn)訂單系統(tǒng)與庫存系統(tǒng)的應(yīng)用解耦。
2.3流量削鋒
流量削鋒也是消息隊(duì)列中的常用場景，一般在秒殺或團(tuán)搶活動中使用廣泛。
應(yīng)用場景：秒殺活動，一般會因?yàn)榱髁窟^大，導(dǎo)致流量暴增，應(yīng)用掛掉。為解決這個(gè)問題，一般需要在應(yīng)用前端加入消息隊(duì)列。
可以控制活動的人數(shù)；
可以緩解短時(shí)間內(nèi)高流量壓垮應(yīng)用；
用戶的請求，服務(wù)器接收后，首先寫入消息隊(duì)列。假如消息隊(duì)列長度超過最大數(shù)量，則直接拋棄用戶請求或跳轉(zhuǎn)到錯(cuò)誤頁面；
秒殺業(yè)務(wù)根據(jù)消息隊(duì)列中的請求信息，再做后續(xù)處理。
2.4日志處理
日志處理是指將消息隊(duì)列用在日志處理中，比如Kafka的應(yīng)用，解決大量日志傳輸?shù)膯栴}。架構(gòu)簡化如下：
日志采集客戶端，負(fù)責(zé)日志數(shù)據(jù)采集，定時(shí)寫受寫入Kafka隊(duì)列；
Kafka消息隊(duì)列，負(fù)責(zé)日志數(shù)據(jù)的接收，存儲和轉(zhuǎn)發(fā)；
日志處理應(yīng)用：訂閱并消費(fèi)kafka隊(duì)列中的日志數(shù)據(jù)；
以下是新浪kafka日志處理應(yīng)用案例：
(1)Kafka：接收用戶日志的消息隊(duì)列。
(2)Logstash：做日志解析，統(tǒng)一成JSON輸出給Elasticsearch。
(3)Elasticsearch：實(shí)時(shí)日志分析服務(wù)的核心技術(shù)，一個(gè)schemaless，實(shí)時(shí)的數(shù)據(jù)存儲服務(wù)，通過index組織數(shù)據(jù)，兼具強(qiáng)大的搜索和統(tǒng)計(jì)功能。
(4)Kibana：基于Elasticsearch的數(shù)據(jù)可視化組件，超強(qiáng)的數(shù)據(jù)可視化能力是眾多公司選擇ELK stack的重要原因。
2.5消息通訊
消息通訊是指，消息隊(duì)列一般都內(nèi)置了高效的通信機(jī)制，因此也可以用在純的消息通訊。比如實(shí)現(xiàn)點(diǎn)對點(diǎn)消息隊(duì)列，或者聊天室等。
點(diǎn)對點(diǎn)通訊：
客戶端A和客戶端B使用同一隊(duì)列，進(jìn)行消息通訊。
聊天室通訊：
客戶端A，客戶端B，客戶端N訂閱同一主題，進(jìn)行消息發(fā)布和接收。實(shí)現(xiàn)類似聊天室效果。
以上實(shí)際是消息隊(duì)列的兩種消息模式，點(diǎn)對點(diǎn)或發(fā)布訂閱模式。模型為示意圖，供參考。
三、消息中間件示例
3.1電商系統(tǒng)
消息隊(duì)列采用高可用，可持久化的消息中間件。比如Active MQ，Rabbit MQ，Rocket Mq。（1）應(yīng)用將主干邏輯處理完成后，寫入消息隊(duì)列。消息發(fā)送是否成功可以開啟消息的確認(rèn)模式。（消息隊(duì)列返回消息接收成功狀態(tài)后，應(yīng)用再返回，這樣保障消息的完整性）
（2）擴(kuò)展流程（發(fā)短信，配送處理）訂閱隊(duì)列消息。采用推或拉的方式獲取消息并處理。
（3）消息將應(yīng)用解耦的同時(shí)，帶來了數(shù)據(jù)一致性問題，可以采用最終一致性方式解決。比如主數(shù)據(jù)寫入數(shù)據(jù)庫，擴(kuò)展應(yīng)用根據(jù)消息隊(duì)列，并結(jié)合數(shù)據(jù)庫方式實(shí)現(xiàn)基于消息隊(duì)列的后續(xù)處理。
3.2日志收集系統(tǒng)
分為Zookeeper注冊中心，日志收集客戶端，Kafka集群和Storm集群（OtherApp）四部分組成。
Zookeeper注冊中心，提出負(fù)載均衡和地址查找服務(wù)；
日志收集客戶端，用于采集應(yīng)用系統(tǒng)的日志，并將數(shù)據(jù)推送到kafka隊(duì)列；
四、JMS消息服務(wù)
講消息隊(duì)列就不得不提JMS 。JMS（Java Message Service,Java消息服務(wù)）API是一個(gè)消息服務(wù)的標(biāo)準(zhǔn)/規(guī)范，允許應(yīng)用程序組件基于JavaEE平臺創(chuàng)建、發(fā)送、接收和讀取消息。它使分布式通信耦合度更低，消息服務(wù)更加可靠以及異步性。
在EJB架構(gòu)中，有消息bean可以無縫的與JM消息服務(wù)集成。在J2EE架構(gòu)模式中，有消息服務(wù)者模式，用于實(shí)現(xiàn)消息與應(yīng)用直接的解耦。
4.1消息模型
在JMS標(biāo)準(zhǔn)中，有兩種消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。
4.1.1 P2P模式
P2P模式包含三個(gè)角色：消息隊(duì)列（Queue），發(fā)送者(Sender)，接收者(Receiver)。每個(gè)消息都被發(fā)送到一個(gè)特定的隊(duì)列，接收者從隊(duì)列中獲取消息。隊(duì)列保留著消息，直到他們被消費(fèi)或超時(shí)。
P2P的特點(diǎn)
每個(gè)消息只有一個(gè)消費(fèi)者（Consumer）(即一旦被消費(fèi)，消息就不再在消息隊(duì)列中)
發(fā)送者和接收者之間在時(shí)間上沒有依賴性，也就是說當(dāng)發(fā)送者發(fā)送了消息之后，不管接收者有沒有正在運(yùn)行，它不會影響到消息被發(fā)送到隊(duì)列
接收者在成功接收消息之后需向隊(duì)列應(yīng)答成功
如果希望發(fā)送的每個(gè)消息都會被成功處理的話，那么需要P2P模式。（架構(gòu)KKQ：466097527，歡迎加入）
4.1.2 Pub/sub模式
包含三個(gè)角色主題（Topic），發(fā)布者（Publisher），訂閱者（Subscriber） 。多個(gè)發(fā)布者將消息發(fā)送到Topic,系統(tǒng)將這些消息傳遞給多個(gè)訂閱者。
Pub/Sub的特點(diǎn)
每個(gè)消息可以有多個(gè)消費(fèi)者
發(fā)布者和訂閱者之間有時(shí)間上的依賴性。針對某個(gè)主題（Topic）的訂閱者，它必須創(chuàng)建一個(gè)訂閱者之后，才能消費(fèi)發(fā)布者的消息。
為了消費(fèi)消息，訂閱者必須保持運(yùn)行的狀態(tài)。
為了緩和這樣嚴(yán)格的時(shí)間相關(guān)性，JMS允許訂閱者創(chuàng)建一個(gè)可持久化的訂閱。這樣，即使訂閱者沒有被激活（運(yùn)行），它也能接收到發(fā)布者的消息。
如果希望發(fā)送的消息可以不被做任何處理、或者只被一個(gè)消息者處理、或者可以被多個(gè)消費(fèi)者處理的話，那么可以采用Pub/Sub模型。
4.2消息消費(fèi)
在JMS中，消息的產(chǎn)生和消費(fèi)都是異步的。對于消費(fèi)來說，JMS的消息者可以通過兩種方式來消費(fèi)消息。
（1）同步
訂閱者或接收者通過receive方法來接收消息，receive方法在接收到消息之前（或超時(shí)之前）將一直阻塞；
（2）異步
訂閱者或接收者可以注冊為一個(gè)消息監(jiān)聽器。當(dāng)消息到達(dá)之后，系統(tǒng)自動調(diào)用監(jiān)聽器的onMessage方法。
JNDI：Java命名和目錄接口,是一種標(biāo)準(zhǔn)的Java命名系統(tǒng)接口。可以在網(wǎng)絡(luò)上查找和訪問服務(wù)。通過指定一個(gè)資源名稱，該名稱對應(yīng)于數(shù)據(jù)庫或命名服務(wù)中的一個(gè)記錄，同時(shí)返回資源連接建立所必須的信息。
JNDI在JMS中起到查找和訪問發(fā)送目標(biāo)或消息來源的作用。（架構(gòu)KKQ：466097527，歡迎加入）
4.3JMS編程模型
(1) ConnectionFactory
創(chuàng)建Connection對象的工廠，針對兩種不同的jms消息模型，分別有QueueConnectionFactory和TopicConnectionFactory兩種?？梢酝ㄟ^JNDI來查找ConnectionFactory對象。
(2) Destination
Destination的意思是消息生產(chǎn)者的消息發(fā)送目標(biāo)或者說消息消費(fèi)者的消息來源。對于消息生產(chǎn)者來說，它的Destination是某個(gè)隊(duì)列（Queue）或某個(gè)主題（Topic）;對于消息消費(fèi)者來說，它的Destination也是某個(gè)隊(duì)列或主題（即消息來源）。
所以，Destination實(shí)際上就是兩種類型的對象：Queue、Topic可以通過JNDI來查找Destination。
(3) Connection
Connection表示在客戶端和JMS系統(tǒng)之間建立的鏈接（對TCP/IP socket的包裝）。Connection可以產(chǎn)生一個(gè)或多個(gè)Session。跟ConnectionFactory一樣，Connection也有兩種類型：QueueConnection和TopicConnection。
(4) Session
Session是操作消息的接口。可以通過session創(chuàng)建生產(chǎn)者、消費(fèi)者、消息等。Session提供了事務(wù)的功能。當(dāng)需要使用session發(fā)送/接收多個(gè)消息時(shí)，可以將這些發(fā)送/接收動作放到一個(gè)事務(wù)中。同樣，也分QueueSession和TopicSession。
(5) 消息的生產(chǎn)者
消息生產(chǎn)者由Session創(chuàng)建，并用于將消息發(fā)送到Destination。同樣，消息生產(chǎn)者分兩種類型：QueueSender和TopicPublisher?？梢哉{(diào)用消息生產(chǎn)者的方法（send或publish方法）發(fā)送消息。
(6) 消息消費(fèi)者
消息消費(fèi)者由Session創(chuàng)建，用于接收被發(fā)送到Destination的消息。兩種類型：QueueReceiver和TopicSubscriber?？煞謩e通過session的createReceiver(Queue)或createSubscriber(Topic)來創(chuàng)建。當(dāng)然，也可以session的creatDurableSubscriber方法來創(chuàng)建持久化的訂閱者。
(7) MessageListener
消息監(jiān)聽器。如果注冊了消息監(jiān)聽器，一旦消息到達(dá)，將自動調(diào)用監(jiān)聽器的onMessage方法。EJB中的MDB（Message-Driven Bean）就是一種MessageListener。
深入學(xué)習(xí)JMS對掌握J(rèn)AVA架構(gòu)，EJB架構(gòu)有很好的幫助，消息中間件也是大型分布式系統(tǒng)必須的組件。本次分享主要做全局性介紹，具體的深入需要大家學(xué)習(xí)，實(shí)踐，總結(jié)，領(lǐng)會。
五、常用消息隊(duì)列
一般商用的容器，比如WebLogic，JBoss，都支持JMS標(biāo)準(zhǔn)，開發(fā)上很方便。但免費(fèi)的比如Tomcat，Jetty等則需要使用第三方的消息中間件。本部分內(nèi)容介紹常用的消息中間件（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他們的特點(diǎn)。
5.1 ActiveMQ
ActiveMQ 是Apache出品，最流行的，能力強(qiáng)勁的開源消息總線。ActiveMQ 是一個(gè)完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實(shí)現(xiàn)，盡管JMS規(guī)范出臺已經(jīng)是很久的事情了，但是JMS在當(dāng)今的J2EE應(yīng)用中間仍然扮演著特殊的地位。
ActiveMQ特性如下：
⒈ 多種語言和協(xié)議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應(yīng)用協(xié)議： OpenWire,Stomp REST,WS Notification,XMPP,AMQP
⒉ 完全支持JMS1.1和J2EE 1.4規(guī)范 （持久化，XA消息，事務(wù))
⒊ 對spring的支持，ActiveMQ可以很容易內(nèi)嵌到使用Spring的系統(tǒng)里面去，而且也支持Spring2.0的特性
⒋ 通過了常見J2EE服務(wù)器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業(yè)服務(wù)器上
⒌ 支持多種傳送協(xié)議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
⒍ 支持通過JDBC和journal提供高速的消息持久化
⒎ 從設(shè)計(jì)上保證了高性能的集群，客戶端-服務(wù)器，點(diǎn)對點(diǎn)
⒏ 支持Ajax
⒐ 支持與Axis的整合
⒑ 可以很容易得調(diào)用內(nèi)嵌JMS provider，進(jìn)行測試
5.2 RabbitMQ
RabbitMQ是流行的開源消息隊(duì)列系統(tǒng)，用erlang語言開發(fā)。RabbitMQ是AMQP（高級消息隊(duì)列協(xié)議）的標(biāo)準(zhǔn)實(shí)現(xiàn)。支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用于在分布式系統(tǒng)中存儲轉(zhuǎn)發(fā)消息，在易用性、擴(kuò)展性、高可用性等方面表現(xiàn)不俗。
幾個(gè)重要概念：
Broker：簡單來說就是消息隊(duì)列服務(wù)器實(shí)體。
Exchange：消息交換機(jī)，它指定消息按什么規(guī)則，路由到哪個(gè)隊(duì)列。
Queue：消息隊(duì)列載體，每個(gè)消息都會被投入到一個(gè)或多個(gè)隊(duì)列。
Binding：綁定，它的作用就是把exchange和queue按照路由規(guī)則綁定起來。
Routing Key：路由關(guān)鍵字，exchange根據(jù)這個(gè)關(guān)鍵字進(jìn)行消息投遞。
vhost：虛擬主機(jī)，一個(gè)broker里可以開設(shè)多個(gè)vhost，用作不同用戶的權(quán)限分離。
producer：消息生產(chǎn)者，就是投遞消息的程序。
consumer：消息消費(fèi)者，就是接受消息的程序。
channel：消息通道，在客戶端的每個(gè)連接里，可建立多個(gè)channel，每個(gè)channel代表一個(gè)會話任務(wù)。
消息隊(duì)列的使用過程，如下：
（1）客戶端連接到消息隊(duì)列服務(wù)器，打開一個(gè)channel。
（2）客戶端聲明一個(gè)exchange，并設(shè)置相關(guān)屬性。
（3）客戶端聲明一個(gè)queue，并設(shè)置相關(guān)屬性。
（4）客戶端使用routing key，在exchange和queue之間建立好綁定關(guān)系。
（5）客戶端投遞消息到exchange。
exchange接收到消息后，就根據(jù)消息的key和已經(jīng)設(shè)置的binding，進(jìn)行消息路由，將消息投遞到一個(gè)或多個(gè)隊(duì)列里。
5.3 ZeroMQ
號稱史上最快的消息隊(duì)列，它實(shí)際類似于Socket的一系列接口，他跟Socket的區(qū)別是：普通的socket是端到端的（1:1的關(guān)系），而ZMQ卻是可以N：M 的關(guān)系，人們對BSD套接字的了解較多的是點(diǎn)對點(diǎn)的連接，點(diǎn)對點(diǎn)連接需要顯式地建立連接、銷毀連接、選擇協(xié)議（TCP/UDP）和處理錯(cuò)誤等，而ZMQ屏蔽了這些細(xì)節(jié)，讓你的網(wǎng)絡(luò)編程更為簡單。ZMQ用于node與node間的通信，node可以是主機(jī)或者是進(jìn)程。
引用官方的說法： “ZMQ(以下ZeroMQ簡稱ZMQ)是一個(gè)簡單好用的傳輸層，像框架一樣的一個(gè)socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個(gè)消息處理隊(duì)列庫，可在多個(gè)線程、內(nèi)核和主機(jī)盒之間彈性伸縮。ZMQ的明確目標(biāo)是“成為標(biāo)準(zhǔn)網(wǎng)絡(luò)協(xié)議棧的一部分，之后進(jìn)入Linux內(nèi)核”?，F(xiàn)在還未看到它們的成功。但是，它無疑是極具前景的、并且是人們更加需要的“傳統(tǒng)”BSD套接字之上的一 層封裝。ZMQ讓編寫高性能網(wǎng)絡(luò)應(yīng)用程序極為簡單和有趣?！?/p>
特點(diǎn)是：
高性能，非持久化；
跨平臺：支持Linux、Windows、OS X等。
多語言支持； C、C++、Java、.NET、Python等30多種開發(fā)語言。
可單獨(dú)部署或集成到應(yīng)用中使用；
可作為Socket通信庫使用。
與RabbitMQ相比，ZMQ并不像是一個(gè)傳統(tǒng)意義上的消息隊(duì)列服務(wù)器，事實(shí)上，它也根本不是一個(gè)服務(wù)器，更像一個(gè)底層的網(wǎng)絡(luò)通訊庫，在Socket API之上做了一層封裝，將網(wǎng)絡(luò)通訊、進(jìn)程通訊和線程通訊抽象為統(tǒng)一的API接口。支持“Request-Reply “，”Publisher-Subscriber“，”Parallel Pipeline”三種基本模型和擴(kuò)展模型。
ZeroMQ高性能設(shè)計(jì)要點(diǎn)：
1、無鎖的隊(duì)列模型
對于跨線程間的交互（用戶端和session）之間的數(shù)據(jù)交換通道pipe，采用無鎖的隊(duì)列算法CAS；在pipe兩端注冊有異步事件，在讀或者寫消息到pipe的時(shí)，會自動觸發(fā)讀寫事件。
2、批量處理的算法
對于傳統(tǒng)的消息處理，每個(gè)消息在發(fā)送和接收的時(shí)候，都需要系統(tǒng)的調(diào)用，這樣對于大量的消息，系統(tǒng)的開銷比較大，zeroMQ對于批量的消息，進(jìn)行了適應(yīng)性的優(yōu)化，可以批量的接收和發(fā)送消息。
3、多核下的線程綁定，無須CPU切換
區(qū)別于傳統(tǒng)的多線程并發(fā)模式，信號量或者臨界區(qū)， zeroMQ充分利用多核的優(yōu)勢，每個(gè)核綁定運(yùn)行一個(gè)工作者線程，避免多線程之間的CPU切換開銷。
5.4 Kafka
Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，它可以處理消費(fèi)者規(guī)模的網(wǎng)站中的所有動作流數(shù)據(jù)。 這種動作（網(wǎng)頁瀏覽，搜索和其他用戶的行動）是在現(xiàn)代網(wǎng)絡(luò)上的許多社會功能的一個(gè)關(guān)鍵因素。 這些數(shù)據(jù)通常是由于吞吐量的要求而通過處理日志和日志聚合來解決。 對于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實(shí)時(shí)處理的限制，這是一個(gè)可行的解決方案。Kafka的目的是通過Hadoop的并行加載機(jī)制來統(tǒng)一線上和離線的消息處理，也是為了通過集群機(jī)來提供實(shí)時(shí)的消費(fèi)。
Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，有如下特性：
通過O(1)的磁盤數(shù)據(jù)結(jié)構(gòu)提供消息的持久化，這種結(jié)構(gòu)對于即使數(shù)以TB的消息存儲也能夠保持長時(shí)間的穩(wěn)定性能。（文件追加的方式寫入數(shù)據(jù)，過期的數(shù)據(jù)定期刪除）
高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒數(shù)百萬的消息。
支持通過Kafka服務(wù)器和消費(fèi)機(jī)集群來分區(qū)消息。
支持Hadoop并行數(shù)據(jù)加載。
Kafka相關(guān)概念
Broker
Kafka集群包含一個(gè)或多個(gè)服務(wù)器，這種服務(wù)器被稱為broker[5]
Topic
每條發(fā)布到Kafka集群的消息都有一個(gè)類別，這個(gè)類別被稱為Topic。（物理上不同Topic的消息分開存儲，邏輯上一個(gè)Topic的消息雖然保存于一個(gè)或多個(gè)broker上但用戶只需指定消息的Topic即可生產(chǎn)或消費(fèi)數(shù)據(jù)而不必關(guān)心數(shù)據(jù)存于何處）
Partition
Parition是物理上的概念，每個(gè)Topic包含一個(gè)或多個(gè)Partition.
Producer
負(fù)責(zé)發(fā)布消息到Kafka broker
Consumer
消息消費(fèi)者，向Kafka broker讀取消息的客戶端。
Consumer Group
每個(gè)Consumer屬于一個(gè)特定的Consumer Group（可為每個(gè)Consumer指定group name，若不指定group name則屬于默認(rèn)的group）。
一般應(yīng)用在大數(shù)據(jù)日志處理或?qū)?shí)時(shí)性（少量延遲），可靠性（少量丟數(shù)據(jù)）要求稍低的場景使用。
下面是基本的步驟：
1 使用mysqldump命令將InnoDB數(shù)據(jù)庫導(dǎo)出
2 停止MySQL
3 刪除所有InnoDB數(shù)據(jù)庫文件和日志
4 啟動MySQL并自動重建InnoDB數(shù)據(jù)庫文件和日志文件
5 導(dǎo)入前面?zhèn)浞莸臄?shù)據(jù)庫文件還有什么疑問的話可以多去后盾們看一些相關(guān)的視頻，這樣你可以更加清楚。
1.Bloom filter
適用范圍：可以用來實(shí)現(xiàn)數(shù)據(jù)字典，進(jìn)行數(shù)據(jù)的判重，或者集合求交集
基本原理及要點(diǎn)：
對于原理來說很簡單，位數(shù)組+k個(gè)獨(dú)立hash函數(shù)。將hash函數(shù)對應(yīng)的值的位數(shù)組置1，查找時(shí)如果發(fā)現(xiàn)所有hash函數(shù)對應(yīng)位都是1說明存在，很明顯這個(gè)過程并不保證查找的結(jié)果是100%正確的。同時(shí)也不支持刪除一個(gè)已經(jīng)插入的關(guān)鍵字，因?yàn)樵撽P(guān)鍵字對應(yīng)的位會牽動到其他的關(guān)鍵字。所以一個(gè)簡單的改進(jìn)就是 counting Bloom filter，用一個(gè)counter數(shù)組代替位數(shù)組，就可以支持刪除了。
還有一個(gè)比較重要的問題，如何根據(jù)輸入元素個(gè)數(shù)n，確定位數(shù)組m的大小及hash函數(shù)個(gè)數(shù)。當(dāng)hash函數(shù)個(gè)數(shù)k=(ln2)*(m/n)時(shí)錯(cuò)誤率最小。在錯(cuò)誤率不大于E的情況下，m至少要等于n*lg(1/E)才能表示任意n個(gè)元素的集合。但m還應(yīng)該更大些，因?yàn)檫€要保證bit數(shù)組里至少一半為 0，則m 應(yīng)該=nlg(1/E)*lge 大概就是nlg(1/E)1.44倍(lg表示以2為底的對數(shù))。
舉個(gè)例子我們假設(shè)錯(cuò)誤率為0.01，則此時(shí)m應(yīng)大概是n的13倍。這樣k大概是8個(gè)。
注意這里m與n的單位不同，m是bit為單位，而n則是以元素個(gè)數(shù)為單位(準(zhǔn)確的說是不同元素的個(gè)數(shù))。通常單個(gè)元素的長度都是有很多bit的。所以使用bloom filter內(nèi)存上通常都是節(jié)省的。
擴(kuò)展：
Bloom filter將集合中的元素映射到位數(shù)組中，用k（k為哈希函數(shù)個(gè)數(shù)）個(gè)映射位是否全1表示元素在不在這個(gè)集合中。Counting bloom filter（CBF）將位數(shù)組中的每一位擴(kuò)展為一個(gè)counter，從而支持了元素的刪除操作。Spectral Bloom Filter（SBF）將其與集合元素的出現(xiàn)次數(shù)關(guān)聯(lián)。SBF采用counter中的最小值來近似表示元素的出現(xiàn)頻率。
問題實(shí)例：給你A,B兩個(gè)文件，各存放50億條URL，每條URL占用64字節(jié)，內(nèi)存限制是4G，讓你找出A,B文件共同的URL。如果是三個(gè)乃至n個(gè)文件呢？
根據(jù)這個(gè)問題我們來計(jì)算下內(nèi)存的占用，4G=2^32大概是40億*8大概是340億，n=50億，如果按出錯(cuò)率0.01算需要的大概是650億個(gè) bit?，F(xiàn)在可用的是340億，相差并不多，這樣可能會使出錯(cuò)率上升些。另外如果這些urlip是一一對應(yīng)的，就可以轉(zhuǎn)換成ip，則大大簡單了。
2.Hashing
適用范圍：快速查找，刪除的基本數(shù)據(jù)結(jié)構(gòu)，通常需要總數(shù)據(jù)量可以放入內(nèi)存
基本原理及要點(diǎn)：
hash函數(shù)選擇，針對字符串，整數(shù)，排列，具體相應(yīng)的hash方法。
碰撞處理，一種是open hashing，也稱為拉鏈法；另一種就是closed hashing，也稱開地址法，opened addressing。 ()
擴(kuò)展：
d-left hashing中的d是多個(gè)的意思，我們先簡化這個(gè)問題，看一看2-left hashing。2-left hashing指的是將一個(gè)哈希表分成長度相等的兩半，分別叫做T1和T2，給T1和T2分別配備一個(gè)哈希函數(shù)，h1和h2。在存儲一個(gè)新的key時(shí)，同時(shí)用兩個(gè)哈希函數(shù)進(jìn)行計(jì)算，得出兩個(gè)地址h1[key]和h2[key]。這時(shí)需要檢查T1中的h1[key]位置和T2中的h2[key]位置，哪一個(gè)位置已經(jīng)存儲的（有碰撞的）key比較多，然后將新key存儲在負(fù)載少的位置。如果兩邊一樣多，比如兩個(gè)位置都為空或者都存儲了一個(gè)key，就把新key 存儲在左邊的T1子表中，2-left也由此而來。在查找一個(gè)key時(shí)，必須進(jìn)行兩次hash，同時(shí)查找兩個(gè)位置。
問題實(shí)例：
1).海量日志數(shù)據(jù)，提取出某日訪問百度次數(shù)最多的那個(gè)IP。
IP的數(shù)目還是有限的，最多2^32個(gè)，所以可以考慮使用hash將ip直接存入內(nèi)存，然后進(jìn)行統(tǒng)計(jì)。
3.bit-map
適用范圍：可進(jìn)行數(shù)據(jù)的快速查找，判重，刪除，一般來說數(shù)據(jù)范圍是int的10倍以下
基本原理及要點(diǎn)：使用bit數(shù)組來表示某些元素是否存在，比如8位電話號碼
擴(kuò)展：bloom filter可以看做是對bit-map的擴(kuò)展
問題實(shí)例：
1)已知某個(gè)文件內(nèi)包含一些電話號碼，每個(gè)號碼為8位數(shù)字，統(tǒng)計(jì)不同號碼的個(gè)數(shù)。
8位最多99 999 999，大概需要99m個(gè)bit，大概10幾m字節(jié)的內(nèi)存即可。
2)2.5億個(gè)整數(shù)中找出不重復(fù)的整數(shù)的個(gè)數(shù)，內(nèi)存空間不足以容納這2.5億個(gè)整數(shù)。
將bit-map擴(kuò)展一下，用2bit表示一個(gè)數(shù)即可，0表示未出現(xiàn)，1表示出現(xiàn)一次，2表示出現(xiàn)2次及以上?；蛘呶覀儾挥?bit來進(jìn)行表示，我們用兩個(gè)bit-map即可模擬實(shí)現(xiàn)這個(gè)2bit-map。
4.堆
適用范圍：海量數(shù)據(jù)前n大，并且n比較小，堆可以放入內(nèi)存
基本原理及要點(diǎn)：最大堆求前n小，最小堆求前n大。方法，比如求前n小，我們比較當(dāng)前元素與最大堆里的最大元素，如果它小于最大元素，則應(yīng)該替換那個(gè)最大元素。這樣最后得到的n個(gè)元素就是最小的n個(gè)。適合大數(shù)據(jù)量，求前n小，n的大小比較小的情況，這樣可以掃描一遍即可得到所有的前n元素，效率很高。
擴(kuò)展：雙堆，一個(gè)最大堆與一個(gè)最小堆結(jié)合，可以用來維護(hù)中位數(shù)。
問題實(shí)例：
1)100w個(gè)數(shù)中找最大的前100個(gè)數(shù)。
用一個(gè)100個(gè)元素大小的最小堆即可。
5.雙層桶劃分 ----其實(shí)本質(zhì)上就是【分而治之】的思想，重在“分”的技巧上！
適用范圍：第k大，中位數(shù)，不重復(fù)或重復(fù)的數(shù)字
基本原理及要點(diǎn)：因?yàn)樵胤秶艽?，不能利用直接尋址表，所以通過多次劃分，逐步確定范圍，然后最后在一個(gè)可以接受的范圍內(nèi)進(jìn)行?？梢酝ㄟ^多次縮小，雙層只是一個(gè)例子。
擴(kuò)展：
問題實(shí)例：
1).2.5億個(gè)整數(shù)中找出不重復(fù)的整數(shù)的個(gè)數(shù)，內(nèi)存空間不足以容納這2.5億個(gè)整數(shù)。
有點(diǎn)像鴿巢原理，整數(shù)個(gè)數(shù)為2^32,也就是，我們可以將這2^32個(gè)數(shù)，劃分為2^8個(gè)區(qū)域(比如用單個(gè)文件代表一個(gè)區(qū)域)，然后將數(shù)據(jù)分離到不同的區(qū)域，然后不同的區(qū)域在利用bitmap就可以直接解決了。也就是說只要有足夠的磁盤空間，就可以很方便的解決。
2).5億個(gè)int找它們的中位數(shù)。
這個(gè)例子比上面那個(gè)更明顯。首先我們將int劃分為2^16個(gè)區(qū)域，然后讀取數(shù)據(jù)統(tǒng)計(jì)落到各個(gè)區(qū)域里的數(shù)的個(gè)數(shù)，之后我們根據(jù)統(tǒng)計(jì)結(jié)果就可以判斷中位數(shù)落到那個(gè)區(qū)域，同時(shí)知道這個(gè)區(qū)域中的第幾大數(shù)剛好是中位數(shù)。然后第二次掃描我們只統(tǒng)計(jì)落在這個(gè)區(qū)域中的那些數(shù)就可以了。
實(shí)際上，如果不是int是int64，我們可以經(jīng)過3次這樣的劃分即可降低到可以接受的程度。即可以先將int64分成2^24個(gè)區(qū)域，然后確定區(qū)域的第幾大數(shù)，在將該區(qū)域分成2^20個(gè)子區(qū)域，然后確定是子區(qū)域的第幾大數(shù)，然后子區(qū)域里的數(shù)的個(gè)數(shù)只有2^20，就可以直接利用direct addr table進(jìn)行統(tǒng)計(jì)了。
6.數(shù)據(jù)庫索引
適用范圍：大數(shù)據(jù)量的增刪改查
基本原理及要點(diǎn)：利用數(shù)據(jù)的設(shè)計(jì)實(shí)現(xiàn)方法，對海量數(shù)據(jù)的增刪改查進(jìn)行處理。
擴(kuò)展：
問題實(shí)例：
7.倒排索引(Inverted index)
適用范圍：搜索引擎，關(guān)鍵字查詢
基本原理及要點(diǎn)：為何叫倒排索引？一種索引方法，被用來存儲在全文搜索下某個(gè)單詞在一個(gè)文檔或者一組文檔中的存儲位置的映射。
以英文為例，下面是要被索引的文本：
T0 = "it is what it is"
T1 = "what is it"
T2 = "it is a banana"
我們就能得到下面的反向文件索引：
"a": {2}
"banana": {2}
"is": {0, 1, 2}
"it": {0, 1, 2}
"what": {0, 1}
檢索的條件"what", "is" 和 "it" 將對應(yīng)集合的交集。
正向索引開發(fā)出來用來存儲每個(gè)文檔的單詞的列表。正向索引的查詢往往滿足每個(gè)文檔有序頻繁的全文查詢和每個(gè)單詞在校驗(yàn)文檔中的驗(yàn)證這樣的查詢。在正向索引中，文檔占據(jù)了中心的位置，每個(gè)文檔指向了一個(gè)它所包含的索引項(xiàng)的序列。也就是說文檔指向了它包含的那些單詞，而反向索引則是單詞指向了包含它的文檔，很容易看到這個(gè)反向的關(guān)系。
擴(kuò)展：
問題實(shí)例：文檔檢索系統(tǒng)，查詢那些文件包含了某單詞，比如常見的學(xué)術(shù)論文的關(guān)鍵字搜索。
8.外排序
適用范圍：大數(shù)據(jù)的排序，去重
基本原理及要點(diǎn)：外排序的歸并方法，置換選擇 敗者樹原理，最優(yōu)歸并樹
擴(kuò)展：
問題實(shí)例：
1).有一個(gè)1G大小的一個(gè)文件，里面每一行是一個(gè)詞，詞的大小不超過16個(gè)字節(jié)，內(nèi)存限制大小是1M。返回頻數(shù)最高的100個(gè)詞。
這個(gè)數(shù)據(jù)具有很明顯的特點(diǎn)，詞的大小為16個(gè)字節(jié)，但是內(nèi)存只有1m做hash有些不夠，所以可以用來排序。內(nèi)存可以當(dāng)輸入緩沖區(qū)使用。
9.trie樹
適用范圍：數(shù)據(jù)量大，重復(fù)多，但是數(shù)據(jù)種類小可以放入內(nèi)存
基本原理及要點(diǎn)：實(shí)現(xiàn)方式，節(jié)點(diǎn)孩子的表示方式
擴(kuò)展：壓縮實(shí)現(xiàn)。
問題實(shí)例：
1).有10個(gè)文件，每個(gè)文件1G， 每個(gè)文件的每一行都存放的是用戶的query，每個(gè)文件的query都可能重復(fù)。要你按照query的頻度排序 。
2).1000萬字符串，其中有些是相同的(重復(fù)),需要把重復(fù)的全部去掉，保留沒有重復(fù)的字符串。請問怎么設(shè)計(jì)和實(shí)現(xiàn)？
3).尋找熱門查詢：查詢串的重復(fù)度比較高，雖然總數(shù)是1千萬，但如果除去重復(fù)后，不超過3百萬個(gè)，每個(gè)不超過255字節(jié)。
10.分布式處理 mapreduce
適用范圍：數(shù)據(jù)量大，但是數(shù)據(jù)種類小可以放入內(nèi)存
基本原理及要點(diǎn)：將數(shù)據(jù)交給不同的機(jī)器去處理，數(shù)據(jù)劃分，結(jié)果歸約。
擴(kuò)展：
問題實(shí)例：
1).The canonical example application of MapReduce is a process to count the appearances of
each different word in a set of documents:
void map(String name, String document):
// name: document name
// document: document contents
for each word w in document:
EmitIntermediate(w, 1);
void reduce(String word, Iterator partialCounts):
// key: a word
// values: a list of aggregated partial counts
int result = 0;
for each v in partialCounts:
result += ParseInt(v);
Emit(result);
Here, each document is split in words, and each word is counted initially with a "1" value by
the Map function, using the word as the result key. The framework puts together all the pairs
with the same key and feeds them to the same call to Reduce, thus this function just needs to
sum all of its input values to find the total appearances of that word.
2).海量數(shù)據(jù)分布在100臺電腦中，想個(gè)辦法高效統(tǒng)計(jì)出這批數(shù)據(jù)的TOP10。
3).一共有N個(gè)機(jī)器，每個(gè)機(jī)器上有N個(gè)數(shù)。每個(gè)機(jī)器最多存O(N)個(gè)數(shù)并對它們操作。如何找到N^2個(gè)數(shù)的中數(shù)(median)？
經(jīng)典問題分析
上千萬or億數(shù)據(jù)（有重復(fù)），統(tǒng)計(jì)其中出現(xiàn)次數(shù)最多的前N個(gè)數(shù)據(jù),分兩種情況：可一次讀入內(nèi)存，不可一次讀入。
可用思路：trie樹+堆，數(shù)據(jù)庫索引，劃分子集分別統(tǒng)計(jì)，hash，分布式計(jì)算，近似統(tǒng)計(jì)，外排序
所謂的是否能一次讀入內(nèi)存，實(shí)際上應(yīng)該指去除重復(fù)后的數(shù)據(jù)量。如果去重后數(shù)據(jù)可以放入內(nèi)存，我們可以為數(shù)據(jù)建立字典，比如通過 map，hashmap，trie，然后直接進(jìn)行統(tǒng)計(jì)即可。當(dāng)然在更新每條數(shù)據(jù)的出現(xiàn)次數(shù)的時(shí)候，我們可以利用一個(gè)堆來維護(hù)出現(xiàn)次數(shù)最多的前N個(gè)數(shù)據(jù)，當(dāng)然這樣導(dǎo)致維護(hù)次數(shù)增加，不如完全統(tǒng)計(jì)后在求前N大效率高。
如果數(shù)據(jù)無法放入內(nèi)存。一方面我們可以考慮上面的字典方法能否被改進(jìn)以適應(yīng)這種情形，可以做的改變就是將字典存放到硬盤上，而不是內(nèi)存，這可以參考數(shù)據(jù)庫的存儲方法。
當(dāng)然還有更好的方法，就是可以采用分布式計(jì)算，基本上就是map-reduce過程，首先可以根據(jù)數(shù)據(jù)值或者把數(shù)據(jù)hash(md5)后的值，將數(shù)據(jù)按照范圍劃分到不同的機(jī)子，最好可以讓數(shù)據(jù)劃分后可以一次讀入內(nèi)存，這樣不同的機(jī)子負(fù)責(zé)處理各種的數(shù)值范圍，實(shí)際上就是map。得到結(jié)果后，各個(gè)機(jī)子只需拿出各自的出現(xiàn)次數(shù)最多的前N個(gè)數(shù)據(jù)，然后匯總，選出所有的數(shù)據(jù)中出現(xiàn)次數(shù)最多的前N個(gè)數(shù)據(jù)，這實(shí)際上就是reduce過程。
實(shí)際上可能想直接將數(shù)據(jù)均分到不同的機(jī)子上進(jìn)行處理，這樣是無法得到正確的解的。因?yàn)橐粋€(gè)數(shù)據(jù)可能被均分到不同的機(jī)子上，而另一個(gè)則可能完全聚集到一個(gè)機(jī)子上，同時(shí)還可能存在具有相同數(shù)目的數(shù)據(jù)。比如我們要找出現(xiàn)次數(shù)最多的前100個(gè)，我們將1000萬的數(shù)據(jù)分布到10臺機(jī)器上，找到每臺出現(xiàn)次數(shù)最多的前 100個(gè)，歸并之后這樣不能保證找到真正的第100個(gè)，因?yàn)楸热绯霈F(xiàn)次數(shù)最多的第100個(gè)可能有1萬個(gè)，但是它被分到了10臺機(jī)子，這樣在每臺上只有1千個(gè)，假設(shè)這些機(jī)子排名在1000個(gè)之前的那些都是單獨(dú)分布在一臺機(jī)子上的，比如有1001個(gè)，這樣本來具有1萬個(gè)的這個(gè)就會被淘汰，即使我們讓每臺機(jī)子選出出現(xiàn)次數(shù)最多的1000個(gè)再歸并，仍然會出錯(cuò)，因?yàn)榭赡艽嬖诖罅總€(gè)數(shù)為1001個(gè)的發(fā)生聚集。因此不能將數(shù)據(jù)隨便均分到不同機(jī)子上，而是要根據(jù)hash 后的值將它們映射到不同的機(jī)子上處理，讓不同的機(jī)器處理一個(gè)數(shù)值范圍。
而外排序的方法會消耗大量的IO，效率不會很高。而上面的分布式方法，也可以用于單機(jī)版本，也就是將總的數(shù)據(jù)根據(jù)值的范圍，劃分成多個(gè)不同的子文件，然后逐個(gè)處理。處理完畢之后再對這些單詞的及其出現(xiàn)頻率進(jìn)行一個(gè)歸并。實(shí)際上就可以利用一個(gè)外排序的歸并過程。
另外還可以考慮近似計(jì)算，也就是我們可以通過結(jié)合自然語言屬性，只將那些真正實(shí)際中出現(xiàn)最多的那些詞作為一個(gè)字典，使得這個(gè)規(guī)模可以放入內(nèi)存。
重慶分公司
重慶分公司
