中軟卓越php大數(shù)據(jù)課程學(xué)哪些知識(shí)，誰(shuí)說一下。

首先是向了解PHP呢還是大數(shù)據(jù)呢？不過想都拿下的話，不是一朝一夕的，步子邁得太大，不好，技在于精而后于多。

霍邱網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)建站,霍邱網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為霍邱超過千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站建設(shè)要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的霍邱做網(wǎng)站的公司定做！

先說PHP：最基本其實(shí)就是web前端基礎(chǔ)；第二的話包括PHP語(yǔ)言基礎(chǔ)、Ajax、數(shù)據(jù)庫(kù)強(qiáng)化、運(yùn)行環(huán)境及配置、面向?qū)ο驩OADUML等；第三就是主流框架的掌握了，Smarty、PDO等

再說大數(shù)據(jù)：

基礎(chǔ)階段：Linux、Docker、KVM、MySQL基礎(chǔ)、Oracle基礎(chǔ)、MongoDB、redis。

hadoop mapreduce hdfs yarn：hadoop：Hadoop 概念、版本、歷史，HDFS工作原理，YARN介紹及組件介紹。

大數(shù)據(jù)存儲(chǔ)階段：hbase、hive、sqoop。

大數(shù)據(jù)架構(gòu)設(shè)計(jì)階段：Flume分布式、Zookeeper、Kafka。

大數(shù)據(jù)實(shí)時(shí)計(jì)算階段：Mahout、Spark、storm。

大數(shù)據(jù)數(shù)據(jù)采集階段：Python、Scala。

大數(shù)據(jù)商業(yè)實(shí)戰(zhàn)階段：實(shí)操企業(yè)大數(shù)據(jù)處理業(yè)務(wù)場(chǎng)景，分析需求、解決方案實(shí)施，綜合技術(shù)實(shí)戰(zhàn)應(yīng)用。

PHP如何解決網(wǎng)站的大數(shù)據(jù)大流量與高并發(fā)

使用緩存，比如memcache,redis,因?yàn)樗鼈兪窃趦?nèi)存中運(yùn)行，所以處理數(shù)據(jù)，返回?cái)?shù)據(jù)非常快，所以可以應(yīng)對(duì)高并發(fā)。

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

3.分布式，讓多個(gè)訪問分到不同的機(jī)器上去處理，每個(gè)機(jī)器處理的請(qǐng)求就相對(duì)減少了。

簡(jiǎn)單說些常用技術(shù)，負(fù)載均衡，限流，加速器等

PHP-大數(shù)據(jù)量怎么處理優(yōu)化

大數(shù)據(jù)的話可以進(jìn)行以下操作：

減少對(duì)數(shù)據(jù)庫(kù)的讀取，也就是減少調(diào)用數(shù)據(jù)庫(kù)，

進(jìn)行數(shù)據(jù)緩存，

利用數(shù)據(jù)庫(kù)的自身優(yōu)化技術(shù)，如索引等

精確查詢條件，有利于提高查找速度

PHP的算法可以實(shí)現(xiàn)大數(shù)據(jù)分析嗎

1.Bloom filter

適用范圍：可以用來(lái)實(shí)現(xiàn)數(shù)據(jù)字典，進(jìn)行數(shù)據(jù)的判重，或者集合求交集

基本原理及要點(diǎn)：

