--寫在前面--
在專案中總是用到的乙個中介軟體就是訊息佇列，從以前的redis到後來用到的rabbitmq，再到即將要研究的kafka，一直只知道用，卻沒有進行好好總結。
正如有句話說的，你知道的越多，你不知道也就越多。以下文章是對過去的總結，以及對未來的展望。
缺點2.通訊模式
訊息是指在應用間傳送的資料，訊息佇列是一種應用間的通訊方式，訊息傳送後可以立即返回，有訊息系統來確保資訊的可靠傳遞，訊息發布者只管把訊息發布到mq中而不管誰來取，訊息使用者只管從mq中取訊息而不管誰發布的，這樣發布者和使用者都不用知道對方的存在。
這個很好理解，原本訊息是由生產者直接傳遞給消費者，也就是說訊息需要同步的傳送給消費者，這時候問題來了，假設消費者掛了怎麼辦，是不是需要重發？實際上有些呼叫不需要同步呼叫介面，此時就可用mq去作解耦。
a系統需要調b、c、d系統，a系統寫自己庫需要20ms，但還需要去bcd呼叫，此時延時達到了使用者不可接受的水平。使用mq後，bcd只需要去自己對應訊息佇列取引數在本地自己執行對應操作。
系統引入的外部依賴越多，越容易掛掉，本來你就是a系統呼叫bcd三個系統的介面就好了，人abcd四個系統好好的，沒啥問題，你偏加個mq進來，萬一mq掛了咋整？mq掛了，整套系統崩潰了，你不就完了麼。
硬生生加個mq進來，你怎麼保證訊息沒有重複消費？怎麼處理訊息丟失的情況？怎麼保證訊息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已。
a系統處理完成，bcd系統有乙個存在問題，資料就不一致了。
點對點模式通常基於拉取或者輪詢訊息傳送模型，傳送到訊息佇列的訊息有且只有乙個消費者進行處理。生產者放入訊息佇列，由消費者主動拉取並決定拉取訊息頻率，缺點是訊息佇列是否有訊息需要消費無法被消費者感知。
發布訂閱模式是基於訊息的訊息傳送模型，該模型可有多個訂閱者。生產者將訊息放入訊息佇列，訊息佇列將訊息推送給訂閱過該訊息的消費者。也就是說消費者屬於被動接收訊息，無需感知訊息佇列是否有待消費的訊息。此處推送的速度變成問題，假設消費者速度不一致，則勢必在推送速度上面存在過快或者過慢的問題，在消費者處就存在無法承受或者資源浪費的問題。
可消費訊息數量 訊息佇列之Kafka概念篇
1.基本定義 kafka是乙個分布式的 可分割槽的 可複製的訊息系統。它提供了普通資訊系統的功能，但具有自己獨特的設計 2.底層原理 2 topic與訊息 這樣，訊息就以乙個個id的方式，組織起來。consumer選擇乙個topic，通過id指定從哪個位置開始消費訊息。消費完成之後保留id，下次可以...
訊息佇列RabbitMQ的概念
rabbitmq的核心概念為以下 1.訊息 由訊息頭和訊息體組成。訊息體是不透明的，訊息頭是由一系列可選屬性組成，包括路由鍵 優先權 是否持久化等 2.交換器 用來接收生產者傳送的訊息，並將訊息路由給伺服器中的佇列，有四種型別 direct 預設 fanout topic headers direc...
Java 知識重點 訊息佇列篇
訊息佇列 訊息佇列的使用場景。訊息的重發，補充策略。如何保證訊息的有序性。用過哪些mq，和其他mq比較有什麼優缺點，mq的連線是執行緒安全的嗎，你們公司的mq服務 架構怎樣的。mq系統的資料如何保證不丟失。rabbitmq如何實現集群高可用。kafka吞吐量高的原因。kafka 和其他訊息佇列的區別...