02 Apache Kafka支持發布與訂閱(RabbitMQ與Kafka之間的差異)

關組件進行簡單的介紹。在介紹Kafka的架構之前，我們先了解一下Kafk的核心概念。

  在詳細介紹Kafka的架構和基本組件之前，需要先了解一下Kafka的一些核心概念。

Procer： 消息的生產者，負責往Kafka集群中發送消息；

Consumer： 消息的消費者，主動從Kafka集群中拉取消息。

Consumer Group： 每個Consumer屬于一個特定的Consumer Group，新建Consumer的時候需要指定對應的Consumer Group ID。

Broker： Kafka集群中的服務實例，也稱之為節點，每個Kafka集群包含一個或者多個Broker（一個Broker就是一個服務器或節點）。

Message： 通過Kafka集群進行傳遞的對象實體，存儲需要傳送的信息。

Topic： 消息的類別，主要用于對消息進行邏輯上的區分，每條發送到Kafka集群的消息都需要有一個指定的Topic，消費者根據Topic對指定的消息進行消費。

Partition： 消息的分區，Partition是一個物理上的概念，相當于一個文件夾，Kafka會為每個topic的每個分區創建一個文件夾，一個Topic的消息會存儲在一個或者多個Partition中。

Segment： 一個partition當中存在多個segment文件段（分段存儲），每個Segment分為兩部分，.log文件和 .index 文件，其中 .index 文件是索引文件，主要用于快速查詢.log 文件當中數據的偏移量位置；

.log文件： 存放Message的數據文件，在Kafka中把數據文件就叫做日志文件。一個分區下面默認有n多個.log文件（分段存儲）。一個.log文件大默認1G，消息會不斷追加在.log文件中，當.log文件的大小超過1G的時候，會自動新建一個新的.log文件。

.index文件： 存放.log文件的索引數據，每個.index文件有一個對應同名的.log文件。

  后面我們會對上面的一些核心概念進行更深入的介紹。在介紹完Kafka的核心概念之后，我們來看一下Kafka的對外提供的基本功能，組件及架構設計。

  如上圖所示，Kafka主要包含四個主要的API組件：

1. Procer API

  應用程序通過Procer API向Kafka集群發送一個或多個Topic的消息。

2. Consumer API

  應用程序通過Consumer API，向Kafka集群訂閱一個或多個Topic的消息，并處理這些Topic下接收到的消息。

3. Streams API

  應用程序通過使用Streams API充當流處理器（Stream Processor），從一個或者多個Topic獲取輸入流，并生產一個輸出流到一個或者多個Topic，能夠有效地將輸入流進行轉變后變成輸出流輸出到Kafka集群。

4. Connect API

  允許應用程序通過Connect API構建和運行可重用的生產者或者消費者，能夠把kafka主題連接到現有的應用程序或數據系統。Connect實際上就做了兩件事情：使用Source Connector從數據源（如：DB）中讀取數據寫入到Topic中，然后再通過Sink Connector讀取Topic中的數據輸出到另一端（如：DB），以實現消息數據在外部存儲和Kafka集群之間的傳輸。

  接下來我們將從Kafka的架構出發，重點介紹Kafka的主要組件及實現原理。Kafka支持消息持久化，消費端是通過主動拉取消息進行消息消費的，訂閱狀態和訂閱關系由客戶端負責維護，消息消費完后不會立刻刪除，會保留歷史消息，一般默認保留7天，因此可以通過在支持多訂閱者時，消息無需復制多分，只需要存儲一份就可以。下面將詳細介紹每個組件的實現原理。

1. Procer

  Procer是Kafka中的消息生產者，主要用于生產帶有特定Topic的消息，生產者生產的消息通過Topic進行歸類，保存在Kafka 集群的Broker上，具體的是保存在指定的partition 的目錄下，以Segment的方式（.log文件和.index文件）進行存儲。

2. Consumer

  Consumer是Kafka中的消費者，主要用于消費指定Topic的消息，Consumer是通過主動拉取的方式從Kafka集群中消費消息，消費者一定屬于某一個特定的消費組。

