高并發(fā)用消息隊(duì)列會(huì)延遲，還有什么好方法解決？首先，您需要知道隊(duì)列的應(yīng)用場(chǎng)景在哪里。一般來(lái)說(shuō)，當(dāng)后臺(tái)需要大量的邏輯處理或計(jì)算資源時(shí)，隊(duì)列也可以改善前端的用戶(hù)體驗(yàn)。例如：微博-關(guān)注/粉絲。如果你有1000

高并發(fā)用消息隊(duì)列會(huì)延遲，還有什么好方法解決？

首先，您需要知道隊(duì)列的應(yīng)用場(chǎng)景在哪里。一般來(lái)說(shuō)，當(dāng)后臺(tái)需要大量的邏輯處理或計(jì)算資源時(shí)，隊(duì)列也可以改善前端的用戶(hù)體驗(yàn)。例如：微博-關(guān)注/粉絲。如果你有1000個(gè)粉絲，你發(fā)一個(gè)微博，1000個(gè)粉絲就會(huì)收到你的消息。消息隊(duì)列適合這種情況。原因：1。推送1000個(gè)動(dòng)態(tài)數(shù)據(jù)是一個(gè)耗時(shí)的操作，發(fā)送微博頁(yè)面需要盡快響應(yīng)，這樣就可以將任務(wù)放入隊(duì)列中。微博發(fā)送后，立即生效，但允許粉絲延遲接收微博，通過(guò)隊(duì)列實(shí)現(xiàn)也滿(mǎn)足需求；3.可以采用高性能集群架構(gòu)處理隊(duì)列，實(shí)現(xiàn)了關(guān)注點(diǎn)的分離，使系統(tǒng)的擴(kuò)展更加靈活。在上圖中定義消息發(fā)送和消耗的過(guò)程

2。為消息定義消息協(xié)議，如ActiveMQ、stomp、XMPP等。定義消息協(xié)議，定義消息隊(duì)列需要滿(mǎn)足的場(chǎng)景

是否要保證消息的可靠性，必要時(shí)要保證存儲(chǔ)的高可用性

是否支持同步和異步消息

是否要保證消息的順序

是否需要延遲消息要支持

很多開(kāi)源的實(shí)現(xiàn)功能可以參考詳細(xì)信息。例如，rocketmq是高度可靠的，Kafka是高吞吐量的，但不是高度可靠的。