一、Kafka快速入門祕籍：背景介紹，應用場景分析、核心架構分析

1、背景介紹

引言：其實這段背景，咱們以前介紹RabbitMQ的時候，已經說過了，咱們這裏講kakfa的時候，再把這一段給拿出來，再說明下。在講實戰前，咱們仍是有必要講解下理論的，理論爲輔，實戰爲主，在實戰的基礎上，再深刻理解理論，底層原理，底層源碼。下篇文章或者視頻，咱們將帶你看官網學習kafka環境搭建、kafka基本用法、kafka的容錯性測試，在掌握知識的同時，還能順便學習下英文。

1）問題引入：

假設咱們如今須要設計這樣一個用戶註冊系統：用戶註冊完成後，須要給用戶發送激活郵件，開通用戶帳號，記錄用戶IP、用戶設備、時間等信息。

起初的設計：

2）但存在的問題是：

因爲多個系統強耦合在一塊兒，用戶註冊響應會很是慢，嚴重影響了用戶的體驗，當流量大的時候，性能會更差。

3）引入消息中間件：

爲了解決上述問題，咱們引入消息中間件，來實現系統的解耦，多個系統間經過消息中間件進行異步通訊，最終的設計圖以下：

即實現了系統解耦，又提高了系統響應的速度

4）消息中間件介紹：

消息中間件（Message Queue Middleware，簡稱MQ）又稱爲消息隊列，是指利用高效可靠的消息傳遞機制進行與平臺無關的數據交流，並基於數據通訊來進行分佈式系統的構建。

二、應用場景分析

1）異步通訊

在不少時候，爲了加快應用系統總體運轉速度，並不須要當即響應某些請求，消息中間件提供了異步處理機制，容許將一些請求信息放入消息中間件中，但並不當即處理它，而是慢慢處理。在有限資源下，使用消息中間件可以使系統性能從容倍增！

如：用戶註冊成功的郵件通知；用戶購物下單的信息通知；大數據日誌收集處理

2）削峯

以防突發劇增流量瞬間沖垮系統，使用消息中間件能夠支撐突發訪問壓力

3）業務系統解耦

系統間的耦合關係太強，會對系統的設計產生束縛，也會增長系統的複雜性，經過消息中間件能夠更好的設計系統，是一個系統完成指定的功能，而不是將全部的功能融合在同一個系統中。

2、kafka簡介

Kafka做爲一種消息中間件，是一種分佈式的，基於發佈/訂閱的消息系統。主要設計目標以下：

• 以時間複雜度爲O(1)的方式提供消息持久化能力，即便對TB級以上數據也能保證常數時間的訪問性能
• 高吞吐率。即便在很是廉價的商用機器上也能作到單機支持每秒100K條消息的傳輸
• 支持Kafka Server間的消息分區，及分佈式消費，同時保證每一個partition內的消息順序傳輸
• 同時支持離線數據處理和實時數據處理

一、kafka架構

名詞解釋：

• Broker 
  一個Kafka集羣由一個或多個broker組成。搭建了kafka環境的服務器就能夠稱爲broker。

• Topic 
  Kafka集羣上存儲的消息都有一個類別，這個類別被稱爲topic。（使用者只需指定消息的topic，便可生產或消費數據而沒必要關心數據存於何處）Topic在邏輯上能夠被認爲是一個queue。每條消費都必須指定它的topic，能夠簡單理解爲必須指明把這條消息放進哪一個queue裏，這與RabbitMQ就有點相似了。

• Partition 
  爲了使得Kafka的吞吐率能夠水平擴展，物理上又把topic分紅一個或多個partition，每一個partition在物理上對應一個文件夾，該文件夾下存儲這個partition的全部消息和索引文件。建立topic時可指定parition數量。咱們實戰演示的時候，會再次說明。

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

• Producer 
  負責發佈消息到Kafka broker

• Consumer 
  消費消息。每一個consumer屬於一個特定的consumer group（可爲每一個consumer指定group name，若不指定group name則屬於默認的group）。同一topic的一條消息只能被同一個consumer group內的一個consumer消費，但多個consumer group可同時消費這一消息。

3、kafka其它核心概念

一、消息存儲

不少傳統的message queue都會在消息被消費完後將消息刪除，一方面避免重複消費，另外一方面能夠保證queue的長度比較少，提升效率。而Kafka集羣會保留全部的消息，不管其被消費與否。固然，由於磁盤限制，不可能永久保留全部數據（實際上也不必），所以Kafka提供兩種策略去刪除舊數據。一是基於時間，二是基於partition文件大小。例如能夠經過配置$KAFKA_HOME/config/server.properties，讓Kafka刪除一週前的數據，也可經過配置讓Kafka在partition文件超過1GB時刪除舊數據。

二、Consumer Group

每個consumer實例都屬於一個consumer group，每一條消息只會被同一個consumer group裏的一個consumer實例消費。（不一樣consumer group能夠同時消費同一條消息） 
Kafka保證的是穩定狀態下每個consumer實例只會消費某一個或多個特定partition的數據，而某個partition的數據只會被某一個特定的consumer實例所消費。這樣設計的劣勢是沒法讓同一個consumer group裏的consumer均勻消費數據，優點是每一個consumer不用都跟大量的broker通訊，減小通訊開銷，同時也下降了分配難度，實現也更簡單。另外，由於同一個partition裏的數據是有序的，這種設計能夠保證每一個partition裏的數據也是有序被消費。

三、Consumer Rebalance

Kafka經過Zookeeper管理集羣配置，在consumer group發生變化時（如：某個consumer因故障下線時）進行rebalance。具體含義爲：

• 若是某consumer group中consumer數量少於partition數量，則至少有一個consumer會消費多個partition的數據，
• 若是consumer的數量與partition數量相同，則正好一個consumer消費一個partition的數據，
• 而若是consumer的數量多於partition的數量時，會有部分consumer沒法消費該topic下任何一條消息。

下篇文章，就是實戰爲主了：帶你閱讀官網完成基本使用、容錯性測試

若是你以爲文章還能夠，歡迎掃一下：

更多內容，請關注：頭條號（極客慧）

更多資料分享，問題諮詢，能夠入羣討論：375412858

文章中用到的源碼，請入羣索要：