MQ是干嘛的

消息總線(xiàn)（Message Queue），后文稱(chēng)MQ，是一種跨進(jìn)程的通信機(jī)制，用于上下游傳遞消息。
MQ是一種非常常見(jiàn)的上下游“邏輯解耦+物理解耦”的消息通信服務(wù)。

什么時(shí)候不使用消息總線(xiàn)

結(jié)論：調(diào)用方實(shí)時(shí)依賴(lài)執(zhí)行結(jié)果的業(yè)務(wù)場(chǎng)景，請(qǐng)使用調(diào)用，而不是MQ。

什么時(shí)候使用MQ

典型場(chǎng)景一：數(shù)據(jù)驅(qū)動(dòng)的任務(wù)依賴(lài)

1. 任務(wù)時(shí)間有先后順序
2. 任務(wù)會(huì)依賴(lài)前面任務(wù)處理的結(jié)果
方案是，采用MQ解耦：
1）task1準(zhǔn)時(shí)開(kāi)始，結(jié)束后發(fā)一個(gè)“task1 done”的消息
2）task2訂閱“task1 done”的消息，收到消息后第一時(shí)間啟動(dòng)執(zhí)行，結(jié)束后發(fā)一個(gè)“task2 done”的消息
3）task3同理
特別說(shuō)明：MQ只用來(lái)傳遞上游任務(wù)執(zhí)行完成的消息，并不用于傳遞真正的輸入輸出數(shù)據(jù)。
另外：這種方式也可以用工作流引擎來(lái)處理。

典型場(chǎng)景二：上游不關(guān)心執(zhí)行結(jié)果

上游需要關(guān)注執(zhí)行結(jié)果時(shí)要用“調(diào)用”，上游不關(guān)注執(zhí)行結(jié)果時(shí)，就可以使用MQ了。
舉例：
智聯(lián)招聘 用戶(hù) 更改簡(jiǎn)歷，會(huì) 通知分析系統(tǒng)重新分析簡(jiǎn)歷，通知關(guān)注你的人你已經(jīng)做跟了簡(jiǎn)歷更新可以聯(lián)系你了 等等。
做法1：在更新簡(jiǎn)歷的時(shí)候 調(diào)用 其他方法。
優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單
不足：
A：更新簡(jiǎn)歷的時(shí)間增加了。 
	-- 后邊的通知并不是現(xiàn)在就要通知到的，可以有一定的延遲；本質(zhì)是 實(shí)時(shí)調(diào)用應(yīng)該完成的只是需要實(shí)時(shí)處理的任務(wù)，后續(xù)可延遲的任務(wù)后續(xù)處理。
B：如果后面的沒(méi)有通知到，會(huì)影響更新簡(jiǎn)歷的功能。上下游邏輯+物理依賴(lài)嚴(yán)重
C：如果后邊增加 一個(gè)關(guān)注該消息的功能，那么就需要修改這個(gè)方法。屬于架構(gòu)設(shè)計(jì)中典型的依賴(lài)倒轉(zhuǎn)(本應(yīng)該B依賴(lài)A的處理消息的，但現(xiàn)在是A依賴(lài)B的處理結(jié)果)
做法2：采用MQ解耦，更新成功后發(fā)一個(gè)消息即可，訂閱消息這自己處理。
優(yōu)點(diǎn)是：
1）上游執(zhí)行時(shí)間短
2）上下游邏輯+物理解耦，除了與MQ有物理連接，模塊之間都不相互依賴(lài)
3）新增一個(gè)下游消息關(guān)注方，上游不需要修改任何代碼

典型場(chǎng)景三：上游關(guān)注執(zhí)行結(jié)果，但執(zhí)行時(shí)間很長(zhǎng)

有時(shí)候上游需要關(guān)注執(zhí)行結(jié)果，但執(zhí)行結(jié)果時(shí)間很長(zhǎng)（典型的是調(diào)用離線(xiàn)處理，或者跨公網(wǎng)調(diào)用），也經(jīng)常使用回調(diào)網(wǎng)關(guān)+MQ來(lái)解耦。

借用一個(gè)例子：

說(shuō)明：

1. 上游應(yīng)該說(shuō)的就是調(diào)用方

2. MQ應(yīng)該是微信提供的接口

3. 對(duì)接的時(shí)候，在調(diào)用支付后，還需要訂閱這個(gè)消息，這樣應(yīng)用服務(wù)就是微信MQ的訂閱方了，在支付成功后就可以通知你。

 延遲消息設(shè)計(jì)

場(chǎng)景：公示3天后，沒(méi)人有異議，就算通過(guò)。
最Low方法：做一個(gè)定時(shí)任務(wù)輪訓(xùn)，可以cron也可以是java中的timer，如果輪訓(xùn)間隔設(shè)置長(zhǎng)了則粒度大，時(shí)效性不好，設(shè)置太短，則效率低。
1.Java中java.util.concurrent.DelayQueue
優(yōu)點(diǎn)：JDK自身實(shí)現(xiàn)，使用方便，量小適用
缺點(diǎn)：隊(duì)列消息處于jvm內(nèi)存，不支持分布式運(yùn)行和消息持久化
2.Rocketmq延時(shí)隊(duì)列
優(yōu)點(diǎn)：消息持久化，分布式
缺點(diǎn)：不支持任意時(shí)間精度，只支持特定level的延時(shí)消息
3.Rabbitmq延時(shí)隊(duì)列（TTL+DLX實(shí)現(xiàn)）
優(yōu)點(diǎn)：消息持久化，分布式
缺點(diǎn)：延時(shí)相同的消息必須扔在同一個(gè)隊(duì)列
4.Redis實(shí)現(xiàn)
參考：https://www.cnblogs.com/lylife/p/7881950.html
5.當(dāng)然可以自己寫(xiě)：
思路：
A：創(chuàng)建一個(gè)3600(S)的循環(huán)鏈表
B：?jiǎn)?dòng)一個(gè)Timer，每秒移動(dòng)一個(gè)下標(biāo)
C：下標(biāo)每到一個(gè)Node就判斷該node是否有需要執(zhí)行的JOB，有則發(fā)搜一個(gè)消息去執(zhí)行
D：添加任務(wù)時(shí)，需要 delayTime/3600 作為循環(huán)的次數(shù)，每循環(huán)一次需要--；delayTime%3600作為偏移量。
RocketMQ消息產(chǎn)生后，生產(chǎn)者希望在間隔一段時(shí)間后被消費(fèi)的場(chǎng)景可以使用定時(shí)消息，RocketMQ目前不支持自定義延遲時(shí)間，但可以指定延遲等級(jí)，可以選擇18個(gè)延遲等級(jí)，分別是對(duì)應(yīng)延遲時(shí)間是1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h。

