隊列系統(tǒng) 含義：
隊列系統(tǒng) 是一個概念呈昔，雖然現(xiàn)在市面上又不少隊列系統(tǒng)霉囚，但是這些隊列系統(tǒng)都是基于這個概念設(shè)計出來的軟件， 使用 文件 喘鸟，使用 mysql， redis 都能夠?qū)崿F(xiàn)一套隊列系統(tǒng)驻右。
那么在這里 文件 mysql redis 在這里系統(tǒng)里面充當(dāng)?shù)慕巧鞘裁词埠冢渴遣皇谴鎯橘|(zhì)啊堪夭？
隊列系統(tǒng)最主要的目的不是為了存儲數(shù)據(jù)愕把，而是為了異步來處理一些數(shù)據(jù)。
那么也就是說我們存到隊列系統(tǒng)的數(shù)據(jù)是個半成品 森爽，那么按道理來說就需要有另外一個東西來處理存放在隊列的數(shù)據(jù)恨豁。
那么對于我們開發(fā)者而言 有哪些方式來處理我存放在隊列的數(shù)據(jù)呢？
1爬迟、死循環(huán)方式讀取
2圣絮、定時任務(wù)
3、守護進程
php 的運行模式 :
1雕旨、通過 web 請求到 apache/nginx然后到 php 這種單進程的運行模式
2、命令行窗口 使用 php xxx.php的方式來運行 php
顯然處理存放在隊列的數(shù)據(jù)肯定是用第二種模式? 這種模式一般稱之為 cli 模式
例如->發(fā)送短信驗證碼：
用戶點擊按鈕 捧请，php將發(fā)短信的任務(wù)以數(shù)據(jù)的形式存到隊列系統(tǒng)里? 返回給用戶短信發(fā)生成功 凡涩，與此同時另外通過 cli 模式啟動的死循環(huán)的php 腳本運行在服務(wù)器，不停的去隊列系統(tǒng)里看有沒有任務(wù)有沒有任務(wù)疹蛉，如果這個進程發(fā)現(xiàn)隊列系統(tǒng)里投遞任務(wù)了 活箕，就從隊列系統(tǒng)里把任務(wù)拿出來，根據(jù)數(shù)據(jù)的參數(shù)不同去執(zhí)行不同的任務(wù)可款。
目的：
使用隊列系統(tǒng)的目的就在于快速的去處理一個復(fù)雜的任務(wù)育韩，而且這個任務(wù)的處理過程用戶不參與。
這樣就說明闺鲸，我們的隊列系統(tǒng)需要一個很顯著的特質(zhì)就是快筋讨！
雖然 mysql 和文件也是可以實現(xiàn)，但是使用 mysql 的情況下是不是反而增加的 mysql 的負(fù)擔(dān)摸恍？所以大家很容易就想到 redis悉罕，那么用 redis 實現(xiàn)一個隊列系統(tǒng) 確實是我們在開發(fā)過程中常用的一個方式redis有個數(shù)據(jù)存儲的方式叫做 list 這種數(shù)據(jù)結(jié)構(gòu)天生的就是實現(xiàn)了赤屋。
市面上主流的隊列系統(tǒng)：
1.RabbitMQ
這個是現(xiàn)在市面非常主流的消息隊列系統(tǒng)? 跨平臺 最大的優(yōu)點就是健壯，穩(wěn)定壁袄，可靠性高
一般用于比較大型的項目 不過這個消息隊列中間件 有幾個問題：
a类早、運行速度較慢
b、學(xué)習(xí)成本比較高
c嗜逻、對于部署是一個很大的考驗如果各位在開發(fā)過程中對數(shù)據(jù)的可靠性要求比較高涩僻，而且業(yè)務(wù)量很大，可以考慮用RabbitMQ栈顷，而且是支持集群的 就是可以分布式部署的
2.ActiveMQ
也是比較流行的隊列系統(tǒng) 這個最大的好處就是支持事務(wù)
其它的我覺得都比不上RabbitMQ 不推薦各位使用逆日，而且他的速度比RabbitMQ更慢 不過多介紹了
3.RocketMQ
RocketMQ是阿里開源的隊列系統(tǒng) 有 RabbitMQ 和ActiveMQ所有優(yōu)點
速度也是超級快的 而且可靠穩(wěn)定支持事務(wù)支持負(fù)載均衡
但是他有個致命的缺點? 目前沒有開發(fā)出可靠的 php的sdk
也有一個國內(nèi)開源項目的巨大的缺點 就是拉完不管
國內(nèi)的開源項目很多都是 KPI 項目 所以即使他又這么多有點 我還是墻裂不推薦
4.Kafka
Kafka實力非常強 阿里的RocketMQ 就是參考了 Kafka
同樣擁有我剛剛說的這些隊列系統(tǒng)的所有優(yōu)點
不過有兩點可惜
一個就是穩(wěn)定性不如RabbitMQ 還有就是對 php 的支持不是特別友好 當(dāng)然只是不是特別友好而已 還是可以用的
重量級的mq：
剛剛我說的就是重量級的消息隊列中間件 一般用于比較重型的分布式項目中 大概的可以總結(jié)為金融等對事務(wù)性要求很高的，可以考慮RabbitMQ和RocketMQ妨蛹，對性能要求高的可考慮Kafka屏富，以上為
輕量級的 MQ：
redis 就是一個 Laravel4框架里也集成了，比較有名的還有AlphaQ? httpsqs zeromq? 和 beanstalkdAlphaQ? httpsqs zeromq Laravel4框架集成的我都沒有用過蛙卤。
提一下里面的zeromq 這個號稱是史上最快的消息隊列狠半，這個確實速度很快上手也非常簡單，不過他有一個致命的缺點颤难，就是存在里面的數(shù)據(jù)不能持久化 神年，也就是一旦機器宕機 ，里面的數(shù)據(jù)就沒有了行嗤，不建議小白用已日， 但是你想體驗極致的快， 可以試試用他栅屏。
在輕量級的消息隊列里? redis 和 beanstalkd是我墻裂推薦的飘千，特別是beanstalkd、redis 的消息隊適合比較簡單的場景栈雳，因為他沒有 優(yōu)先級 延遲 和 任務(wù)超時重發(fā)的處理辦法护奈，所以大家在做非常簡單的秒殺場景的時候 可以用 redis。
beanstalkd：
beanstalkd是一個高性能哥纫、輕量級的分布式內(nèi)存隊列系統(tǒng)
速度快而且是支持持久化存儲的, 也就是說 ,一旦機器宕機 里面的數(shù)據(jù)是還有保留的霉旗。
beanstalkd的速度是要高于 redis 的而且數(shù)據(jù)的可靠性也是要高于 redis 的beanstalkd的隊列是有優(yōu)先級的 ,也就是是說, 存放到隊列里的數(shù)據(jù)， 不僅是有序的 蛀骇，而且是可以插隊的目前 facebook 和淘寶團隊都在使用厌秒。
Beanstalkd對 php 的支持也是非常友好的。
案例:
1.可以用來處理延時任務(wù)? 舉個例子 大家在應(yīng)用場景中會出現(xiàn)擅憔，xxx 時間不操作就需要把訂單關(guān)閉的場景鸵闪，比如為了不打擾用戶,晚上11點以后的消息系統(tǒng)延遲到第二天10點以后發(fā)送
在這些場景中都是可以使用隊列系統(tǒng)來完成的 而Beanstalk是支持延時任務(wù)的 不需要額外的開發(fā)
2.就是循環(huán)任務(wù)? 比如每天需要給達到某個要求的用戶增加積分
類似這樣的循環(huán)任務(wù)也是可以由隊列系統(tǒng)來完成
3.就是兜底任務(wù) 這個場景就更多了
比如我請求短信發(fā)生失敗以后繼續(xù)嘗試，我剛剛說了Beanstalk是支持超時控制的 那么他支持超時控制就支持異呈钪睿控制岛马，一個請求有失敗的概率棉姐，可以用Beanstalk不斷重試
再比如各位在開發(fā)過程中 特別是支付場景中 都是有回調(diào)的 如果說各位的系統(tǒng)出現(xiàn)網(wǎng)絡(luò)問題或者是其它異常情況 回調(diào)收不到咋辦？也可以用隊列系統(tǒng)來進行兜底
4.定時任務(wù)? 這個不多說和延時任務(wù)一樣 既然可以延時 那么就可以定時
5.就是一般的異步任務(wù)舉例子
比如需要和第三方進行通訊的 短信發(fā)送 等等
比如內(nèi)部系統(tǒng)的調(diào)用啊
比如你是一個接口服務(wù)需要給其他人發(fā)回調(diào)
比如秒殺活動啦逆，一般會因為流量過大伞矩，導(dǎo)致流量暴增，應(yīng)用掛掉,可以先將任務(wù)放到隊列一個個來處理
比如日志的收集等等等 很多場景都可以用到
