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

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

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

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

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

是否支持同步和異步消息

是否要保證消息的順序

是否需要延遲消息要支持

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