消息隊(duì)列（MsgQueue）的消息必達(dá)性架構(gòu)與流程

 架構(gòu)方向

MQ要想盡量消息必達(dá)，架構(gòu)上有兩個(gè)核心設(shè)計(jì)點(diǎn)：
（1）消息落地
（2）消息超時(shí)、重傳、確認(rèn)

MQ消息可靠投遞核心流程

投遞消息：MQ持久化后返回給 消息的生產(chǎn)者。
消費(fèi)消息：只有當(dāng)消息的消費(fèi)者 確認(rèn) 收到消息才刪除消息。

數(shù)據(jù)丟失保障措施

為了降低消息丟失的概率，MQ需要進(jìn)行超時(shí)和重傳。

投遞消息：如果MQ一直沒(méi)有確認(rèn)，MQ Client就會(huì)重發(fā)，直到MQ確認(rèn)收到，如果超時(shí)就會(huì)回調(diào) 投遞失敗。

消費(fèi)消息：如果消費(fèi)者一直沒(méi)有回復(fù)，MQ Server會(huì)重發(fā)消息，采用指數(shù)間隔時(shí)間(1s 2s 4s …)，這是消費(fèi)者會(huì)收到多條一樣的數(shù)據(jù)。

消費(fèi)者拿到了重復(fù)的消息，就需要去重，實(shí)現(xiàn)冪等性。
 

消息總線(xiàn)的冪等性設(shè)計(jì)

冪等性設(shè)計(jì)至關(guān)重要
投遞消息的冪等性是由MQ來(lái)完成，邏輯是：對(duì)每條消息，MQ系統(tǒng)內(nèi)部必須生成一個(gè)inner-msg-id，作為去重和冪等的依據(jù)，這個(gè)內(nèi)部消息ID的特性是：
（1）全局唯一
（2）MQ生成，具備業(yè)務(wù)無(wú)關(guān)性，對(duì)消息發(fā)送方和消息接收方屏蔽
消費(fèi)消息的冪等性是由消費(fèi)者保證，為了保證業(yè)務(wù)冪等性，業(yè)務(wù)消息體中，必須有一個(gè)biz-id，作為去重和冪等的依據(jù)，這個(gè)業(yè)務(wù)ID的特性是：
（1）對(duì)于同一個(gè)業(yè)務(wù)場(chǎng)景，全局唯一
（2）由業(yè)務(wù)消息發(fā)送方生成，業(yè)務(wù)相關(guān)，對(duì)MQ透明
（3）由業(yè)務(wù)消息消費(fèi)方負(fù)責(zé)判重，以保證冪等

流量削峰填谷

削峰填谷：顧名思義，是將流量的高峰 削去，保證系統(tǒng)可用性。在系統(tǒng)稍微空閑(谷)的時(shí)候處理。
原因是：一個(gè)處理鏈路，各個(gè)節(jié)點(diǎn)處理能力不同。一般情況，上游的業(yè)務(wù)系統(tǒng)都可以支撐過(guò)高并發(fā)，下游的業(yè)務(wù)系統(tǒng)，處理邏輯相對(duì)復(fù)雜，單TPS處理時(shí)間長(zhǎng)。 如果讓下游業(yè)務(wù)系統(tǒng)跟上游處理能力相同，這個(gè)費(fèi)用相當(dāng)大。
舉個(gè)栗子，秒殺業(yè)務(wù)：
上游發(fā)起下單操作
下游完成秒殺業(yè)務(wù)邏輯（庫(kù)存檢查，庫(kù)存凍結(jié)，余額檢查，余額凍結(jié)，訂單生成，余額扣減，庫(kù)存扣減，生成流水，余額解凍，庫(kù)存解凍）
上游下單業(yè)務(wù)簡(jiǎn)單，每秒發(fā)起了10000個(gè)請(qǐng)求，下游秒殺業(yè)務(wù)復(fù)雜，每秒只能處理2000個(gè)請(qǐng)求，很有可能上游不限速的下單，導(dǎo)致下游系統(tǒng)被壓垮，引發(fā)雪崩。
解決思路：
1. 上游發(fā)慢點(diǎn) -- 用戶(hù)下單處理不及時(shí)，腦子有問(wèn)題
2. 下游按照正常容量來(lái)處理  -- 這個(gè)可以，別采用訂閱模式，使用MQ的拉模式
下游改動(dòng)：
1. 定時(shí)任務(wù)：用定時(shí)任務(wù)去拉
2. 批處理：為提高處理效率，一次拉一批，處理也按照批處理方式

end