一. 內部原理

1. 點對點模式（一對一，消費者主動拉取數據，消息收到后消息清除）

點對點模型通常是一個基于拉取或者輪詢的消息傳送模型，這種模型從隊列中請求信息，而不是將消息推送到客戶端。這個模型的特點是發送到隊列的消息被一個且只有一個接收者接收處理，即使有多個消息監聽者也是如此。

2. 發布/訂閱模式（一對多）

發布訂閱模型則是另一個消息傳送模型。發布訂閱模型可以有多種不同的訂閱者，臨時訂閱者只在主動監聽主題時才接收消息，而持久訂閱者則監聽主題的所有消息，即使當前訂閱者不可用，處于離線狀態。

?

二. 為什么需要消息隊列

1. 解耦：

允許你獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。

2. 冗余：

消息隊列把數據進行持久化直到它們已經被完全處理，通過這一方式規避了數據丟失風險。許多消息隊列所采用的"插入-獲取-刪除"范式中，在把一個消息從隊列中刪除之前，需要你的處理系統明確的指出該消息已經被處理完畢，從而確保你的數據被安全的保存直到你使用完畢。

3. 擴展性：

因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。

4. 靈活性 & 峰值處理能力：

在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量并不常見。如果為以能處理這類峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列能夠使關鍵組件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全崩潰。

5. 可恢復性：

系統的一部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復后被處理。

6. 順序保證：

在大多使用場景下，數據處理的順序都很重要。大部分消息隊列本來就是排序的，并且能保證數據會按照特定的順序來處理。（Kafka保證一個Partition內的消息的有序性）

7. 緩沖：

有助于控制和優化數據流經過系統的速度，解決生產消息和消費消息的處理速度不一致的情況。

8. 異步通信：

很多時候，用戶不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然后在需要的時候再去處理它們。

?

三. Kafka架構

?

1. Producer ：消息生產者，就是向kafka broker發消息的客戶端；

2. Consumer ：消息消費者，向kafka broker取消息的客戶端；

其中的offset需要存在其他位置，低版本0.9之前將offset保存在Zookeeper中，0.9及之后保存在Kafka的“__consumer_offsets”主題中。

3. Topic ：可以理解為一個隊列或一個消息分類；

4.? Consumer Group （CG）：這是kafka用來實現一個topic消息的廣播（發給所有的consumer）和單播（發給任意一個consumer）的手段。

一個topic可以有多個CG。topic的消息會復制（不是真的復制，是概念上的）到所有的CG，但每個partion只會把消息發給該CG中的一個consumer。

如果需要實現廣播，只要每個consumer有一個獨立的CG就可以了。要實現單播只要所有的consumer在同一個CG。用CG還可以將consumer進行自由的分組而不需要多次發送消息到不同的topic；

5. Broker ：一臺kafka服務器就是一個broker。一個集群由多個broker組成。一個broker可以容納多個topic；

6. Partition：為了實現擴展性，一個非常大的topic可以分布到多個broker（即服務器）上，一個topic可以分為多個partition，每個partition是一個有序的隊列。

partition中的每條消息都會被分配一個有序的id（offset）。kafka只保證按一個partition中的順序將消息發給consumer，不保證一個topic的整體（多個partition間）的順序；

?

轉載于:https://www.cnblogs.com/duoduotouhenying/p/10221800.html

總結

以上是生活随笔為你收集整理的Kafka(1)-概述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。