分享一個(gè)高手的解釋，化抽象為具體，化繁為簡，牛逼牛逼
[消息隊(duì)列的使用場景是怎樣的？ - 祁達(dá)方的回答 - 知乎]
(https://www.zhihu.com/question/34243607/answer/140732170)
Why MQ
1. 降低代碼的耦合性
作為消息的生產(chǎn)者，只需要關(guān)心消息如何被生產(chǎn)，而不必關(guān)心這個(gè)消息如何被消費(fèi)，被誰消費(fèi)。消費(fèi)者與生產(chǎn)者各自實(shí)現(xiàn)各自的接口。（這里有個(gè)詞很有意思：fire and forget，這個(gè)詞是從導(dǎo)彈行業(yè)引進(jìn)來的，直譯為“射后不管”，是不是很污，用在這里，代表生產(chǎn)者生產(chǎn)完數(shù)據(jù)之后就不用管了）
2. 易擴(kuò)展
因?yàn)榻档土笋詈闲裕砸讛U(kuò)展，很容易調(diào)整消息的入隊(duì)和處理的頻率
3. 消息安全傳輸
消息隊(duì)列把數(shù)據(jù)進(jìn)行持久化直到它們已經(jīng)被完全處理，通過這一方式規(guī)避了數(shù)據(jù)丟失風(fēng)險(xiǎn)。許多消息隊(duì)列所采用的"插入-獲取-刪除"范式中，在把一個(gè)消息從隊(duì)列中刪除之前，需要你的處理系統(tǒng)明確的指出該消息已經(jīng)被處理完畢，從而確保你的數(shù)據(jù)被安全的保存直到你使用完畢。
4. 異步通信
很多時(shí)候，用戶不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制，允許用戶把一個(gè)消息放入隊(duì)列，但并不立即處理它。想向隊(duì)列中放入多少消息就放多少，然后在需要的時(shí)候再去處理它們。
消息隊(duì)列中的數(shù)據(jù)需要在多個(gè)系統(tǒng)間共享數(shù)據(jù)才能發(fā)揮價(jià)值。這點(diǎn)對分布式系統(tǒng)異常重要。
RabbitMQ VS Redis
RabbitMQ
RabbitMQ是使用Erlang編寫的一個(gè)開源的消息隊(duì)列，本身支持很多的協(xié)議：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量級，更適合于企業(yè)級的開發(fā)。同時(shí)實(shí)現(xiàn)了Broker構(gòu)架，這意味著消息在發(fā)送給客戶端時(shí)先在中心隊(duì)列排隊(duì)。對路由，負(fù)載均衡或者數(shù)據(jù)持久化都有很好的支持。
Redis
Redis是一個(gè)基于Key-Value對的NoSQL數(shù)據(jù)庫，開發(fā)維護(hù)很活躍。雖然它是一個(gè)Key-Value數(shù)據(jù)庫存儲系統(tǒng)，但它本身支持MQ功能，所以完全可以當(dāng)做一個(gè)輕量級的隊(duì)列服務(wù)來使用。對于RabbitMQ和Redis的入隊(duì)和出隊(duì)操作，各執(zhí)行100萬次，每10萬次記錄一次執(zhí)行時(shí)間。測試數(shù)據(jù)分為128Bytes、512Bytes、1K和10K四個(gè)不同大小的數(shù)據(jù)。實(shí)驗(yàn)表明：入隊(duì)時(shí)，當(dāng)數(shù)據(jù)比較小時(shí)Redis的性能要高于RabbitMQ，而如果數(shù)據(jù)大小超過了10K，Redis則慢的無法忍受；出隊(duì)時(shí)，無論數(shù)據(jù)大小，Redis都表現(xiàn)出非常好的性能，而RabbitMQ的出隊(duì)性能則遠(yuǎn)低于Redis。
