Kafka學習筆記（2）----Kafka的架構

 

1. 架構圖

　　

　　一個Kafka集羣中包含若干個Broker(消息實例)，Kafka支持Broker橫向擴展，Broker越多，吞吐量越大，同時也包含了若干個Producer(能夠是web前端產生的Page View，或者是服務器日誌，系統CPU、Memory等）和若干個Consumer(消費者)以及一個zookeeper集羣，Kafka經過Zookeeper管理集羣配置，選舉leader，以及在Consumer Group發生變化時進行rebalance。Producer使用push模式將消息發佈到broker，Consumer使用pull模式從broker訂閱並消費消息。

2. Topic和Partition

　　

 

 　　Topic：是一個邏輯的概念，它能夠認爲相似於其餘中間件中queue的概念，做爲一組消息的一個集合，跟其餘的消息中間件同樣，每一個消息的發送或者是消費都必需要指定Topic，代表將消息存在哪一個Topic中。一個Topic能夠接受多個Producer發送的消息和被多個Consumer消費。

　　Partition：了使得Kafka的吞吐率能夠線性提升，物理上把Topic分紅一個或多個Partition，每一個Partition在物理上對應一個文件夾，該文件夾下存儲這個Partition的全部消息和索引文件，贊成Topic下不一樣分區包含的消息是不一樣的，當每一個消息發送到分區時，都會分配到一個offset（偏移量）它是消息在此分區中的惟一編號，kafka經過offset保證消息在分區內的順序，offset的順序不跨分區，即kafka只保證在同一個分區內的消息是有序的；Partition是以文件的形式存儲在文件系統中，存儲在kafka-log目錄下，命名規則爲<topic_name>-<partition_id>，如新建一個Topic，

　　

　　查看kafka_log目錄

　　

3. kafka高吞吐量的緣由

　　由於每條消息都被append到該Partition中，屬於順序寫磁盤，所以效率很是高，順序寫磁盤效率比隨機寫內存還要高，這是Kafka高吞吐率的一個很重要的保證。

　　對於傳統的message queue而言，通常會刪除已經被消費的消息，而Kafka集羣會保留全部的消息，不管其被消費與否。固然，由於磁盤限制，不可能永久保留全部數據（實際上也不必），所以Kafka提供兩種策略刪除舊數據。一是基於時間，二是基於Partition文件大小。例如能夠經過配置$KAFKA_HOME/config/server.properties，讓Kafka刪除一週前的數據，也可在Partition文件超過1GB時刪除舊數據，配置以下所示。

#The minimum age of a log file to be eligible for deletion
log.retention.hours=168
# The maximum size of a log segment file. When this size is reached a new log segment will be created.
log.segment.bytes=1073741824
# The interval at which log segments are checked to see if they can be deleted according to the retention policies
log.retention.check.interval.ms=300000
# If log.cleaner.enable=true is set the cleaner will be enabled and individual logs can then be marked for log compaction.
log.cleaner.enable=false

　　由於Kafka讀取特定消息的時間複雜度爲O(1)，即與文件大小無關，因此這裏刪除過時文件與提升Kafka性能無關。選擇怎樣的刪除策略只與磁盤以及具體的需求有關。另外，Kafka會爲每個Consumer Group保留一些metadata信息——當前消費的消息的position，也即offset。這個offset由Consumer控制。正常狀況下Consumer會在消費完一條消息後遞增該offset。固然，Consumer也可將offset設成一個較小的值，從新消費一些消息。由於offset由Consumer控制，因此Kafka broker是無狀態的，它不須要標記哪些消息被哪些消費過，也不須要經過broker去保證同一個Consumer Group只有一個Consumer能消費某一條消息，所以也就不須要鎖機制，這也爲Kafka的高吞吐率提供了有力保障。

　　在異步消息發送模式中，kafka容許進行批量發送，也就是先講消息緩存到內存中，而後一次請求批量發送出去。這樣減小了磁盤頻繁io以及網絡IO形成的性能瓶頸。

　　零拷貝也是提升吞吐量的一個點。