mq訊息佇列廣泛應用在中大型分布式系統中,主要使用的場景包括:非同步處理 , 應用解耦 , 流量削峰和即時通訊四個場景.
場景介紹:典型的im即時通訊系統中, 使用者註冊成功後需要傳送註冊郵件 / 註冊通知簡訊
傳統解決方案:
引入訊息佇列
場景說明:典型的電商購物平台,使用者下單之後,訂單系統需要通知庫存系統
傳統解決方法
引入訊息佇列
場景介紹:流量削峰在大型秒殺活動中使用廣泛,秒殺活動因為流量過大導致流量暴增應用掛掉.
引入訊息佇列:使用訊息佇列可以 控制活動的人數 + 緩解短時間內高流量壓垮應用
使用者的請求被伺服器接收後,首先
是什麼?:日誌處理是指將訊息佇列用在日誌處理中，比如linkedin這種大型職業社交應用架構中kafka的應用（kafka就是linkedin開發並開源的），解決大量日誌傳輸的問題。
日誌採集客戶端–寫入—>kafka訊息佇列
單純從技術上看，im系統的所有資料路徑無非就是3種情況：
1）訊息從a客戶端 -> 經由伺服器->再**給b客戶端：即c to s to c；
2）訊息從a客戶端直髮服務端：即c to s；
2）訊息從伺服器直髮a客戶端：即s to c。
而訊息中介軟體裡的訂閱模式：
即生產者推送訊息到mq、再由消費者從mq讀取，理論上是完全可以實現上面所說的3種訊息傳遞路徑的，如果要實現im訊息的生產和消費，基本上就是乙個使用者對應乙個佇列，而大量使用者存在的情況下就是大量的佇列產生，而每個佇列的訊息流轉其實很少，試想乙個人聊天時能發出多少訊息？。
但存在乙個問題的：
本身mq被設計來的目的是處理大量的訊息的，也即是通常的應用場景下，不會有多少佇列存在，但每個佇列每秒都要滿負荷處理大量的訊息，而假設你來開發mq中間的話，你也能想到：你最大的優化目標是將每個佇列的訊息處理吞吐做到最大化，而不應該把處理大量的佇列連線、斷開、重連這些事情做為mq存在的意義。
綜上：我的個人意見是，沒有行不行，而是合不合適，所以就看你怎麼選擇了。有的人因為im系統很小，為了省事或偷懶，也真就是用mq來實現的，但除非你老闆懂技術，不然誰管你。
訊息中介軟體 MQ
1 為什麼需要訊息佇列mq 因為在高併發環境下，由於來不及同步處理，請求往往會發生阻塞，比如 大量的insert，update語句請求同時到達mysql，直接導致無數的行鎖鎖表，甚至最後的請求會堆積過多，從而觸發too many connections錯誤。通過使用訊息佇列，可以非同步的處理請求，從...
MQ訊息中介軟體
mq是message queue,就是訊息佇列。是進行通訊的中介軟體產品，可以把訊息佇列比作是乙個存放訊息的容器，呼叫的方法就是訊息，把方法存到佇列中然後從佇列中取出方法去執行。目前使用較多的訊息佇列有activemq，rabbitmq，kafka，rocketmq。訊息佇列的作用有非同步 削峰 解...
訊息中介軟體MQ
訊息中介軟體利用高效可靠的訊息傳遞機制進行平台無關的資料交流，並基於資料通訊來進行分布式系統的整合。通過提供訊息傳遞和訊息排隊模型，它可以在分布式環境下擴充套件程序間的通訊。對於訊息中介軟體，常見的角色大致也就有producer 生產者 consumer 消費者 訊息佇列中介軟體是分布式系統中重要的...