3. Topic

  Kafka中的消息是根據Topic進行分類的，Topic是支持多訂閱的，一個Topic可以有多個不同的訂閱消息的消費者。Kafka集群Topic的數量沒有限制，同一個Topic的數據會被劃分在同一個目錄下，一個Topic可以包含1至多個分區，所有分區的消息加在一起就是一個Topic的所有消息。

4. Partition

  在Kafka中，為了提升消息的消費速度，可以為每個Topic分配多個Partition，這也是就之前我們說到的，Kafka是支持多分區的。默認情況下，一個Topic的消息只存放在一個分區中。Topic的所有分區的消息合并起來，就是一個Topic下的所有消息。每個分區都有一個從0開始的編號，每個分區內的數據都是有序的，但是不同分區直接的數據是不能保證有序的，因為不同的分區需要不同的Consumer去消費，每個Partition只能分配一個Consumer，但是一個Consumer可以同時一個Topic的多個Partition。

5. Consumer Group

  Kafka中的每一個Consumer都歸屬于一個特定的Consumer Group，如果不指定，那么所有的Consumer都屬于同一個默認的Consumer Group。Consumer Group由一個或多個Consumer組成，同一個Consumer Group中的Consumer對同一條消息只消費一次。每個Consumer Group都有一個唯一的ID，即Group ID，也稱之為Group Name。Consumer Group內的所有Consumer協調在一起訂閱一個Topic的所有Partition，且每個Partition只能由一個Consuemr Group中的一個Consumer進行消費，但是可以由不同的Consumer Group中的一個Consumer進行消費。如下圖所示：

在層級關系上來說Consumer Group好比是跟Topic對應的，而Consumer就對應于Topic下的Partition。Consumer Group中的Consumer數量和Topic下的Partition數量共同決定了消息消費的并發量，且Partition數量決定了最終并發量，因為一個Partition只能由一個Consumer進行消費。當一個Consumer Group中Consumer數量超過訂閱的Topic下的Partition數量時，Kafka會為每個Partition分配一個Consumer，多出來的Consumer會處于空閑狀態。當Consumer Group中Consumer數量少于當前定于的Topic中的Partition數量是，單個Consumer將承擔多個Partition的消費工作。如上圖所示，Consumer Group B中的每個Consumer需要消費兩個Partition中的數據，而Consumer Group C中會多出來一個空閑的Consumer4。總結下來就是：同一個Topic下的Partition數量越多，同一時間可以有越多的Consumer進行消費，消費的速度就會越快，吞吐量就越高。同時，Consumer Group中的Consumer數量需要控制為小于等于Partition數量，且最好是整數倍：如1，2，4等。

6. Segment

  考慮到消息消費的性能，Kafka中的消息在每個Partition中是以分段的形式進行存儲的，即每1G消息新建一個Segment，每個Segment包含兩個文件：.log文件和.index文件。之前我們已經說過，.log文件就是Kafka實際存儲Procer生產的消息，而.index文件采用稀疏索引的方式存儲.log文件中對應消息的邏輯編號和物理偏移地址（offset），以便于加快數據的查詢速度。.log文件和.index文件是一一對應，成對出現的。下圖展示了.log文件和.index文件在Partition中的存在方式。

  Kafka里面每一條消息都有自己的邏輯offset（相對偏移量）以及存在物理磁盤上面實際的物理地址便宜量Position，也就是說在Kafka中一條消息有兩個位置：offset（相對偏移量）和position（磁盤物理偏移地址）。在kafka的設計中，將消息的offset作為了Segment文件名的一部分。Segment文件命名規則為：Partition全局的第一個Segment從0開始，后續每個segment文件名為上一個Partition的最大offset（Message的offset，非實際物理地偏移地址，實際物理地址需映射到.log中，后面會詳細介紹在.log文件中查詢消息的原理）。數值最大為64位long大小，由20位數字表示，前置用0填充。

  上圖展示了.index文件和.log文件直接的映射關系，通過上圖，我們可以簡單介紹一下Kafka在Segment中查找Message的過程：

   1. 根據需要消費的下一個消息的offset，這里假設是7，使用二分查找在Partition中查找到文件名小于（一定要小于，因為文件名編號等于當前offset的文件里存的都是大于當前offset的消息）當前offset的最大編號的.index文件，這里自然是查找到了00000000000000000000.index。

 &

很赞哦!（78182）