解耦:
容許你獨立的擴展或修改兩邊的處理過程,只要確保它們遵照一樣的接口約束。安全
冗餘:
消息隊列把數據進行持久化直到它們已經被徹底處理,經過這一方式規避了數據丟失風險。許多消息隊列所採用的"插入-獲取-刪除"範式中,在把一個消息從隊列中刪除以前,須要你的處理系統明確的指出該消息已經被處理完畢,從而確保你的數據被安全的保存直到你使用完畢。服務器
擴展性:
由於消息隊列解耦了你的處理過程,因此增大消息入隊和處理的頻率是很容易的,只要另外增長處理過程便可。併發
靈活性 & 峯值處理能力:
在訪問量劇增的狀況下,應用仍然須要繼續發揮做用,可是這樣的突發流量並不常見。若是爲以能處理這類峯值訪問爲標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列可以使關鍵組件頂住突發的訪問壓力,而不會由於突發的超負荷的請求而徹底崩潰。異步
可恢復性:
系統的一部分組件失效時,不會影響到整個系統。消息隊列下降了進程間的耦合度,因此即便一個處理消息的進程掛掉,加入隊列中的消息仍然能夠在系統恢復後被處理。優化
順序保證:
在大多使用場景下,數據處理的順序都很重要。大部分消息隊列原本就是排序的,而且能保證數據會按照特定的順序來處理。(Kafka 保證一個 Partition 內的消息的有序性)設計
緩衝:
有助於控制和優化數據流通過系統的速度,解決生產消息和消費消息的處理速度不一致的狀況。日誌
異步通訊:
不少時候,用戶不想也不須要當即處理消息。消息隊列提供了異步處理機制,容許用戶把一個消息放入隊列,但並不當即處理它。想向隊列中放入多少消息就放多少,而後在須要的時候再去處理它們。blog
kafka 經過 zookeeper 來存儲集羣的 meta 信息排序
Kafka 經過給 Topic指定多個Partition, 而各個Partition分佈在不一樣的節點上, 這樣便能提供比較好的併發能力. 同時, 對於 Partition 還能夠指定對應的 Replica 數, 這也極大地提升了數據存儲的安全性, 防止出現數據丟失.索引
Broker 能夠簡單理解爲一個 Kafka 節點,也能夠理解爲集羣中包含的服務器, 多個 Broker 節點構成整個 Kafka 集羣;
Topic 條發佈到 kafka 集羣的消息屬於的類別
Partition 它是 Topic 在物理上的分組, 多個 Partition 會被分散地存儲在不一樣的 Kafka 節點上; 單個 Partition 的消息是保證有序的, 但整個 Topic 的消息就不必定是有序的;
Segment 包含消息內容的指定大小的文件, 由 index 文件和 log 文件組成; 一個 Partition 由多個 Segment 文件組成
Replica (N) 消息的冗餘備份, 表現爲每一個 Partition 都會有 N 個徹底相同的冗餘備份, 這些備份會被儘可能分散存儲在不一樣的機器上;
Producer 經過 Broker 發佈新的消息到某個 Topic 中;
Consumer 經過 Broker 從某個 Topic 中獲取消息;
消息發送時都被髮送到一個 topic,其本質就是一個目錄,而 topic 由是由一些 Partition Logs(分區日誌)組成, 其組織結構以下圖所示:
咱們能夠看到,每一個 Partition 中的消息都是有序的,生產的消息被不斷追加到 Partition log 上,其中的每個消息都被賦予了一個惟一的 offset 值。
每個 Partition 都是和一個目錄對應的, 同時每個目錄裏都包含了一個 index 文件和 log 文件
其中 log 文件存儲實際的消息內容, 而和它同名的 index 文件存儲消息的索引數據. log 的文件名存放的是上一個 log 文件中最後一個消息的 offset 值.
能夠按照下面的方法找到指定 offset 對應的消息