以下是本消息隊(duì)列系列文章的傳送門：
1. 什么是消息隊(duì)列
隊(duì)列相信大家應(yīng)該都不陌生，它是一種先進(jìn)先出的數(shù)據(jù)結(jié)構(gòu)，基本結(jié)構(gòu)如下圖。
在java中已經(jīng)實(shí)現(xiàn)了各種各樣的隊(duì)列了，那為什么還需要消息隊(duì)列MQ（Message Queue）這種中間件呢？我們可以先嘗試思考一下消息隊(duì)列存在的意義，它能滿足我們項(xiàng)目中的什么需求，下面我會(huì)繼續(xù)補(bǔ)充。
消息隊(duì)列可以簡(jiǎn)單理解為，我們把想要傳輸?shù)臄?shù)據(jù)放到隊(duì)列中（其結(jié)構(gòu)與普通隊(duì)列是一樣的）
我們將把數(shù)據(jù)放入到隊(duì)列的那一方叫做生產(chǎn)者；將從消息隊(duì)列中取數(shù)據(jù)的一方叫做消費(fèi)者。
2. 為什么要使用消息隊(duì)列
以下我將通過幾個(gè)簡(jiǎn)單的場(chǎng)景來簡(jiǎn)單說明我們?yōu)槭裁词褂孟㈥?duì)列。
2.1 解耦
假設(shè)我們現(xiàn)在有一個(gè)環(huán)境數(shù)據(jù)生成系統(tǒng)A，系統(tǒng)A通過調(diào)用系統(tǒng)B和系統(tǒng)C的接口來向系統(tǒng)B、C來發(fā)送數(shù)據(jù)，場(chǎng)景一圖如下：
即系統(tǒng)A在有新的環(huán)境數(shù)據(jù)生成時(shí)，會(huì)通過調(diào)用B、C系統(tǒng)的接口來將生成的數(shù)據(jù)發(fā)送給B、C。寫成偽代碼如下所示（此處不考慮用觀察者模式實(shí)現(xiàn)解耦并實(shí)時(shí)通知觀察者的情況）：
public class SystemA {
// 系統(tǒng)B和系統(tǒng)C的依賴
SystemB systemB = new SystemB();
SystemC systemC = new SystemC();
// 系統(tǒng)A獨(dú)有的數(shù)據(jù)
private String environmentData= "data";
public void doSomething() {
// 通過調(diào)用接口發(fā)送數(shù)據(jù)
systemB.SystemBNeed2do(environmentData);
systemC.SystemCNeed2do(environmentData);
}
}
這種情況下，會(huì)有以下問題：
- 如果某一天系統(tǒng)B不需要這些數(shù)據(jù)了，讓系統(tǒng)A的負(fù)責(zé)人將發(fā)送數(shù)據(jù)給他們的那一部分代碼給改了，即注釋掉
systemB.SystemBNeed2do(environmentData);； - 有新的系統(tǒng)D需要這些數(shù)據(jù)了，需要增加調(diào)用D系統(tǒng)接口來發(fā)送數(shù)據(jù)的代碼；
- 同時(shí)，系統(tǒng)A還需要考慮如果其余系統(tǒng)B、C、D的系統(tǒng)如果掛了怎么辦，要不要重發(fā)。
從上面的場(chǎng)景可以發(fā)現(xiàn)，系統(tǒng)A與其他三個(gè)系統(tǒng)高度耦合了。我們?cè)囅肴缦聢?chǎng)景二，系統(tǒng)A將最新的環(huán)境數(shù)據(jù)信息放到MQ中，哪個(gè)系統(tǒng)需要就可以訂閱這個(gè)消息消費(fèi)。如果某個(gè)系統(tǒng)不需要這些數(shù)據(jù)了，就取消對(duì)MQ消息的消費(fèi)即可。這種場(chǎng)景下，A系統(tǒng)完全不需要去考慮將數(shù)據(jù)發(fā)送給誰，也不需要去維護(hù)之前發(fā)送數(shù)據(jù)的代碼，不需要考慮其他系統(tǒng)是否調(diào)用成功、失敗超時(shí)等情況。
小結(jié)：
通過這種模式消息發(fā)布與訂閱的模式，使得系統(tǒng)A與其他系統(tǒng)解耦。
2.2 異步
其實(shí)我仔細(xì)斟酌了一下異步與解耦的場(chǎng)景，發(fā)現(xiàn)其實(shí)異步與解耦是有一定關(guān)系的，我們使用同樣的場(chǎng)景，只是我們考慮的面不同，場(chǎng)景三如下圖所示。但我們現(xiàn)在考慮的面是時(shí)間效率。
假設(shè)系統(tǒng)A產(chǎn)生環(huán)境數(shù)據(jù)需要100ms，調(diào)用系統(tǒng)B、C、D的接口分別需要300ms、300ms、300ms，那么在類似場(chǎng)景一的設(shè)計(jì)方式時(shí)，這次請(qǐng)求所需要耗費(fèi)的時(shí)間為100+300+300+300 = 1000ms = 1s。請(qǐng)求會(huì)隨著需要環(huán)境數(shù)據(jù)的系統(tǒng)越來越多而使得請(qǐng)求響應(yīng)越來越慢，這是用戶不能忍受的，即類似我們?nèi)フ?qǐng)求一個(gè)系統(tǒng)服務(wù)，我們主要想要的服務(wù)只是系統(tǒng)A生成的環(huán)境數(shù)據(jù)服務(wù)，而系統(tǒng)A這個(gè)時(shí)候卻因?yàn)槠渌到y(tǒng)調(diào)用而使得這個(gè)服務(wù)請(qǐng)求響應(yīng)過慢。
而如果是類似于如下場(chǎng)景時(shí)，我們的響應(yīng)時(shí)間僅僅是產(chǎn)生消息的時(shí)間100ms。
小結(jié)：
- 同步場(chǎng)景下，整個(gè)請(qǐng)求需要耗時(shí)1s；
- 異步場(chǎng)景下，請(qǐng)求只需要100ms。
2.3 削峰/限流
我們接著考慮如下場(chǎng)景，假設(shè)我們的系統(tǒng)A有個(gè)促銷功能，大促銷期間并發(fā)量較大，我們假設(shè)每秒可能有5k個(gè)請(qǐng)求。如下圖。
一般的MySQL，每秒能處理2k個(gè)請(qǐng)求就差不多了，如果每秒5k個(gè)請(qǐng)求同時(shí)處理的話，可能會(huì)導(dǎo)致MySQL不可用，導(dǎo)致整個(gè)系統(tǒng)崩潰，用戶也就沒法使用MySQL了。但一過了促銷期，每秒請(qǐng)求只有百來個(gè)，這個(gè)時(shí)候?qū)ο到y(tǒng)幾乎沒有任何壓力。
如果使用MQ，每秒5k個(gè)請(qǐng)求寫入MQ，A系統(tǒng)可以根據(jù)自身的處理能力來決定每秒拉取的請(qǐng)求數(shù)。這樣下來，在高峰期時(shí)系統(tǒng)A也不會(huì)掛掉。
這個(gè)短暫的高峰期積壓是完全OK的。（消息隊(duì)列是支持吞高吐量的，為此不用擔(dān)心這個(gè)量的問題，同樣，我們可以暫不考慮MQ掛掉的情況）。
系統(tǒng)A按照它能處理的速率來處理請(qǐng)求。
小結(jié)：
通過將請(qǐng)求放在支持高吞吐量的MQ中來到達(dá)削峰/限流的效果。
2.4 其它應(yīng)用場(chǎng)景
- 日志處理：將大量日志存儲(chǔ)到消息隊(duì)列中（一般采用分布式消息隊(duì)列kafka），解決大量日志傳輸?shù)膯栴}。其中，消息隊(duì)列負(fù)責(zé)日志數(shù)據(jù)的接收，存儲(chǔ)和轉(zhuǎn)發(fā)；
- 消息通訊：點(diǎn)對(duì)點(diǎn)通訊或聊天室通訊。
3. 使用消息隊(duì)列會(huì)有什么優(yōu)缺點(diǎn)
優(yōu)點(diǎn)其實(shí)就是上文中談到的，在特殊場(chǎng)景下的應(yīng)用好處，解耦、異步與削峰等。
系統(tǒng)可用性：
系統(tǒng)因?yàn)橐蕾嚺cMQ消息隊(duì)列這個(gè)服務(wù)，若這個(gè)服務(wù)崩潰了，那么我們的整個(gè)系統(tǒng)將不可用。為此往往我們都是通過集群/分布式部署來實(shí)現(xiàn)MQ高可用的。
系統(tǒng)復(fù)雜度：
我們將數(shù)據(jù)寫到消息隊(duì)列上，就有可能會(huì)存在數(shù)據(jù)丟失的情況。以及我們?nèi)绾伪ＷC消息沒有被重復(fù)消費(fèi)等問題。
一致性問題：
A系統(tǒng)將請(qǐng)求寫入到消息隊(duì)列后就返回請(qǐng)求成功了，假設(shè)在多機(jī)部署的時(shí)候，系統(tǒng)B、C寫庫成功，假設(shè)D寫入失敗了，這種情況下就會(huì)產(chǎn)生數(shù)據(jù)不一致的問題。
4. 后語
總的來說，雖然引入消息隊(duì)列有很多好處，但是也得針對(duì)它的缺點(diǎn)來引入其它技術(shù)方案和架構(gòu)來規(guī)避這些問題，所以我們應(yīng)該按照我們的實(shí)際需求與場(chǎng)景，來選擇我們的技術(shù)方案。
本人水平有限，難免有錯(cuò)誤或遺漏之處，望大家指正和諒解，歡迎評(píng)論留言。
