Kafka實戰－入門

1.概述

　　通過一個多月的時間觀察，業務上在集成Kafka後，各方面還算穩定，這裏打算抽時間給你們分享一下Kafka在實際場景中的一些使用心得。本篇博客打算先給你們入個門，讓你們對Kafka有個初步的瞭解，知道Kafka是作什麼的，下面是本篇博客的目錄內容：

• Kafka背景
• Kafka應用場景
• Kafka架構原理

　　下面開始今天的博客分享內容。

2.Kafka背景

　　Kafka它本質上是一個消息系統，由當時從LinkedIn出來創業的三人小組開發，他們開發出了Apache Kafka實時信息隊列技術，該技術致力於爲各行各業的公司提供實時數據處理服務解決方案。Kafka爲LinkedIn的中樞神經系統，管理從各個應用程序的匯聚，這些數據通過處理後再被分發到其餘地方。Kafka不一樣於傳統的企業信息隊列系統，它是以近乎實時的方式處理流經一個公司的全部數據，目前已經服務於LinkedIn、Netflix、Uber以及Verizon，併爲此創建了實時信息處理平臺。

　　流水數據是全部站點對其網站使用狀況作報表時都要用到的數據中最經常使用的一部分，流水數據包括PV，瀏覽內容信息以及搜索記錄等。這些數據一般是先以日誌文件的形式存在，而後有周期的去對這些日誌文件進行統計分析處理，而後得到須要的KPI指標結果。

3.Kafka應用場景

　　咱們在接觸一門新技術或是新語言時，得明白這門技術（或是語言）的應用場景，也就說要明白它能作什麼，服務的對象是誰，下面用一個圖來講明，以下圖所示：

　　首先，Kafka能夠應用於消息系統，好比，當下較爲熱門的消息推送，這些消息推送系統的消息源，可使用Kafka做爲系統的核心組建來完成消息的生產和消息的消費。而後是網站的行跡，咱們能夠將企業的Portal，用戶的操做記錄等信息發送到Kafka中，按照實際業務需求，能夠進行實時監控，或者作離線處理等。最後，一個是日誌收集，相似於Flume套件這樣的日誌收集系統，但Kafka的設計架構採用push/pull，適合異構集羣，Kafka能夠批量提交消息，對Producer來講，在性能方面基本上是無消耗的，而在Consumer端中，咱們可使用HDFS這類的分佈式文件存儲系統進行存儲。

4.Kafka架構原理

　　Kafka的設計之初是但願作一個統一的信息收集平臺，可以實時的收集反饋信息，而且具備良好的容錯能力。Kafka中咱們最直觀的感覺就是它的消費者與生產者，以下圖所示：

4.1Producer And Consumer

　　這裏Kafka對消息的保存是根據Topic進行歸類的，由消息生產者（Producer）和消息消費者（Consumer）組成，另外，每個Server稱爲一個Broker。對於Kafka集羣而言，Producer和Consumer都依賴於ZooKeeper來保證數據的一致性。

4.2Topic

　　在每條消息輸送到Kafka集羣后，消息都會由一個Type，這個Type被稱爲一個Topic，不一樣的Topic的消息是分開存儲的。以下圖所示：

　　一個Topic會被歸類爲一則消息，每一個Topic能夠被分割爲多個Partition，在每條消息中，它在文件中的位置稱爲Offset，用於標記惟一一條消息。在Kafka中，消息被消費後，消息仍然會被保留必定時間後在刪除，好比在配置信息中，文件信息保留7天，那麼7天后，無論Kafka中的消息是否被消費，都會被刪除；以此來釋放磁盤空間，減小磁盤的IO消耗。

　　在Kafka中，一個Topic的多個分區，被分佈在Kafka集羣的多個Server上，每一個Server負責分區中消息的讀寫操做。另外，Kafka還能夠配置分區須要備份的個數，以便提升可用行。因爲用到來ZK來協調，每一個分區都有一個Server爲Leader狀態，服務對外響應（如讀寫操做），若該Leader宕機，會由其餘的Follower來選舉出新的Leader來保證集羣的高可用性。

5.總結

　　整體來講，介紹Kafka的相關背景，概述及原理，這些較爲偏理論，概念性較強，須要你們認真的去理解、琢磨，這裏能夠大體熟悉一下，心中有個輪廓，後面會陸續介紹Kafka的實戰用法，讓你們在實際業務和編碼中去體會Kafka的這些原理。

6.結束語

　　這篇博客就和你們分享到這裏，若是你們在研究學習的過程中有什麼問題，能夠加羣進行討論或發送郵件給我，我會盡我所能爲您解答，與君共勉！