對(duì)于原理來(lái)說很簡(jiǎn)單，位數(shù)組+k個(gè)獨(dú)立hash函數(shù)。將hash函數(shù)對(duì)應(yīng)的值的位數(shù)組置1，查找時(shí)如果發(fā)現(xiàn)所有hash函數(shù)對(duì)應(yīng)位都是1說明存在，很明顯這個(gè)過程并不保證查找的結(jié)果是100%正確的。同時(shí)也不支持刪除一個(gè)已經(jīng)插入的關(guān)鍵字，因?yàn)樵撽P(guān)鍵字對(duì)應(yīng)的位會(huì)牽動(dòng)到其他的關(guān)鍵字。所以一個(gè)簡(jiǎn)單的改進(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為底的對(duì)數(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è)元素的長(zhǎng)度都是有很多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中的最小值來(lái)近似表示元素的出現(xiàn)頻率。

問題實(shí)例：給你A,B兩個(gè)文件，各存放50億條URL，每條URL占用64字節(jié)，內(nèi)存限制是4G，讓你找出A,B文件共同的URL。如果是三個(gè)乃至n個(gè)文件呢？

根據(jù)這個(gè)問題我們來(lái)計(jì)算下內(nèi)存的占用，4G=2^32大概是40億*8大概是340億，n=50億，如果按出錯(cuò)率0.01算需要的大概是650億個(gè) bit。現(xiàn)在可用的是340億，相差并不多，這樣可能會(huì)使出錯(cuò)率上升些。另外如果這些urlip是一一對(duì)應(yīng)的，就可以轉(zhuǎn)換成ip，則大大簡(jiǎn)單了。

2.Hashing

適用范圍：快速查找，刪除的基本數(shù)據(jù)結(jié)構(gòu)，通常需要總數(shù)據(jù)量可以放入內(nèi)存

基本原理及要點(diǎn)：

hash函數(shù)選擇，針對(duì)字符串，整數(shù)，排列，具體相應(yīng)的hash方法。

碰撞處理，一種是open hashing，也稱為拉鏈法；另一種就是closed hashing，也稱開地址法，opened addressing。 ()

擴(kuò)展：

d-left hashing中的d是多個(gè)的意思，我們先簡(jiǎn)化這個(gè)問題，看一看2-left hashing。2-left hashing指的是將一個(gè)哈希表分成長(zhǎng)度相等的兩半，分別叫做T1和T2，給T1和T2分別配備一個(gè)哈希函數(shù)，h1和h2。在存儲(chǔ)一個(gè)新的key時(shí)，同時(shí)用兩個(gè)哈希函數(shù)進(jìn)行計(jì)算，得出兩個(gè)地址h1[key]和h2[key]。這時(shí)需要檢查T1中的h1[key]位置和T2中的h2[key]位置，哪一個(gè)位置已經(jīng)存儲(chǔ)的（有碰撞的）key比較多，然后將新key存儲(chǔ)在負(fù)載少的位置。如果兩邊一樣多，比如兩個(gè)位置都為空或者都存儲(chǔ)了一個(gè)key，就把新key 存儲(chǔ)在左邊的T1子表中，2-left也由此而來(lái)。在查找一個(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ù)的快速查找，判重，刪除，一般來(lái)說數(shù)據(jù)范圍是int的10倍以下

基本原理及要點(diǎn)：使用bit數(shù)組來(lái)表示某些元素是否存在，比如8位電話號(hào)碼

擴(kuò)展：bloom filter可以看做是對(duì)bit-map的擴(kuò)展

問題實(shí)例：

1)已知某個(gè)文件內(nèi)包含一些電話號(hào)碼，每個(gè)號(hào)碼為8位數(shù)字，統(tǒng)計(jì)不同號(hào)碼的個(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來(lái)進(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é)合，可以用來(lái)維護(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ù)庫(kù)索引

適用范圍：大數(shù)據(jù)量的增刪改查

基本原理及要點(diǎn)：利用數(shù)據(jù)的設(shè)計(jì)實(shí)現(xiàn)方法，對(duì)海量數(shù)據(jù)的增刪改查進(jìn)行處理。

擴(kuò)展：

問題實(shí)例：

7.倒排索引(Inverted index)

適用范圍：搜索引擎，關(guān)鍵字查詢

基本原理及要點(diǎn)：為何叫倒排索引？一種索引方法，被用來(lái)存儲(chǔ)在全文搜索下某個(gè)單詞在一個(gè)文檔或者一組文檔中的存儲(chǔ)位置的映射。

以英文為例，下面是要被索引的文本：

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" 將對(duì)應(yīng)集合的交集。

正向索引開發(fā)出來(lái)用來(lái)存儲(chǔ)每個(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有些不夠，所以可以用來(lái)排序。內(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萬(wàn)字符串，其中有些是相同的(重復(fù)),需要把重復(fù)的全部去掉，保留沒有重復(fù)的字符串。請(qǐng)問怎么設(shè)計(jì)和實(shí)現(xiàn)？

3).尋找熱門查詢：查詢串的重復(fù)度比較高，雖然總數(shù)是1千萬(wàn)，但如果除去重復(fù)后，不超過3百萬(wàn)個(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臺(tái)電腦中，想個(gè)辦法高效統(tǒng)計(jì)出這批數(shù)據(jù)的TOP10。

3).一共有N個(gè)機(jī)器，每個(gè)機(jī)器上有N個(gè)數(shù)。每個(gè)機(jī)器最多存O(N)個(gè)數(shù)并對(duì)它們操作。如何找到N^2個(gè)數(shù)的中數(shù)(median)？

經(jīng)典問題分析

上千萬(wàn)or億數(shù)據(jù)（有重復(fù)），統(tǒng)計(jì)其中出現(xiàn)次數(shù)最多的前N個(gè)數(shù)據(jù),分兩種情況：可一次讀入內(nèi)存，不可一次讀入。

可用思路：trie樹+堆，數(shù)據(jù)庫(kù)索引，劃分子集分別統(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è)堆來(lái)維護(hù)出現(xiàn)次數(shù)最多的前N個(gè)數(shù)據(jù)，當(dāng)然這樣導(dǎo)致維護(hù)次數(shù)增加，不如完全統(tǒng)計(jì)后在求前N大效率高。

如果數(shù)據(jù)無(wú)法放入內(nèi)存。一方面我們可以考慮上面的字典方法能否被改進(jìn)以適應(yīng)這種情形，可以做的改變就是將字典存放到硬盤上，而不是內(nèi)存，這可以參考數(shù)據(jù)庫(kù)的存儲(chǔ)方法。

當(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)行處理，這樣是無(wú)法得到正確的解的。因?yàn)橐粋€(gè)數(shù)據(jù)可能被均分到不同的機(jī)子上，而另一個(gè)則可能完全聚集到一個(gè)機(jī)子上，同時(shí)還可能存在具有相同數(shù)目的數(shù)據(jù)。比如我們要找出現(xiàn)次數(shù)最多的前100個(gè)，我們將1000萬(wàn)的數(shù)據(jù)分布到10臺(tái)機(jī)器上，找到每臺(tái)出現(xiàn)次數(shù)最多的前 100個(gè)，歸并之后這樣不能保證找到真正的第100個(gè)，因?yàn)楸热绯霈F(xiàn)次數(shù)最多的第100個(gè)可能有1萬(wàn)個(gè)，但是它被分到了10臺(tái)機(jī)子，這樣在每臺(tái)上只有1千個(gè)，假設(shè)這些機(jī)子排名在1000個(gè)之前的那些都是單獨(dú)分布在一臺(tái)機(jī)子上的，比如有1001個(gè)，這樣本來(lái)具有1萬(wàn)個(gè)的這個(gè)就會(huì)被淘汰，即使我們讓每臺(tái)機(jī)子選出出現(xiàn)次數(shù)最多的1000個(gè)再歸并，仍然會(huì)出錯(cuò)，因?yàn)榭赡艽嬖诖罅總€(gè)數(shù)為1001個(gè)的發(fā)生聚集。因此不能將數(shù)據(jù)隨便均分到不同機(jī)子上，而是要根據(jù)hash 后的值將它們映射到不同的機(jī)子上處理，讓不同的機(jī)器處理一個(gè)數(shù)值范圍。

