MQ的提出

上游發(fā)出請(qǐng)求后阻塞等待下游給到反饋，否則整個(gè)流程將一直阻塞。
提出mq之后：即有producer mq consumer 三者

---

MQ的特點(diǎn)

異步解耦
在有了 mq 后，producer 不需要過(guò)分關(guān)心 consumer 的身份信息，只需要把消息按照指定的協(xié)議投遞到對(duì)應(yīng)的 topic 即可
producer 在處理請(qǐng)求時(shí)，只需要把消息投遞到 mq 即可認(rèn)為流程處理結(jié)束，相比于同步請(qǐng)求下游，整個(gè)流程會(huì)更加輕便靈活，擁有更高的吞吐量
流量削峰
因?yàn)橛?mq 作為緩沖層. 下游 consumer 可以設(shè)定好合適的消費(fèi)限流參數(shù)，按照指定的速率進(jìn)行消費(fèi)，能夠在很大程度上對(duì) consumer 起到保護(hù)作用

Redis自身的缺點(diǎn)（無(wú)論是做緩存還是做mq都存在的）
價(jià)格昂貴：redis本身是基于內(nèi)存的，相比傳統(tǒng)的mq組件是基于磁盤(pán)的。因此總?cè)萘靠赡苡邢蕖?br />存在數(shù)據(jù)丟失：即使有RDB/AOF的持久化策略，也難免存在數(shù)據(jù)丟失的問(wèn)題，因?yàn)檫@個(gè)持久化是異步執(zhí)行的，只要是異步，都不能說(shuō)它是百分百的。

Redis自身的優(yōu)點(diǎn)：
輕量，部署方便，運(yùn)維成本低。

---

基于List實(shí)現(xiàn)的消息隊(duì)列

首先，在使用 list 充當(dāng)消息隊(duì)列時(shí)，list 對(duì)應(yīng)的 key 則對(duì)應(yīng)為消息的 topic 名稱.
producer 在投遞消息時(shí)，可以使用 lpush 指令
consumer 消費(fèi)消息時(shí)，使用 rpop 指令
但是存在一定的缺陷：

首先，consumer 在消費(fèi)時(shí)，一定是一個(gè)類似于 loop thread 的自旋模型，每一輪循環(huán)中，通過(guò) rpop 指令嘗試從 list 中讀取消息，如果成功讀取到了消息，則進(jìn)行相應(yīng)的邏輯處理.
然而在此處，redis 的 rpop 指令是非阻塞型的，即在 list 沒(méi)有數(shù)據(jù)時(shí)，也會(huì)即時(shí)返回一個(gè)結(jié)果為 nil 的響應(yīng)，這樣在自旋模型下，對(duì)CPU是一筆不小的損耗。

倘若我們?cè)?rpop 捕捉到 nil 時(shí)，立即開(kāi)啟下一輪循環(huán)，則這個(gè)輪詢行為可能是沒(méi)有意義的，因?yàn)?list 中可能仍然不存在數(shù)據(jù). 這樣的高頻率自旋，對(duì)于 cpu 資源是一種無(wú)謂的損耗
倘若我們選擇讓 consumer 休眠一段時(shí)間進(jìn)行循環(huán)，這個(gè)休眠的時(shí)長(zhǎng)又具有一定的人為誤判性. 倘若我們把時(shí)長(zhǎng)設(shè)得太短，仍然會(huì)存在 cpu 浪費(fèi)的問(wèn)題；倘若設(shè)得太長(zhǎng)，則可能會(huì)導(dǎo)致消息處理不及時(shí)的問(wèn)題

在這個(gè)過(guò)程中，最理想的實(shí)現(xiàn)方案是，在 list 中有數(shù)據(jù)到達(dá)時(shí)，我們令 consumer 即時(shí)獲取到對(duì)應(yīng)的結(jié)果；倘若 list 數(shù)據(jù)為空，則令 consumer 陷入阻塞等待的狀態(tài)，直到有數(shù)據(jù)抵達(dá)時(shí)程序才被喚醒.?
推出阻塞等待機(jī)制：
BRPop key 【阻塞等待的超時(shí)時(shí)長(zhǎng)】
達(dá)到此閾值仍未獲取數(shù)據(jù)時(shí)會(huì)返回 nil. 如果設(shè)置為 0 ，則代表沒(méi)有這個(gè)超時(shí)限制.

---

基于Pub/Sub

?