我挖掘Kafka底層原理！發現了它火爆宇宙的3個真相

目前市面上各類中間件層出不窮，咱們在作具體的選型時不免會糾結，在這裏闡述點粗淺的見解，其實每一箇中間件在其設計上，都有其獨有的特色或優化點，這些剛好應該是咱們所關注的，這樣才能作到物盡其用，將其特性發揮到最大；同時還要了解它們各自的劣勢，這主要爲了避坑。各類中間件就像是積木，咱們能作的，就是選擇合適形狀的積木，搭出須要的房子。

不得不說Kafka這塊積木，既能作消息中間件削峯解耦，又能作實時流處理，數據業務兩手抓，真可謂上得廳堂，下得廚房。因此Kafka系列的第一篇，想先從它的應用場景分別出發，說說是哪些技術和原理支撐了它的技術特性。

Kafka核心思想歸納

全部的消息以「有序日誌「的方式存儲，生產者將消息發佈到末端（可理解爲追加），消費者從某個邏輯位按序讀取。

【場景一】消息中間件

在選擇消息中間件時，咱們的主要關注點有：性能、消息的可靠性，順序性。

1.性能

關於Kafka的高性能，主要是由於它在實現上利用了操做系統一些底層的優化技術，儘管做爲寫業務代碼的程序員，這些底層知識也是須要了解的。

【優化一】零拷貝

這是Kafka在消費者端的優化，咱們經過兩張圖來比較一下傳統方式與零拷貝方式的區別：

傳統方式：

零拷貝方式：

終極目標：如何讓數據不通過用戶空間？

從圖中可看出，零拷貝省略了拷貝到用戶緩衝的步驟，經過文件描述符，直接從內核空間將數據複製到網卡接口。

【優化二】順序寫入磁盤

寫入消息時，採用文件追加的方式，而且不容許修改已經寫入的消息，因而寫入磁盤的方式是順序寫入。咱們一般認爲的基於磁盤讀寫性能較差，指的是基於磁盤的隨機讀寫；事實上，基於磁盤的順序讀寫，性能接近於內存的隨機讀寫，如下是性能對比圖：

【優化三】內存映射

歸納：用戶空間的一段內存區域映射到內核空間，這樣，不管是內核空間或用戶空間對這段內存區域的修改，均可以直接映射到另外一個區域。

優點：若是內核態和用戶態存在大量的數據傳輸，效率是很是高的。

爲何會提升效率：歸納來說，傳統方式爲read()系統調用，進行了兩次數據拷貝；內存映射方式爲mmap()系統調用，只進行一次數據拷貝

【優化四】批量壓縮

生產者：批量發送消息集

消費者：主動拉取數據，一樣採用批量拉取的方式

2.可靠性

Kafka的副本機制是保證其可靠性的核心。

關於副本機制，我將它理解爲Leader-Follower機制，就是多個服務器中有相同數據的多個副本，而且劃分的粒度是分區。很明顯，這樣的策略就有下面幾個問題必須解決：

各副本間如何同步？

ISR機制：Leader動態維護一個ISR（In-Sync Replica）列表，

Leader故障，如何選舉新的Leader？

要想解決這個問題，就要引出Zookeeper，它是Kafka實現副本機制的前提，關於它的原理且聽下回分解，本篇仍是從Kafka角度進行分析。在這裏咱們只須要了解，一些關於Broker、Topics、Partitions的元信息存儲在Zookeeper中，Leader發生故障時，從ISR集合中進行選舉新的Leader。

request.required.acks來設置數據的可靠性：

分區機制和副本機制知識點：

3.順序性

順序性保證主要依賴於分區機制 + 偏移量。

提到分區，首先就要解釋一下相關的概念以及他們之間的關係，我的總結以下幾點：

服務器（Broker）：指一個獨立的服務器

主題（Topic）：消息的邏輯分類，可跨Broker

分區（Partition）：消息的物理分類，基本的存儲單元

這裏盜一張圖闡述上述概念間的關係

爲何分區機制能夠保證消息的順序性？

Kafka能夠保證一個分區內消息是有序且不可變的。

生產者：Kafka的消息是一個鍵值對，咱們經過設置鍵值，指定消息被髮送到特定主題的特定分區。

能夠經過設置key，將同一類型的消息，發到同一個分區，就能夠保證消息的有序性。

消費者：消費者須要經過保存偏移量，來記錄本身消費到哪一個位置，在0.10版本前，偏移量保存在zk中，後來保存在 __consumeroffsets topic中。

【場景二】流處理

在0.10版本後，Kafka內置了流處理框架API——Kafka Streams，一個基於Kafka的流式處理類庫，它利用了上述，至此，Kafka也就隨之發展成爲一個囊括消息系統、存儲系統、流處理系統的中央式的流處理平臺。

與已有的Spark Streaming平臺不一樣的是，Spark Streaming或Flink是一個是一個系統架構，而Kafka Streams屬於一個庫。Kafka Streams秉承簡單的設計原則，優點體如今運維上。同時Kafka Streams保持了上面提到的全部特性。

關於兩者適合的應用場景，已有大佬給出告終論，就不強行總結了。

Kafka Streams：適合」Kafka --> Kafka「場景

Spark Streaming：適合」Kafka --> 數據庫」或「Kafka --> 數據科學模型「場景

最後分享一份面試寶典【Java核心知識點整理】覆蓋了JVM、鎖、高併發、反射、Spring原理、微服務、Zookeeper、數據庫、數據結構等等」，還有Java208道面試題（含答案）！

加入個人粉絲羣（Java填坑之路：659655594）便可免費獲取到！掌握了這些知識點，面試時在候選人中又能夠奪目很多，暴擊9999點。機會都是留給有準備的人，只有充足的準備，纔可能讓本身能夠在候選人中脫穎而出。