摘自cs訊息者傳送的訊息只能被其中乙個消費者消費一次
消費者向指定頻道或主題（topic）發布乙個訊息，訂閱該頻道或topic的多個消費者可訂閱到這條訊息並消費
與觀察者模式的區別例如:郵箱驗證郵件的傳送，將傳送郵件這一訊息傳送到訊息佇列由其他服務進行非同步處理，而當前使用者立即返回1.不知道對方的存在，
2.可以立即返回，不用了解訊息何時被消費
高併發情況下，將短時間內到達的請求存入訊息佇列，伺服器作為消費者訂閱訊息進行處處理
模組分離，乙個模組只需向訊息佇列傳送訊息，另一模組從佇列中訂閱訊息完成呼叫，使得修改其中乙個模組對其他模組影響很小，從而提高可擴充套件性
維持一張日誌表
只是了解了相關知識，後續會進行實戰
訊息佇列 訊息佇列
輪詢排程 一次性分發所有訊息，保證訊息平均分配，不管消費者是否能正常消費 訊息應答 保證消費端能確實消費，不丟失 公平 乙個乙個分發所有訊息,在保證分發到的執行緒確認回覆後，才分發下個訊息給下個空閒的消費者，訊息持久化 保證佇列中的訊息不丟失，包括3要素 交換器 訊息佇列 訊息都必須宣告持久化 發布...
Java 知識重點 訊息佇列篇
訊息佇列 訊息佇列的使用場景。訊息的重發，補充策略。如何保證訊息的有序性。用過哪些mq，和其他mq比較有什麼優缺點，mq的連線是執行緒安全的嗎，你們公司的mq服務 架構怎樣的。mq系統的資料如何保證不丟失。rabbitmq如何實現集群高可用。kafka吞吐量高的原因。kafka 和其他訊息佇列的區別...
訊息佇列相關知識點
1.為什麼使用訊息佇列？如果我們不使用訊息佇列，對於使用者的請求，而是直接落到伺服器上，再通過資料庫或者快取對它進行響應。假如在高併發的場景下，如果沒有快取或者資料庫承受不了這麼大的壓力的話，就會造成相應速度非常緩慢，甚至造成資料庫宕機。但是使用訊息佇列之後，使用者的請求資料傳送給了訊息佇列之後可以...