而外排序的方法會(huì)消耗大量的IO，效率不會(huì)很高。而上面的分布式方法，也可以用于單機(jī)版本，也就是將總的數(shù)據(jù)根據(jù)值的范圍，劃分成多個(gè)不同的子文件，然后逐個(gè)處理。處理完畢之后再對(duì)這些單詞的及其出現(xiàn)頻率進(jìn)行一個(gè)歸并。實(shí)際上就可以利用一個(gè)外排序的歸并過程。

另外還可以考慮近似計(jì)算，也就是我們可以通過結(jié)合自然語(yǔ)言屬性，只將那些真正實(shí)際中出現(xiàn)最多的那些詞作為一個(gè)字典，使得這個(gè)規(guī)?？梢苑湃雰?nèi)存。

php采集大數(shù)據(jù)的方案

1、建議你讀寫數(shù)據(jù)和下載圖片分開，各用不同的進(jìn)程完成。

比如說，取數(shù)據(jù)用get-data.php，下載圖片用get-image.php。

2、多進(jìn)程的話，php可以簡(jiǎn)單的用pcntl_fork()。這樣可以并發(fā)多個(gè)子進(jìn)程。

但是我不建議你用fork，我建議你安裝一個(gè)gearman worker。這樣你要并發(fā)幾個(gè)，就啟幾個(gè)worker，寫代碼簡(jiǎn)單，根本不用在代碼里考慮thread啊，process等等。

3、綜上，解決方案這樣：

（1）安裝gearman worker。

（2）寫一個(gè)get-data.php，在crontab里設(shè)置它每5分鐘執(zhí)行一次，只負(fù)責(zé)讀數(shù)據(jù)，然后把讀回來(lái)的數(shù)據(jù)一條一條的扔到 gearman worker的隊(duì)列里；

然后再寫一個(gè)處理數(shù)據(jù)的腳本作為worker，例如叫process-data.php，這個(gè)腳本常駐內(nèi)存。它作為worker從geraman 隊(duì)列里讀出一條一條的數(shù)據(jù)，然后跟你的數(shù)據(jù)庫(kù)老數(shù)據(jù)比較，進(jìn)行你的業(yè)務(wù)邏輯。如果你要10個(gè)并發(fā)，那就啟動(dòng)10個(gè)process-data.php好了。處理完后，如果圖片地址有變動(dòng)需要下載圖片，就把圖片地址扔到 gearman worker的另一個(gè)隊(duì)列里。

（3）再寫一個(gè)download-data.php，作為下載圖片的worker，同樣，你啟動(dòng)10個(gè)20個(gè)并發(fā)隨便你。這個(gè)進(jìn)程也常駐內(nèi)存運(yùn)行，從gearman worker的圖片數(shù)據(jù)隊(duì)列里取數(shù)據(jù)出來(lái)，下載圖片

4、常駐進(jìn)程的話，就是在代碼里寫個(gè)while(true)死循環(huán)，讓它一直運(yùn)行好了。如果怕內(nèi)存泄露啥的，你可以每循環(huán)10萬(wàn)次退出一下。然后在crontab里設(shè)置，每分鐘檢查一下進(jìn)程有沒有啟動(dòng)，比如說這樣啟動(dòng)3個(gè)process-data worker進(jìn)程：

* * * * * flock -xn /tmp/process-data.1.lock -c '/usr/bin/php /process-data.php /dev/null 21'

* * * * * flock -xn /tmp/process-data.2.lock -c '/usr/bin/php /process-data.php /dev/null 21'

* * * * * flock -xn /tmp/process-data.3.lock -c '/usr/bin/php /process-data.php /dev/null 21'

不知道你明白了沒有

大型的PHP應(yīng)用，通常使用什么應(yīng)用做消息隊(duì)列？

一、消息隊(duì)列概述\x0d\x0a消息隊(duì)列中間件是分布式系統(tǒng)中重要的組件，主要解決應(yīng)用耦合，異步消息，流量削鋒等問題。實(shí)現(xiàn)高性能，高可用，可伸縮和最終一致性架構(gòu)。是大型分布式系統(tǒng)不可缺少的中間件。\x0d\x0a目前在生產(chǎn)環(huán)境，使用較多的消息隊(duì)列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。\x0d\x0a二、消息隊(duì)列應(yīng)用場(chǎng)景\x0d\x0a以下介紹消息隊(duì)列在實(shí)際應(yīng)用中常用的使用場(chǎng)景。異步處理，應(yīng)用解耦，流量削鋒和消息通訊四個(gè)場(chǎng)景。\x0d\x0a2.1異步處理\x0d\x0a場(chǎng)景說明：用戶注冊(cè)后，需要發(fā)注冊(cè)郵件和注冊(cè)短信。傳統(tǒng)的做法有兩種1.串行的方式；2.并行方式。\x0d\x0a（1）串行方式：將注冊(cè)信息寫入數(shù)據(jù)庫(kù)成功后，發(fā)送注冊(cè)郵件，再發(fā)送注冊(cè)短信。以上三個(gè)任務(wù)全部完成后，返回給客戶端。（架構(gòu)KKQ：466097527，歡迎加入）\x0d\x0a（2）并行方式：將注冊(cè)信息寫入數(shù)據(jù)庫(kù)成功后，發(fā)送注冊(cè)郵件的同時(shí)，發(fā)送注冊(cè)短信。以上三個(gè)任務(wù)完成后，返回給客戶端。與串行的差別是，并行的方式可以提高處理的時(shí)間。\x0d\x0a假設(shè)三個(gè)業(yè)務(wù)節(jié)點(diǎn)每個(gè)使用50毫秒鐘，不考慮網(wǎng)絡(luò)等其他開銷，則串行方式的時(shí)間是150毫秒，并行的時(shí)間可能是100毫秒。\x0d\x0a因?yàn)镃PU在單位時(shí)間內(nèi)處理的請(qǐng)求數(shù)是一定的，假設(shè)CPU1秒內(nèi)吞吐量是100次。則串行方式1秒內(nèi)CPU可處理的請(qǐng)求量是7次（1000/150）。并行方式處理的請(qǐng)求量是10次（1000/100）。\x0d\x0a小結(jié)：如以上案例描述，傳統(tǒng)的方式系統(tǒng)的性能（并發(fā)量，吞吐量，響應(yīng)時(shí)間）會(huì)有瓶頸。如何解決這個(gè)問題呢？\x0d\x0a引入消息隊(duì)列，將不是必須的業(yè)務(wù)邏輯，異步處理。改造后的架構(gòu)如下：\x0d\x0a按照以上約定，用戶的響應(yīng)時(shí)間相當(dāng)于是注冊(cè)信息寫入數(shù)據(jù)庫(kù)的時(shí)間，也就是50毫秒。注冊(cè)郵件，發(fā)送短信寫入消息隊(duì)列后，直接返回，因此寫入消息隊(duì)列的速度很快，基本可以忽略，因此用戶的響應(yīng)時(shí)間可能是50毫秒。因此架構(gòu)改變后，系統(tǒng)的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了兩倍。\x0d\x0a2.2應(yīng)用解耦\x0d\x0a場(chǎng)景說明：用戶下單后，訂單系統(tǒng)需要通知庫(kù)存系統(tǒng)。傳統(tǒng)的做法是，訂單系統(tǒng)調(diào)用庫(kù)存系統(tǒng)的接口。如下圖：\x0d\x0a傳統(tǒng)模式的缺點(diǎn)：\x0d\x0a1） 假如庫(kù)存系統(tǒng)無(wú)法訪問，則訂單減庫(kù)存將失敗，從而導(dǎo)致訂單失敗；\x0d\x0a2） 訂單系統(tǒng)與庫(kù)存系統(tǒng)耦合；\x0d\x0a如何解決以上問題呢？引入應(yīng)用消息隊(duì)列后的方案，如下圖：\x0d\x0a訂單系統(tǒng)：用戶下單后，訂單系統(tǒng)完成持久化處理，將消息寫入消息隊(duì)列，返回用戶訂單下單成功。\x0d\x0a庫(kù)存系統(tǒng)：訂閱下單的消息，采用拉/推的方式，獲取下單信息，庫(kù)存系統(tǒng)根據(jù)下單信息，進(jìn)行庫(kù)存操作。\x0d\x0a假如：在下單時(shí)庫(kù)存系統(tǒng)不能正常使用。也不影響正常下單，因?yàn)橄聠魏?，訂單系統(tǒng)寫入消息隊(duì)列就不再關(guān)心其他的后續(xù)操作了。實(shí)現(xiàn)訂單系統(tǒng)與庫(kù)存系統(tǒng)的應(yīng)用解耦。\x0d\x0a2.3流量削鋒\x0d\x0a流量削鋒也是消息隊(duì)列中的常用場(chǎng)景，一般在秒殺或團(tuán)搶活動(dòng)中使用廣泛。\x0d\x0a應(yīng)用場(chǎng)景：秒殺活動(dòng)，一般會(huì)因?yàn)榱髁窟^大，導(dǎo)致流量暴增，應(yīng)用掛掉。為解決這個(gè)問題，一般需要在應(yīng)用前端加入消息隊(duì)列。\x0d\x0a可以控制活動(dòng)的人數(shù)；\x0d\x0a可以緩解短時(shí)間內(nèi)高流量壓垮應(yīng)用；\x0d\x0a用戶的請(qǐng)求，服務(wù)器接收后，首先寫入消息隊(duì)列。假如消息隊(duì)列長(zhǎng)度超過最大數(shù)量，則直接拋棄用戶請(qǐng)求或跳轉(zhuǎn)到錯(cuò)誤頁(yè)面；\x0d\x0a秒殺業(yè)務(wù)根據(jù)消息隊(duì)列中的請(qǐng)求信息，再做后續(xù)處理。\x0d\x0a2.4日志處理\x0d\x0a日志處理是指將消息隊(duì)列用在日志處理中，比如Kafka的應(yīng)用，解決大量日志傳輸?shù)膯栴}。架構(gòu)簡(jiǎn)化如下：\x0d\x0a日志采集客戶端，負(fù)責(zé)日志數(shù)據(jù)采集，定時(shí)寫受寫入Kafka隊(duì)列；\x0d\x0aKafka消息隊(duì)列，負(fù)責(zé)日志數(shù)據(jù)的接收，存儲(chǔ)和轉(zhuǎn)發(fā)；\x0d\x0a日志處理應(yīng)用：訂閱并消費(fèi)kafka隊(duì)列中的日志數(shù)據(jù)；\x0d\x0a以下是新浪kafka日志處理應(yīng)用案例：\x0d\x0a(1)Kafka：接收用戶日志的消息隊(duì)列。\x0d\x0a(2)Logstash：做日志解析，統(tǒng)一成JSON輸出給Elasticsearch。\x0d\x0a(3)Elasticsearch：實(shí)時(shí)日志分析服務(wù)的核心技術(shù)，一個(gè)schemaless，實(shí)時(shí)的數(shù)據(jù)存儲(chǔ)服務(wù)，通過index組織數(shù)據(jù)，兼具強(qiáng)大的搜索和統(tǒng)計(jì)功能。\x0d\x0a(4)Kibana：基于Elasticsearch的數(shù)據(jù)可視化組件，超強(qiáng)的數(shù)據(jù)可視化能力是眾多公司選擇ELK stack的重要原因。\x0d\x0a2.5消息通訊\x0d\x0a消息通訊是指，消息隊(duì)列一般都內(nèi)置了高效的通信機(jī)制，因此也可以用在純的消息通訊。比如實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)消息隊(duì)列，或者聊天室等。\x0d\x0a點(diǎn)對(duì)點(diǎn)通訊：\x0d\x0a客戶端A和客戶端B使用同一隊(duì)列，進(jìn)行消息通訊。\x0d\x0a聊天室通訊：\x0d\x0a客戶端A，客戶端B，客戶端N訂閱同一主題，進(jìn)行消息發(fā)布和接收。實(shí)現(xiàn)類似聊天室效果。\x0d\x0a以上實(shí)際是消息隊(duì)列的兩種消息模式，點(diǎn)對(duì)點(diǎn)或發(fā)布訂閱模式。模型為示意圖，供參考。\x0d\x0a三、消息中間件示例\x0d\x0a3.1電商系統(tǒng)\x0d\x0a消息隊(duì)列采用高可用，可持久化的消息中間件。比如Active MQ，Rabbit MQ，Rocket Mq。（1）應(yīng)用將主干邏輯處理完成后，寫入消息隊(duì)列。消息發(fā)送是否成功可以開啟消息的確認(rèn)模式。（消息隊(duì)列返回消息接收成功狀態(tài)后，應(yīng)用再返回，這樣保障消息的完整性）\x0d\x0a（2）擴(kuò)展流程（發(fā)短信，配送處理）訂閱隊(duì)列消息。采用推或拉的方式獲取消息并處理。\x0d\x0a（3）消息將應(yīng)用解耦的同時(shí)，帶來(lái)了數(shù)據(jù)一致性問題，可以采用最終一致性方式解決。比如主數(shù)據(jù)寫入數(shù)據(jù)庫(kù)，擴(kuò)展應(yīng)用根據(jù)消息隊(duì)列，并結(jié)合數(shù)據(jù)庫(kù)方式實(shí)現(xiàn)基于消息隊(duì)列的后續(xù)處理。\x0d\x0a3.2日志收集系統(tǒng)\x0d\x0a分為Zookeeper注冊(cè)中心，日志收集客戶端，Kafka集群和Storm集群（OtherApp）四部分組成。\x0d\x0aZookeeper注冊(cè)中心，提出負(fù)載均衡和地址查找服務(wù)；\x0d\x0a日志收集客戶端，用于采集應(yīng)用系統(tǒng)的日志，并將數(shù)據(jù)推送到kafka隊(duì)列；\x0d\x0a四、JMS消息服務(wù)\x0d\x0a講消息隊(duì)列就不得不提JMS 。JMS（Java Message Service,Java消息服務(wù)）API是一個(gè)消息服務(wù)的標(biāo)準(zhǔn)/規(guī)范，允許應(yīng)用程序組件基于JavaEE平臺(tái)創(chuàng)建、發(fā)送、接收和讀取消息。它使分布式通信耦合度更低，消息服務(wù)更加可靠以及異步性。\x0d\x0a在EJB架構(gòu)中，有消息bean可以無(wú)縫的與JM消息服務(wù)集成。在J2EE架構(gòu)模式中，有消息服務(wù)者模式，用于實(shí)現(xiàn)消息與應(yīng)用直接的解耦。\x0d\x0a4.1消息模型\x0d\x0a在JMS標(biāo)準(zhǔn)中，有兩種消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。\x0d\x0a4.1.1 P2P模式\x0d\x0aP2P模式包含三個(gè)角色：消息隊(duì)列（Queue），發(fā)送者(Sender)，接收者(Receiver)。每個(gè)消息都被發(fā)送到一個(gè)特定的隊(duì)列，接收者從隊(duì)列中獲取消息。隊(duì)列保留著消息，直到他們被消費(fèi)或超時(shí)。\x0d\x0aP2P的特點(diǎn)\x0d\x0a每個(gè)消息只有一個(gè)消費(fèi)者（Consumer）(即一旦被消費(fèi)，消息就不再在消息隊(duì)列中)\x0d\x0a發(fā)送者和接收者之間在時(shí)間上沒有依賴性，也就是說當(dāng)發(fā)送者發(fā)送了消息之后，不管接收者有沒有正在運(yùn)行，它不會(huì)影響到消息被發(fā)送到隊(duì)列\(zhòng)x0d\x0a接收者在成功接收消息之后需向隊(duì)列應(yīng)答成功\x0d\x0a如果希望發(fā)送的每個(gè)消息都會(huì)被成功處理的話，那么需要P2P模式。（架構(gòu)KKQ：466097527，歡迎加入）\x0d\x0a4.1.2 Pub/sub模式\x0d\x0a包含三個(gè)角色主題（Topic），發(fā)布者（Publisher），訂閱者（Subscriber） 。多個(gè)發(fā)布者將消息發(fā)送到Topic,系統(tǒng)將這些消息傳遞給多個(gè)訂閱者。\x0d\x0aPub/Sub的特點(diǎn)\x0d\x0a每個(gè)消息可以有多個(gè)消費(fèi)者\(yùn)x0d\x0a發(fā)布者和訂閱者之間有時(shí)間上的依賴性。針對(duì)某個(gè)主題（Topic）的訂閱者，它必須創(chuàng)建一個(gè)訂閱者之后，才能消費(fèi)發(fā)布者的消息。\x0d\x0a為了消費(fèi)消息，訂閱者必須保持運(yùn)行的狀態(tài)。\x0d\x0a為了緩和這樣嚴(yán)格的時(shí)間相關(guān)性，JMS允許訂閱者創(chuàng)建一個(gè)可持久化的訂閱。這樣，即使訂閱者沒有被激活（運(yùn)行），它也能接收到發(fā)布者的消息。\x0d\x0a如果希望發(fā)送的消息可以不被做任何處理、或者只被一個(gè)消息者處理、或者可以被多個(gè)消費(fèi)者處理的話，那么可以采用Pub/Sub模型。\x0d\x0a4.2消息消費(fèi)\x0d\x0a在JMS中，消息的產(chǎn)生和消費(fèi)都是異步的。對(duì)于消費(fèi)來(lái)說，JMS的消息者可以通過兩種方式來(lái)消費(fèi)消息。\x0d\x0a（1）同步\x0d\x0a訂閱者或接收者通過receive方法來(lái)接收消息，receive方法在接收到消息之前（或超時(shí)之前）將一直阻塞；\x0d\x0a（2）異步\x0d\x0a訂閱者或接收者可以注冊(cè)為一個(gè)消息監(jiān)聽器。當(dāng)消息到達(dá)之后，系統(tǒng)自動(dòng)調(diào)用監(jiān)聽器的onMessage方法。\x0d\x0aJNDI：Java命名和目錄接口,是一種標(biāo)準(zhǔn)的Java命名系統(tǒng)接口。可以在網(wǎng)絡(luò)上查找和訪問服務(wù)。通過指定一個(gè)資源名稱，該名稱對(duì)應(yīng)于數(shù)據(jù)庫(kù)或命名服務(wù)中的一個(gè)記錄，同時(shí)返回資源連接建立所必須的信息。\x0d\x0aJNDI在JMS中起到查找和訪問發(fā)送目標(biāo)或消息來(lái)源的作用。（架構(gòu)KKQ：466097527，歡迎加入）\x0d\x0a4.3JMS編程模型\x0d\x0a(1) ConnectionFactory\x0d\x0a創(chuàng)建Connection對(duì)象的工廠，針對(duì)兩種不同的jms消息模型，分別有QueueConnectionFactory和TopicConnectionFactory兩種?？梢酝ㄟ^JNDI來(lái)查找ConnectionFactory對(duì)象。\x0d\x0a(2) Destination\x0d\x0aDestination的意思是消息生產(chǎn)者的消息發(fā)送目標(biāo)或者說消息消費(fèi)者的消息來(lái)源。對(duì)于消息生產(chǎn)者來(lái)說，它的Destination是某個(gè)隊(duì)列（Queue）或某個(gè)主題（Topic）;對(duì)于消息消費(fèi)者來(lái)說，它的Destination也是某個(gè)隊(duì)列或主題（即消息來(lái)源）。\x0d\x0a所以，Destination實(shí)際上就是兩種類型的對(duì)象：Queue、Topic可以通過JNDI來(lái)查找Destination。\x0d\x0a(3) Connection\x0d\x0aConnection表示在客戶端和JMS系統(tǒng)之間建立的鏈接（對(duì)TCP/IP socket的包裝）。Connection可以產(chǎn)生一個(gè)或多個(gè)Session。跟ConnectionFactory一樣，Connection也有兩種類型：QueueConnection和TopicConnection。\x0d\x0a(4) Session\x0d\x0aSession是操作消息的接口?？梢酝ㄟ^session創(chuàng)建生產(chǎn)者、消費(fèi)者、消息等。Session提供了事務(wù)的功能。當(dāng)需要使用session發(fā)送/接收多個(gè)消息時(shí)，可以將這些發(fā)送/接收動(dòng)作放到一個(gè)事務(wù)中。同樣，也分QueueSession和TopicSession。\x0d\x0a(5) 消息的生產(chǎn)者\(yùn)x0d\x0a消息生產(chǎn)者由Session創(chuàng)建，并用于將消息發(fā)送到Destination。同樣，消息生產(chǎn)者分兩種類型：QueueSender和TopicPublisher?？梢哉{(diào)用消息生產(chǎn)者的方法（send或publish方法）發(fā)送消息。\x0d\x0a(6) 消息消費(fèi)者\(yùn)x0d\x0a消息消費(fèi)者由Session創(chuàng)建，用于接收被發(fā)送到Destination的消息。兩種類型：QueueReceiver和TopicSubscriber?？煞謩e通過session的createReceiver(Queue)或createSubscriber(Topic)來(lái)創(chuàng)建。當(dāng)然，也可以session的creatDurableSubscriber方法來(lái)創(chuàng)建持久化的訂閱者。\x0d\x0a(7) MessageListener\x0d\x0a消息監(jiān)聽器。如果注冊(cè)了消息監(jiān)聽器，一旦消息到達(dá)，將自動(dòng)調(diào)用監(jiān)聽器的onMessage方法。EJB中的MDB（Message-Driven Bean）就是一種MessageListener。\x0d\x0a深入學(xué)習(xí)JMS對(duì)掌握J(rèn)AVA架構(gòu)，EJB架構(gòu)有很好的幫助，消息中間件也是大型分布式系統(tǒng)必須的組件。本次分享主要做全局性介紹，具體的深入需要大家學(xué)習(xí)，實(shí)踐，總結(jié)，領(lǐng)會(huì)。\x0d\x0a五、常用消息隊(duì)列\(zhòng)x0d\x0a一般商用的容器，比如WebLogic，JBoss，都支持JMS標(biāo)準(zhǔn)，開發(fā)上很方便。但免費(fèi)的比如Tomcat，Jetty等則需要使用第三方的消息中間件。本部分內(nèi)容介紹常用的消息中間件（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他們的特點(diǎn)。\x0d\x0a5.1 ActiveMQ\x0d\x0aActiveMQ 是Apache出品，最流行的，能力強(qiáng)勁的開源消息總線。ActiveMQ 是一個(gè)完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實(shí)現(xiàn)，盡管JMS規(guī)范出臺(tái)已經(jīng)是很久的事情了，但是JMS在當(dāng)今的J2EE應(yīng)用中間仍然扮演著特殊的地位。\x0d\x0aActiveMQ特性如下：\x0d\x0a⒈ 多種語(yǔ)言和協(xié)議編寫客戶端。語(yǔ)言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應(yīng)用協(xié)議： OpenWire,Stomp REST,WS Notification,XMPP,AMQP\x0d\x0a⒉ 完全支持JMS1.1和J2EE 1.4規(guī)范 （持久化，XA消息，事務(wù))\x0d\x0a⒊ 對(duì)spring的支持，ActiveMQ可以很容易內(nèi)嵌到使用Spring的系統(tǒng)里面去，而且也支持Spring2.0的特性\x0d\x0a⒋ 通過了常見J2EE服務(wù)器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測(cè)試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動(dòng)的部署到任何兼容J2EE 1.4 商業(yè)服務(wù)器上\x0d\x0a⒌ 支持多種傳送協(xié)議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA\x0d\x0a⒍ 支持通過JDBC和journal提供高速的消息持久化\x0d\x0a⒎ 從設(shè)計(jì)上保證了高性能的集群，客戶端-服務(wù)器，點(diǎn)對(duì)點(diǎn)\x0d\x0a⒏ 支持Ajax\x0d\x0a⒐ 支持與Axis的整合\x0d\x0a⒑ 可以很容易得調(diào)用內(nèi)嵌JMS provider，進(jìn)行測(cè)試\x0d\x0a5.2 RabbitMQ\x0d\x0aRabbitMQ是流行的開源消息隊(duì)列系統(tǒng)，用erlang語(yǔ)言開發(fā)。RabbitMQ是AMQP（高級(jí)消息隊(duì)列協(xié)議）的標(biāo)準(zhǔn)實(shí)現(xiàn)。支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用于在分布式系統(tǒng)中存儲(chǔ)轉(zhuǎn)發(fā)消息，在易用性、擴(kuò)展性、高可用性等方面表現(xiàn)不俗。\x0d\x0a幾個(gè)重要概念：\x0d\x0aBroker：簡(jiǎn)單來(lái)說就是消息隊(duì)列服務(wù)器實(shí)體。\x0d\x0aExchange：消息交換機(jī)，它指定消息按什么規(guī)則，路由到哪個(gè)隊(duì)列。\x0d\x0aQueue：消息隊(duì)列載體，每個(gè)消息都會(huì)被投入到一個(gè)或多個(gè)隊(duì)列。\x0d\x0aBinding：綁定，它的作用就是把exchange和queue按照路由規(guī)則綁定起來(lái)。\x0d\x0aRouting Key：路由關(guān)鍵字，exchange根據(jù)這個(gè)關(guān)鍵字進(jìn)行消息投遞。\x0d\x0avhost：虛擬主機(jī)，一個(gè)broker里可以開設(shè)多個(gè)vhost，用作不同用戶的權(quán)限分離。\x0d\x0aproducer：消息生產(chǎn)者，就是投遞消息的程序。\x0d\x0aconsumer：消息消費(fèi)者，就是接受消息的程序。\x0d\x0achannel：消息通道，在客戶端的每個(gè)連接里，可建立多個(gè)channel，每個(gè)channel代表一個(gè)會(huì)話任務(wù)。\x0d\x0a消息隊(duì)列的使用過程，如下：\x0d\x0a（1）客戶端連接到消息隊(duì)列服務(wù)器，打開一個(gè)channel。\x0d\x0a（2）客戶端聲明一個(gè)exchange，并設(shè)置相關(guān)屬性。\x0d\x0a（3）客戶端聲明一個(gè)queue，并設(shè)置相關(guān)屬性。\x0d\x0a（4）客戶端使用routing key，在exchange和queue之間建立好綁定關(guān)系。\x0d\x0a（5）客戶端投遞消息到exchange。\x0d\x0aexchange接收到消息后，就根據(jù)消息的key和已經(jīng)設(shè)置的binding，進(jìn)行消息路由，將消息投遞到一個(gè)或多個(gè)隊(duì)列里。\x0d\x0a5.3 ZeroMQ\x0d\x0a號(hào)稱史上最快的消息隊(duì)列，它實(shí)際類似于Socket的一系列接口，他跟Socket的區(qū)別是：普通的socket是端到端的（1:1的關(guān)系），而ZMQ卻是可以N：M 的關(guān)系，人們對(duì)BSD套接字的了解較多的是點(diǎn)對(duì)點(diǎn)的連接，點(diǎn)對(duì)點(diǎn)連接需要顯式地建立連接、銷毀連接、選擇協(xié)議（TCP/UDP）和處理錯(cuò)誤等，而ZMQ屏蔽了這些細(xì)節(jié)，讓你的網(wǎng)絡(luò)編程更為簡(jiǎn)單。ZMQ用于node與node間的通信，node可以是主機(jī)或者是進(jìn)程。\x0d\x0a引用官方的說法： “ZMQ(以下ZeroMQ簡(jiǎn)稱ZMQ)是一個(gè)簡(jiǎn)單好用的傳輸層，像框架一樣的一個(gè)socket library，他使得Socket編程更加簡(jiǎn)單、簡(jiǎn)潔和性能更高。是一個(gè)消息處理隊(duì)列庫(kù)，可在多個(gè)線程、內(nèi)核和主機(jī)盒之間彈性伸縮。ZMQ的明確目標(biāo)是“成為標(biāo)準(zhǔn)網(wǎng)絡(luò)協(xié)議棧的一部分，之后進(jìn)入Linux內(nèi)核”?，F(xiàn)在還未看到它們的成功。但是，它無(wú)疑是極具前景的、并且是人們更加需要的“傳統(tǒng)”BSD套接字之上的一 層封裝。ZMQ讓編寫高性能網(wǎng)絡(luò)應(yīng)用程序極為簡(jiǎn)單和有趣?！盶x0d\x0a特點(diǎn)是：\x0d\x0a高性能，非持久化；\x0d\x0a跨平臺(tái)：支持Linux、Windows、OS X等。\x0d\x0a多語(yǔ)言支持； C、C++、Java、.NET、Python等30多種開發(fā)語(yǔ)言。\x0d\x0a可單獨(dú)部署或集成到應(yīng)用中使用；\x0d\x0a可作為Socket通信庫(kù)使用。\x0d\x0a與RabbitMQ相比，ZMQ并不像是一個(gè)傳統(tǒng)意義上的消息隊(duì)列服務(wù)器，事實(shí)上，它也根本不是一個(gè)服務(wù)器，更像一個(gè)底層的網(wǎng)絡(luò)通訊庫(kù)，在Socket API之上做了一層封裝，將網(wǎng)絡(luò)通訊、進(jìn)程通訊和線程通訊抽象為統(tǒng)一的API接口。支持“Request-Reply “，”Publisher-Subscriber“，”Parallel Pipeline”三種基本模型和擴(kuò)展模型。\x0d\x0aZeroMQ高性能設(shè)計(jì)要點(diǎn)：\x0d\x0a1、無(wú)鎖的隊(duì)列模型\x0d\x0a對(duì)于跨線程間的交互（用戶端和session）之間的數(shù)據(jù)交換通道pipe，采用無(wú)鎖的隊(duì)列算法CAS；在pipe兩端注冊(cè)有異步事件，在讀或者寫消息到pipe的時(shí)，會(huì)自動(dòng)觸發(fā)讀寫事件。\x0d\x0a2、批量處理的算法\x0d\x0a對(duì)于傳統(tǒng)的消息處理，每個(gè)消息在發(fā)送和接收的時(shí)候，都需要系統(tǒng)的調(diào)用，這樣對(duì)于大量的消息，系統(tǒng)的開銷比較大，zeroMQ對(duì)于批量的消息，進(jìn)行了適應(yīng)性的優(yōu)化，可以批量的接收和發(fā)送消息。\x0d\x0a3、多核下的線程綁定，無(wú)須CPU切換\x0d\x0a區(qū)別于傳統(tǒng)的多線程并發(fā)模式，信號(hào)量或者臨界區(qū)， zeroMQ充分利用多核的優(yōu)勢(shì)，每個(gè)核綁定運(yùn)行一個(gè)工作者線程，避免多線程之間的CPU切換開銷。\x0d\x0a5.4 Kafka\x0d\x0aKafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，它可以處理消費(fèi)者規(guī)模的網(wǎng)站中的所有動(dòng)作流數(shù)據(jù)。 這種動(dòng)作（網(wǎng)頁(yè)瀏覽，搜索和其他用戶的行動(dòng)）是在現(xiàn)代網(wǎng)絡(luò)上的許多社會(huì)功能的一個(gè)關(guān)鍵因素。 這些數(shù)據(jù)通常是由于吞吐量的要求而通過處理日志和日志聚合來(lái)解決。 對(duì)于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實(shí)時(shí)處理的限制，這是一個(gè)可行的解決方案。Kafka的目的是通過Hadoop的并行加載機(jī)制來(lái)統(tǒng)一線上和離線的消息處理，也是為了通過集群機(jī)來(lái)提供實(shí)時(shí)的消費(fèi)。\x0d\x0aKafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，有如下特性：\x0d\x0a通過O(1)的磁盤數(shù)據(jù)結(jié)構(gòu)提供消息的持久化，這種結(jié)構(gòu)對(duì)于即使數(shù)以TB的消息存儲(chǔ)也能夠保持長(zhǎng)時(shí)間的穩(wěn)定性能。（文件追加的方式寫入數(shù)據(jù)，過期的數(shù)據(jù)定期刪除）\x0d\x0a高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒數(shù)百萬(wàn)的消息。\x0d\x0a支持通過Kafka服務(wù)器和消費(fèi)機(jī)集群來(lái)分區(qū)消息。\x0d\x0a支持Hadoop并行數(shù)據(jù)加載。\x0d\x0aKafka相關(guān)概念\x0d\x0aBroker\x0d\x0aKafka集群包含一個(gè)或多個(gè)服務(wù)器，這種服務(wù)器被稱為broker[5]\x0d\x0aTopic\x0d\x0a每條發(fā)布到Kafka集群的消息都有一個(gè)類別，這個(gè)類別被稱為Topic。（物理上不同Topic的消息分開存儲(chǔ)，邏輯上一個(gè)Topic的消息雖然保存于一個(gè)或多個(gè)broker上但用戶只需指定消息的Topic即可生產(chǎn)或消費(fèi)數(shù)據(jù)而不必關(guān)心數(shù)據(jù)存于何處）\x0d\x0aPartition\x0d\x0aParition是物理上的概念，每個(gè)Topic包含一個(gè)或多個(gè)Partition.\x0d\x0aProducer\x0d\x0a負(fù)責(zé)發(fā)布消息到Kafka broker\x0d\x0aConsumer\x0d\x0a消息消費(fèi)者，向Kafka broker讀取消息的客戶端。\x0d\x0aConsumer Group\x0d\x0a每個(gè)Consumer屬于一個(gè)特定的Consumer Group（可為每個(gè)Consumer指定group name，若不指定group name則屬于默認(rèn)的group）。\x0d\x0a一般應(yīng)用在大數(shù)據(jù)日志處理或?qū)?shí)時(shí)性（少量延遲），可靠性（少量丟數(shù)據(jù)）要求稍低的場(chǎng)景使用。