1.什么是消息隊(duì)列
隊(duì)列是存放消息的容器
2.為什么要使用隊(duì)列
- 解耦：例：系統(tǒng)A放消息到隊(duì)列，BCD系統(tǒng)按需訂閱，增減訂閱無(wú)需修改代碼;或BCD系統(tǒng)中某一個(gè)掛了，幾分鐘內(nèi)消息可緩沖在隊(duì)列，增加系統(tǒng)可用性。
- 異步：串行變并行。例：發(fā)短信郵件消息各需50s,則一共需要100s,隊(duì)列并行50s?；蛘咧暗幕卣{(diào)是A隔一段時(shí)間去輪詢B，或者B去調(diào)用A的api通知，現(xiàn)B完成后發(fā)消息給MQ，MQ去通知A
- 削峰 :5000條數(shù)據(jù)請(qǐng)求穿透數(shù)據(jù)庫(kù)造成壓力；放在隊(duì)列消費(fèi)者每次取1000條即可
3.ActiviMQ RabbitMQ RocketMQ Kafka比較
ActiviMQ ：6000+；資料豐富；性能差
RabbitMQ ：12000+；輕量迅捷，客戶端語(yǔ)言多；消息堆積支持差，性能差
RocketMQ ：十萬(wàn)級(jí)；性能高，穩(wěn)定性高，優(yōu)化響應(yīng)時(shí)延，社區(qū)活躍；兼容性差
Kafka：百萬(wàn)級(jí)；為大數(shù)據(jù)而生，性能好，兼容性好；響應(yīng)時(shí)延高，topic達(dá)到上百個(gè)，性能大幅下降
4.RabbitMQ - AMQP協(xié)議的實(shí)現(xiàn)
4.1 RabbitMQ的特點(diǎn)
- 可靠【持久化、發(fā)布確認(rèn)、消費(fèi)確認(rèn)】
- 靈活的路由 【路由指定對(duì)應(yīng)的路由策略】
- 消息集群【多個(gè)服務(wù)器組合成為一個(gè)邏輯broker】
- 高可用【通過(guò)集群鏡像實(shí)現(xiàn)】
- 多種協(xié)議【RabbitMQ 支持多種消息隊(duì)列協(xié)議，比如 STOMP、MQTT】
- 多語(yǔ)言客戶端
- 管理界面
- 跟蹤機(jī)制【如果消息異常，RabbitMQ 提供消息跟蹤機(jī)制，可以找出發(fā)生了什么】
4.2 RabbitMQ的組成部分和工作流程
- Broker：中間件實(shí)體機(jī)
- 交換器Exchange
- 隊(duì)列 Queue
- 綁定 Bind
- 路由 RoutingKey
- 信道 Channel 虛擬概念
工作流程：
- Producer連接到隊(duì)列Broker:創(chuàng)建Connection,打開(kāi)Channel
- Channel指定交換機(jī)類型、名稱、是否持久化
- 生產(chǎn)者發(fā)布消息：指定RoutingKey 和消息是否持久化
- Exchange根據(jù)RountingKey將消息放進(jìn)對(duì)應(yīng)隊(duì)列
- 消費(fèi)者監(jiān)聽(tīng)到消息后開(kāi)始業(yè)務(wù)處理
4.3 RabbitMQ交換機(jī)的四種類型的特點(diǎn)，以及使用方法。=消息如何路由
direct：直接類型，routingKey嚴(yán)格匹配
finout：廣播類型，通道上所有的
topic ：通配符類型
header[場(chǎng)景少，基本不用]：通過(guò)header信息進(jìn)行匹配，match分any部分匹配 all全部匹配
4.4 如何確保消息正確地發(fā)送至RabbitMQ？ 如何確保消息接收方消費(fèi)了消息？
1） 發(fā)布時(shí)：
- 發(fā)布者確認(rèn)：與路由無(wú)關(guān)，channel.waitForConfirm(); 批量channel.waitForConfirmOrDie();
- 備用交換器
- 事務(wù)
- 消息持久化
4.5 如何避免消息重復(fù)投遞或重復(fù)消費(fèi)？
冪等性設(shè)計(jì)
