轉(zhuǎn)自：http://www.cnblogs.com/williamjie/p/9481780.html 尊重原作泡孩，謝謝
消息隊列
為什么寫這篇文章?
博主有兩位朋友分別是小A和小B:
- 小A车摄，工作于傳統(tǒng)軟件行業(yè)(某社保局的軟件外包公司)，每天工作內(nèi)容就是和產(chǎn)品聊聊需求仑鸥，改改業(yè)務(wù)邏輯吮播。再不然就是和運營聊聊天，寫幾個SQL眼俊，生成下報表意狠。又或者接到客服的通知，某某功能故障了泵琳，改改數(shù)據(jù)摄职，然后下班部署上線誊役。每天過的都是這種生活获列，技術(shù)零成長。
- 小B蛔垢，工作于某國企击孩，雖然能接觸到一些中間件技術(shù)。然而鹏漆，他只會訂閱/發(fā)布消息巩梢。通俗點說创泄，就是調(diào)調(diào)API。對為什么使用這些中間件袄稹鞠抑？如何保證高可用啊忌警？沒有充分的認(rèn)識搁拙。
慶幸的是兩位朋友都很有上進心，于是博主寫這篇文章法绵，幫助他們復(fù)習(xí)一下關(guān)于消息隊列中間件這塊的要點
復(fù)習(xí)要點
本文大概圍繞如下幾點進行闡述:
我們圍繞以上七點進行闡述盐茎。需要說明一下，本文不是《消息隊列從入門到精通》這種課程徙赢，因此只是提供一個復(fù)習(xí)思路字柠，而不是去教你們怎么調(diào)用消息隊列的API。建議對消息隊列不了解的人狡赐，去找點消息隊列的博客看看募谎，再看本文，收獲更大
正文
1阴汇、為什么要使用消息隊列?
分析:一個用消息隊列的人数冬，不知道為啥用，這就有點尷尬搀庶。沒有復(fù)習(xí)這點拐纱，很容易被問蒙，然后就開始胡扯了哥倔。
回答:這個問題,咱只答三個最主要的應(yīng)用場景(不可否認(rèn)還有其他的秸架，但是只答三個主要的),即以下六個字:解耦、異步咆蒿、削峰
(1)解耦
傳統(tǒng)模式:
傳統(tǒng)模式的缺點：
- 系統(tǒng)間耦合性太強东抹，如上圖所示，系統(tǒng)A在代碼中直接調(diào)用系統(tǒng)B和系統(tǒng)C的代碼沃测，如果將來D系統(tǒng)接入缭黔，系統(tǒng)A還需要修改代碼，過于麻煩蒂破！
中間件模式:
中間件模式的的優(yōu)點：
- 將消息寫入消息隊列馏谨，需要消息的系統(tǒng)自己從消息隊列中訂閱，從而系統(tǒng)A不需要做任何修改附迷。
(2)異步
傳統(tǒng)模式:
傳統(tǒng)模式的缺點：
- 一些非必要的業(yè)務(wù)邏輯以同步的方式運行惧互，太耗費時間哎媚。
中間件模式:
中間件模式的的優(yōu)點：
- 將消息寫入消息隊列，非必要的業(yè)務(wù)邏輯以異步的方式運行喊儡，加快響應(yīng)速度
(3)削峰
傳統(tǒng)模式
傳統(tǒng)模式的缺點：
- 并發(fā)量大的時候拨与，所有的請求直接懟到數(shù)據(jù)庫，造成數(shù)據(jù)庫連接異常
中間件模式:
中間件模式的的優(yōu)點：
- 系統(tǒng)A慢慢的按照數(shù)據(jù)庫能處理的并發(fā)量艾猜，從消息隊列中慢慢拉取消息截珍。在生產(chǎn)中，這個短暫的高峰期積壓是允許的箩朴。
2岗喉、使用了消息隊列會有什么缺點?
分析:一個使用了MQ的項目，如果連這個問題都沒有考慮過炸庞，就把MQ引進去了钱床，那就給自己的項目帶來了風(fēng)險。我們引入一個技術(shù)埠居，要對這個技術(shù)的弊端有充分的認(rèn)識查牌，才能做好預(yù)防。要記住纸颜，不要給公司挖坑！
回答:回答也很容易绎橘，從以下兩個個角度來答
- 系統(tǒng)可用性降低:你想啊，本來其他系統(tǒng)只要運行好好的称鳞，那你的系統(tǒng)就是正常的∥醣現(xiàn)在你非要加個消息隊列進去，那消息隊列掛了周霉，你的系統(tǒng)不是呵呵了诗眨。因此，系統(tǒng)可用性降低
- 系統(tǒng)復(fù)雜性增加:要多考慮很多方面的問題匠楚，比如一致性問題巍膘、如何保證消息不被重復(fù)消費，如何保證保證消息可靠傳輸与斤。因此磷支，需要考慮的東西更多，系統(tǒng)復(fù)雜性增大抵皱。
但是善榛，我們該用還是要用的。
3呻畸、消息隊列如何選型?
先說一下移盆，博主只會ActiveMQ,RabbitMQ,RocketMQ,Kafka，對什么ZeroMQ等其他MQ沒啥理解伤为，因此只能基于這四種MQ給出回答咒循。
分析:既然在項目中用了MQ，肯定事先要對業(yè)界流行的MQ進行調(diào)研绞愚，如果連每種MQ的優(yōu)缺點都沒了解清楚剑鞍，就拍腦袋依據(jù)喜好，用了某種MQ爽醋，還是給項目挖坑蚁署。如果面試官問:"你為什么用這種MQ？蚂四。"你直接回答"領(lǐng)導(dǎo)決定的光戈。"這種回答就很LOW了。還是那句話遂赠，不要給公司挖坑久妆。
回答:首先，咱先上ActiveMQ的社區(qū)跷睦，看看該MQ的更新頻率:
Apache ActiveMQ 5.15.3 Release
Christopher L. Shannon posted on Feb 12, 2018
Apache ActiveMQ 5.15.2 Released
Christopher L. Shannon posted on Oct 23, 2017
Apache ActiveMQ 5.15.0 Released
Christopher L. Shannon posted on Jul 06, 2017
省略以下記錄
...
我們可以看出筷弦，ActiveMq幾個月才發(fā)一次版本，據(jù)說研究重心在他們的下一代產(chǎn)品Apollo。
接下來烂琴，我們再去RabbitMQ的社區(qū)去看一下,RabbitMQ的更新頻率
RabbitMQ 3.7.3 release 30 January 2018
RabbitMQ 3.6.15 release 17 January 2018
RabbitMQ 3.7.2 release23 December 2017
RabbitMQ 3.7.1 release21 December 2017
省略以下記錄
...
我們可以看出爹殊，RabbitMQ版本發(fā)布比ActiveMq頻繁很多。至于RocketMQ和kafka就不帶大家看了奸绷，總之也比ActiveMQ活躍的多梗夸。詳情，可自行查閱号醉。
再來一個性能對比表
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | kafka |
|---|---|---|---|---|
| 開發(fā)語言 | java | erlang | java | scala |
| 單機吞吐量 | 萬級 | 萬級 | 10萬級 | 10萬級 |
| 時效性 | ms級 | us級 | ms級 | ms級以內(nèi) |
| 可用性 | 高(主從架構(gòu)) | 高(主從架構(gòu)) | 非常高(分布式架構(gòu)) | 非常高(分布式架構(gòu)) |
| 功能特性 | 成熟的產(chǎn)品反症，在很多公司得到應(yīng)用；有較多的文檔畔派；各種協(xié)議支持較好 | 基于erlang開發(fā)铅碍，所以并發(fā)能力很強，性能極其好线椰，延時很低;管理界面較豐富 | MQ功能比較完備胞谈，擴展性佳 | 只支持主要的MQ功能，像一些消息查詢士嚎，消息回溯等功能沒有提供呜魄，畢竟是為大數(shù)據(jù)準(zhǔn)備的，在大數(shù)據(jù)領(lǐng)域應(yīng)用廣莱衩。 |
綜合上面的材料得出以下兩點:
(1)中小型軟件公司爵嗅，建議選RabbitMQ.一方面，erlang語言天生具備高并發(fā)的特性笨蚁，而且他的管理界面用起來十分方便睹晒。正所謂，成也蕭何括细，敗也蕭何伪很！他的弊端也在這里，雖然RabbitMQ是開源的奋单，然而國內(nèi)有幾個能定制化開發(fā)erlang的程序員呢锉试？所幸，RabbitMQ的社區(qū)十分活躍览濒，可以解決開發(fā)過程中遇到的bug呆盖，這點對于中小型公司來說十分重要。不考慮rocketmq和kafka的原因是贷笛，一方面中小型軟件公司不如互聯(lián)網(wǎng)公司应又，數(shù)據(jù)量沒那么大，選消息中間件乏苦，應(yīng)首選功能比較完備的株扛，所以kafka排除。不考慮rocketmq的原因是，rocketmq是阿里出品洞就，如果阿里放棄維護rocketmq盆繁，中小型公司一般抽不出人來進行rocketmq的定制化開發(fā)，因此不推薦奖磁。
(2)大型軟件公司改基，根據(jù)具體使用在rocketMq和kafka之間二選一繁疤。一方面咖为，大型軟件公司，具備足夠的資金搭建分布式環(huán)境稠腊，也具備足夠大的數(shù)據(jù)量躁染。針對rocketMQ,大型軟件公司也可以抽出人手對rocketMQ進行定制化開發(fā)，畢竟國內(nèi)有能力改JAVA源碼的人架忌，還是相當(dāng)多的吞彤。至于kafka，根據(jù)業(yè)務(wù)場景選擇叹放，如果有日志采集功能饰恕，肯定是首選kafka了。具體該選哪個井仰，看使用場景埋嵌。
4、如何保證消息隊列是高可用的俱恶？
分析:在第二點說過了雹嗦，引入消息隊列后，系統(tǒng)的可用性下降合是。在生產(chǎn)中了罪，沒人使用單機模式的消息隊列。因此聪全，作為一個合格的程序員泊藕，應(yīng)該對消息隊列的高可用有很深刻的了解。如果面試的時候难礼，面試官問娃圆，你們的消息中間件如何保證高可用的？你的回答只是表明自己只會訂閱和發(fā)布消息鹤竭，面試官就會懷疑你是不是只是自己搭著玩踊餐，壓根沒在生產(chǎn)用過。請做一個愛思考臀稚，會思考吝岭，懂思考的程序員。
回答:這問題，其實要對消息隊列的集群模式要有深刻了解窜管，才好回答散劫。
以rcoketMQ為例，他的集群就有多master 模式幕帆、多master多slave異步復(fù)制模式获搏、多 master多slave同步雙寫模式。多master多slave模式部署架構(gòu)圖(網(wǎng)上找的,偷個懶失乾，懶得畫):
其實博主第一眼看到這個圖常熙，就覺得和kafka好像，只是NameServer集群碱茁，在kafka中是用zookeeper代替裸卫，都是用來保存和發(fā)現(xiàn)master和slave用的。通信過程如下:
Producer 與 NameServer集群中的其中一個節(jié)點（隨機選擇）建立長連接纽竣，定期從 NameServer 獲取 Topic 路由信息墓贿，并向提供 Topic 服務(wù)的 Broker Master 建立長連接，且定時向 Broker 發(fā)送心跳蜓氨。Producer 只能將消息發(fā)送到 Broker master聋袋，但是 Consumer 則不一樣，它同時和提供 Topic 服務(wù)的 Master 和 Slave建立長連接穴吹，既可以從 Broker Master 訂閱消息幽勒，也可以從 Broker Slave 訂閱消息。
那么kafka呢,為了對比說明直接上kafka的拓補架構(gòu)圖(也是找的刀荒，懶得畫)
如上圖所示代嗤，一個典型的Kafka集群中包含若干Producer（可以是web前端產(chǎn)生的Page View，或者是服務(wù)器日志缠借，系統(tǒng)CPU干毅、Memory等），若干broker（Kafka支持水平擴展泼返，一般broker數(shù)量越多硝逢，集群吞吐率越高），若干Consumer Group绅喉，以及一個Zookeeper集群渠鸽。Kafka通過Zookeeper管理集群配置，選舉leader柴罐，以及在Consumer Group發(fā)生變化時進行rebalance徽缚。Producer使用push模式將消息發(fā)布到broker，Consumer使用pull模式從broker訂閱并消費消息革屠。
至于rabbitMQ,也有普通集群和鏡像集群模式凿试，自行去了解排宰，比較簡單，兩小時即懂那婉。
要求板甘，在回答高可用的問題時，應(yīng)該能邏輯清晰的畫出自己的MQ集群架構(gòu)或清晰的敘述出來详炬。
5盐类、如何保證消息不被重復(fù)消費？
分析:這個問題其實換一種問法就是呛谜，如何保證消息隊列的冪等性?這個問題可以認(rèn)為是消息隊列領(lǐng)域的基本問題在跳。換句話來說，是在考察你的設(shè)計能力呻率，這個問題的回答可以根據(jù)具體的業(yè)務(wù)場景來答硬毕，沒有固定的答案呻引。
回答:先來說一下為什么會造成重復(fù)消費?
??其實無論是那種消息隊列礼仗，造成重復(fù)消費原因其實都是類似的。正常情況下逻悠，消費者在消費消息時候元践，消費完畢后，會發(fā)送一個確認(rèn)信息給消息隊列童谒，消息隊列就知道該消息被消費了单旁，就會將該消息從消息隊列中刪除。只是不同的消息隊列發(fā)送的確認(rèn)信息形式不同,例如RabbitMQ是發(fā)送一個ACK確認(rèn)消息饥伊，RocketMQ是返回一個CONSUME_SUCCESS成功標(biāo)志象浑，kafka實際上有個offset的概念，簡單說一下(如果還不懂琅豆，出門找一個kafka入門到精通教程),就是每一個消息都有一個offset愉豺，kafka消費過消息后，需要提交offset茫因，讓消息隊列知道自己已經(jīng)消費過了蚪拦。那造成重復(fù)消費的原因?，就是因為網(wǎng)絡(luò)傳輸?shù)鹊裙收隙逞海_認(rèn)信息沒有傳送到消息隊列驰贷，導(dǎo)致消息隊列不知道自己已經(jīng)消費過該消息了，再次將該消息分發(fā)給其他的消費者洛巢。
??如何解決?這個問題針對業(yè)務(wù)場景來答分以下幾點
??(1)比如括袒，你拿到這個消息做數(shù)據(jù)庫的insert操作。那就容易了稿茉，給這個消息做一個唯一主鍵锹锰，那么就算出現(xiàn)重復(fù)消費的情況类垦，就會導(dǎo)致主鍵沖突，避免數(shù)據(jù)庫出現(xiàn)臟數(shù)據(jù)城须。
??(2)再比如蚤认，你拿到這個消息做redis的set的操作，那就容易了糕伐，不用解決砰琢，因為你無論set幾次結(jié)果都是一樣的，set操作本來就算冪等操作良瞧。
??(3)如果上面兩種情況還不行陪汽，上大招。準(zhǔn)備一個第三方介質(zhì),來做消費記錄褥蚯。以redis為例挚冤，給消息分配一個全局id，只要消費過該消息赞庶，將<id,message>以K-V形式寫入redis训挡。那消費者開始消費前，先去redis中查詢有沒消費記錄即可歧强。
6澜薄、如何保證消費的可靠性傳輸?
分析:我們在使用消息隊列的過程中，應(yīng)該做到消息不能多消費摊册，也不能少消費肤京。如果無法做到可靠性傳輸，可能給公司帶來千萬級別的財產(chǎn)損失茅特。同樣的忘分，如果可靠性傳輸在使用過程中，沒有考慮到白修，這不是給公司挖坑么妒峦，你可以拍拍屁股走了，公司損失的錢熬荆，誰承擔(dān)舟山。還是那句話，認(rèn)真對待每一個項目卤恳，不要給公司挖坑累盗。
回答:其實這個可靠性傳輸，每種MQ都要從三個角度來分析:生產(chǎn)者弄丟數(shù)據(jù)突琳、消息隊列弄丟數(shù)據(jù)若债、消費者弄丟數(shù)據(jù)
RabbitMQ
(1)生產(chǎn)者丟數(shù)據(jù)
從生產(chǎn)者弄丟數(shù)據(jù)這個角度來看，RabbitMQ提供transaction和confirm模式來確保生產(chǎn)者不丟消息拆融。
transaction機制就是說蠢琳，發(fā)送消息前啊终，開啟事物(channel.txSelect())，然后發(fā)送消息傲须，如果發(fā)送過程中出現(xiàn)什么異常蓝牲，事物就會回滾(channel.txRollback())，如果發(fā)送成功則提交事物(channel.txCommit())泰讽。
然而缺點就是吞吐量下降了例衍。因此，按照博主的經(jīng)驗已卸，生產(chǎn)上用confirm模式的居多佛玄。一旦channel進入confirm模式，所有在該信道上面發(fā)布的消息都將會被指派一個唯一的ID(從1開始)累澡，一旦消息被投遞到所有匹配的隊列之后梦抢，rabbitMQ就會發(fā)送一個Ack給生產(chǎn)者(包含消息的唯一ID)，這就使得生產(chǎn)者知道消息已經(jīng)正確到達目的隊列了.如果rabiitMQ沒能處理該消息愧哟，則會發(fā)送一個Nack消息給你奥吩，你可以進行重試操作。處理Ack和Nack的代碼如下所示（說好不上代碼的翅雏，偷偷上了）:
channel.addConfirmListener(new ConfirmListener() {
@Override
public void handleNack(long deliveryTag, boolean multiple) throws IOException {
System.out.println("nack: deliveryTag = "+deliveryTag+" multiple: "+multiple);
}
@Override
public void handleAck(long deliveryTag, boolean multiple) throws IOException {
System.out.println("ack: deliveryTag = "+deliveryTag+" multiple: "+multiple);
}
});
(2)消息隊列丟數(shù)據(jù)
處理消息隊列丟數(shù)據(jù)的情況圈驼，一般是開啟持久化磁盤的配置。這個持久化配置可以和confirm機制配合使用望几，你可以在消息持久化磁盤后，再給生產(chǎn)者發(fā)送一個Ack信號萤厅。這樣橄抹，如果消息持久化磁盤之前，rabbitMQ陣亡了惕味，那么生產(chǎn)者收不到Ack信號楼誓，生產(chǎn)者會自動重發(fā)。
那么如何持久化呢名挥，這里順便說一下吧疟羹，其實也很容易，就下面兩步
1禀倔、將queue的持久化標(biāo)識durable設(shè)置為true,則代表是一個持久的隊列
2榄融、發(fā)送消息的時候?qū)eliveryMode=2
這樣設(shè)置以后，rabbitMQ就算掛了救湖，重啟后也能恢復(fù)數(shù)據(jù)
(3)消費者丟數(shù)據(jù)
消費者丟數(shù)據(jù)一般是因為采用了自動確認(rèn)消息模式愧杯。這種模式下，消費者會自動確認(rèn)收到信息鞋既。這時rahbitMQ會立即將消息刪除力九，這種情況下如果消費者出現(xiàn)異常而沒能處理該消息耍铜，就會丟失該消息。
至于解決方案跌前，采用手動確認(rèn)消息即可棕兼。
kafka
這里先引一張kafka Replication的數(shù)據(jù)流向圖
Producer在發(fā)布消息到某個Partition時，先通過ZooKeeper找到該Partition的Leader抵乓，然后無論該Topic的Replication Factor為多少（也即該Partition有多少個Replica）程储，Producer只將該消息發(fā)送到該Partition的Leader。Leader會將該消息寫入其本地Log臂寝。每個Follower都從Leader中pull數(shù)據(jù)章鲤。
針對上述情況，得出如下分析
(1)生產(chǎn)者丟數(shù)據(jù)
在kafka生產(chǎn)中咆贬，基本都有一個leader和多個follwer败徊。follwer會去同步leader的信息。因此掏缎，為了避免生產(chǎn)者丟數(shù)據(jù)皱蹦，做如下兩點配置
- 第一個配置要在producer端設(shè)置acks=all。這個配置保證了眷蜈，follwer同步完成后沪哺，才認(rèn)為消息發(fā)送成功。
- 在producer端設(shè)置retries=MAX酌儒，一旦寫入失敗辜妓，這無限重試
(2)消息隊列丟數(shù)據(jù)
針對消息隊列丟數(shù)據(jù)的情況，無外乎就是忌怎，數(shù)據(jù)還沒同步籍滴，leader就掛了，這時zookpeer會將其他的follwer切換為leader,那數(shù)據(jù)就丟失了榴啸。針對這種情況孽惰，應(yīng)該做兩個配置。
- replication.factor參數(shù)鸥印，這個值必須大于1勋功，即要求每個partition必須有至少2個副本
- min.insync.replicas參數(shù)，這個值必須大于1库说，這個是要求一個leader至少感知到有至少一個follower還跟自己保持聯(lián)系
這兩個配置加上上面生產(chǎn)者的配置聯(lián)合起來用狂鞋，基本可確保kafka不丟數(shù)據(jù)
(3)消費者丟數(shù)據(jù)
這種情況一般是自動提交了offset，然后你處理程序過程中掛了璃弄。kafka以為你處理好了要销。再強調(diào)一次offset是干嘛的
offset：指的是kafka的topic中的每個消費組消費的下標(biāo)。簡單的來說就是一條消息對應(yīng)一個offset下標(biāo)夏块，每次消費數(shù)據(jù)的時候如果提交offset疏咐，那么下次消費就會從提交的offset加一那里開始消費纤掸。
比如一個topic中有100條數(shù)據(jù)，我消費了50條并且提交了浑塞，那么此時的kafka服務(wù)端記錄提交的offset就是49(offset從0開始)借跪，那么下次消費的時候offset就從50開始消費。
解決方案也很簡單酌壕，改成手動提交即可掏愁。
ActiveMQ和RocketMQ
大家自行查閱吧
7、如何保證消息的順序性卵牍？
分析:其實并非所有的公司都有這種業(yè)務(wù)需求果港，但是還是對這個問題要有所復(fù)習(xí)。
回答:針對這個問題糊昙，通過某種算法辛掠，將需要保持先后順序的消息放到同一個消息隊列中(kafka中就是partition,rabbitMq中就是queue)。然后只用一個消費者去消費該隊列释牺。
有的人會問:那如果為了吞吐量汹桦，有多個消費者去消費怎么辦驯用？
這個問題奖蔓，沒有固定回答的套路以蕴。比如我們有一個微博的操作，發(fā)微博祭刚、寫評論牌捷、刪除微博，這三個異步操作袁梗。如果是這樣一個業(yè)務(wù)場景宜鸯，那只要重試就行。比如你一個消費者先執(zhí)行了寫評論的操作遮怜，但是這時候，微博都還沒發(fā)鸿市，寫評論一定是失敗的锯梁，等一段時間。等另一個消費者焰情，先執(zhí)行寫評論的操作后陌凳，再執(zhí)行，就可以成功内舟。
總之合敦，針對這個問題，我的觀點是保證入隊有序就行验游，出隊以后的順序交給消費者自己去保證充岛，沒有固定套路保檐。
一些其他的相關(guān)連接：
https://www.cnblogs.com/williamjie/p/9481774.html RabbitMQ基礎(chǔ)概念詳細介紹
https://blog.csdn.net/anzhsoft/article/details/19563091 RabbitMQ消息隊列
https://segmentfault.com/a/1190000016351345 https://blog.csdn.net/qq_26656329/article/details/77891793 RabbitMQ參數(shù)調(diào)優(yōu)
