消息隊列(Message Queue)是一種進程間通訊或同一進程的不一樣線程間的通訊方式。進程或者線程之間經過 消息 進行通訊,消息發送後能夠當即返回,由消息系統來確保信息的可靠傳遞,消息發佈者(生產者)只管把消息發佈到消息隊裏中而不用管誰來消費,消息使用者(消費者)只管從消息隊列中獲取消息以進一步處理而不用管理誰發佈的消息,這樣發佈者和使用者都不用知道對方的存在。前端
消息(Message)是指在應用之間傳送的數據。消息能夠很是簡單,好比只包含文本字符串,也能夠很複雜,如嵌入對象。性能優化
經過提供 消息傳遞 和 消息排隊 模型,它能夠在 分佈式環境 下提供 應用解耦、彈性伸縮、冗餘存儲、流量削峯、異步通訊、數據同步 等等功能,其做爲 分佈式系統架構 中的一個重要組件,有着舉足輕重的地位。消息隊列主要特色有:服務器
同步處理 是指從請求的發起一直到最終的處理完成期間,請求的調用方一直在同步阻塞等待調用的處理完成。架構
異步處理 處理是指在請求發起的處理過程當中,客戶端的代碼已經返回了,它能夠繼續進行本身的後續操做,而不須要等待調用處理完成。異步
對一些比較耗時且不須要即時(同步)返回操做結果的操做,能夠把處理過程經過消息隊列進行異步處理。這樣作能夠推遲耗時操做的處理,使耗時操做異步化,而沒必要阻塞客戶端程序,客戶端的程序在獲得處理結果以前能夠繼續執行,從而提升客戶端程序的處理性能。分佈式
異步處理的主要目的是 減小請求響應時間,實現非核心流程異步化,提升系統響應性能。性能
使用消息隊列,能夠有多個生產者發佈消息,多個消費者消費消息,共同完成整個的業務處理邏輯,生產者只關心是否正確將消息寫入消息隊列,消費者只關心從消息隊列中獲取消息,而後進行處理邏輯,生產者和消費者之間不須要直接的交互調用,沒有代碼的依賴耦合。優化
耦合度越低程序代碼越容易維護,也容易進行擴展。線程
通常在秒殺活動中普遍使用。設計
在秒殺活動中,通常因爲瞬時訪問量過大,服務器瞬間接收了大量的請求,流量暴增,這種狀況下頗有可能致使相關係統沒法處理請求甚至崩潰。爲了解決這個問題,通常會在應用的前端加入消息隊列。
使用消息隊列,即使是訪問流量持續的增加,系統依然能夠持續的接收請求。雖然生產者生成的消息比消費者消費的速度快,可是經過消息隊列進行了緩衝,在短期內,生產者和消費者之間處理能力不會互相影響,一樣也能夠保證系統的穩定性。
消息隊列通常都內置了高效的通訊機制,所以能夠用於單純的消息通信,好比實現點對點消息隊列或者聊天室。
若是沒有消息隊列,每當一個新的業務方介入,那都須要聯調一次接口。有了消息隊列,只須要關係消息是否送達了隊列,至於誰但願訂閱,是下游的事情,無疑極大地減小了開發和聯調的工做量。
將消息隊列用在日誌處理中,解決了大量日誌傳輸的問題(如Kafka)。
點對點模式 用於 消息生產者 和 消息消費者 之間 點到點 的通訊。消息生產者將消息發送到由某個名字標識的特定隊列(Queue
)。在消息傳遞給消費者以前它被 存儲 在這個隊列中。隊列消息 能夠放在 內存 中也能夠 持久化,以保證在消息服務出現故障時仍然可以傳遞消息。
點對點模式特色:
發佈者/訂閱者 模型支持向一個特定的 消息主題 生產消息。 0 或多個 訂閱者 可能對接收來自 特定消息主題 的消息感興趣。
在這種模型下,發佈者和訂閱者彼此不知道對方。多個消費者能夠得到消息,在 發佈者 和 訂閱者 之間存在 時間依賴性。發佈者須要創建一個 訂閱(subscription
),以便可以消費者訂閱。訂閱者 必須保持 持續的活動狀態 並 接收消息。
發佈/點閱模式特色:
目前在生產環境,使用較多的消息隊列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等。
好文推薦: