Kafka

官網： Apache Kafka http://kafka.apache.org/

kafka 簡介

       kafka是一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者規模的網站中的所有動作流資料。這種動作（網頁瀏覽，搜尋和其他使用者的行動）是在現代網路上的許多社會功能的一個關鍵因素。這些資料通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。

     Kafka是由Apache軟體基金會開發的一個開源流處理平臺，由Scala和Java編寫。Kafka是一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者規模的網站中的所有動作流資料。 這種動作（網頁瀏覽，搜尋和其他使用者的行動）是在現代網路上的許多社會功能的一個關鍵因素。 這些資料通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。 對於像Hadoop的一樣的日誌資料和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的訊息處理，也是為了通過叢集來提供實時的訊息。

kafka 基礎知識梳理

Kafka是分散式釋出-訂閱訊息系統。它最初由LinkedIn公司開發，之後成為Apache專案的一部分。Kafka是一個分散式的，可劃分的，冗餘備份的永續性的日誌服務。它主要用於處理活躍的流式資料。

在大資料系統中，常常會碰到一個問題，整個大資料是由各個子系統組成，資料需要在各個子系統中高效能，低延遲的不停流轉。傳統的企業訊息系統並不是非常適合大規模的資料處理。為了已在同時搞定線上應用（訊息）和離線應用（資料檔案，日誌）Kafka就出現了。Kafka可以起到兩個作用：

1. 降低系統組網複雜度。
2. 降低程式設計複雜度，各個子系統不在是相互協商介面，各個子系統類似插口插在插座上，Kafka承擔高速資料匯流排的作用。

Kafka主要特點：

1. 同時為釋出和訂閱提供高吞吐量。據瞭解，Kafka每秒可以生產約25萬訊息（50 MB），每秒處理55萬訊息（110 MB）。
2. 可進行持久化操作。將訊息持久化到磁碟，因此可用於批量消費，例如ETL，以及實時應用程式。通過將資料持久化到硬碟以及replication防止資料丟失。
3. 分散式系統，易於向外擴充套件。所有的producer、broker和consumer都會有多個，均為分散式的。無需停機即可擴充套件機器。
4. 訊息被處理的狀態是在consumer端維護，而不是由server端維護。當失敗時能自動平衡。
5. 支援online和offline的場景。

kafka應用場景：
       構建實時的流資料管道，可靠地獲取系統和應用程式之間的資料。
       構建實時流的應用程式，對資料流進行轉換或反應。

 kafka基基原理:

       通常來講，訊息模型可以分為兩種：佇列和釋出-訂閱式。佇列的處理方式是一組消費者從伺服器讀取訊息，一條訊息只有其中的一個消費者來處理。在釋出-訂閱模型中，訊息被廣播給所有的消費者，接收到訊息的消費者都可以處理此訊息。Kafka為這兩種模型提供了單一的消費者抽象模型： 消費者組(consumer group)。消費者用一個消費者組名標記自己。

       一個釋出在Topic上訊息被分發給此消費者組中的一個消費者。假如所有的消費者都在一個組中，那麼這就變成了queue模型。假如所有的消費者都在不同的組中，那麼就完全變成了釋出-訂閱模型。更通用的， 我們可以建立一些消費者組作為邏輯上的訂閱者。每個組包含數目不等的消費者，一個組內多個消費者可以用來擴充套件效能和容錯。       

       並且，kafka能夠保證生產者傳送到一個特定的Topic的分割槽上，訊息將會按照它們傳送的順序依次加入，也就是說，如果一個訊息M1和M2使用相同的producer傳送，M1先傳送，那麼M1將比M2的offset低，並且優先的出現在日誌中。消費者收到的訊息也是此順序。如果一個Topic配置了複製因子（replication facto）為N,那麼可以允許N-1伺服器當機而不丟失任何已經提交（committed）的訊息。此特性說明kafka有比傳統的訊息系統更強的順序保證。但是，相同的消費者組中不能有比分割槽更多的消費者，否則多出的消費者一直處於空等待，不會收到訊息。

                                                                    Kafka的架構：

kafka名詞解釋

• producer：生產者。
• consumer：消費者。
• topic: 訊息以topic為類別記錄,Kafka將訊息種子(Feed)分門別類,每一類的訊息稱之為一個主題(Topic)。
• broker：以叢集的方式執行,可以由一個或多個服務組成，每個服務叫做一個broker;消費者可以訂閱一個或多個主題(topic),並從Broker拉資料,從而消費這些已釋出的訊息。

      每個訊息（也叫作record記錄,也被稱為訊息）是由一個key，一個value和時間戳構成。

kafka有四個核心API介紹

• 應用程式使用producer API釋出訊息到1個或多個topic中。
• 應用程式使用consumer API來訂閱一個或多個topic,並處理產生的訊息。
• 應用程式使用streams API充當一個流處理器,從1個或多個topic消費輸入流,併產生一個輸出流到1個或多個topic,有效地將輸入流轉換到輸出流。
• connector API允許構建或執行可重複使用的生產者或消費者,將topic連結到現有的應用程式或資料系統。 

Kafka的整體架構非常簡單，是顯式分散式架構，producer、broker（kafka）和consumer都可以有多個。Producer，consumer實現Kafka註冊的介面，資料從producer傳送到broker，broker承擔一箇中間快取和分發的作用。broker分發註冊到系統中的consumer。broker的作用類似於快取，即活躍的資料和離線處理系統之間的快取。客戶端和伺服器端的通訊，是基於簡單，高效能，且與程式語言無關的TCP協議。幾個基本概念：

1. Topic：特指Kafka處理的訊息源（feeds of messages）的不同分類。
2. Partition：Topic物理上的分組，一個topic可以分為多個partition，每個partition是一個有序的佇列。partition中的每條訊息都會被分配一個有序的id（offset）。
3. Message：訊息，是通訊的基本單位，每個producer可以向一個topic（主題）釋出一些訊息。
4. Producers：訊息和資料生產者，向Kafka的一個topic釋出訊息的過程叫做producers。
5. Consumers：訊息和資料消費者，訂閱topics並處理其釋出的訊息的過程叫做consumers。
6. Broker：快取代理，Kafka叢集中的一臺或多臺伺服器統稱為broker。

                                                             訊息傳送的流程：

1. Producer根據指定的partition方法（round-robin、hash等），將訊息釋出到指定topic的partition裡面
2. kafka叢集接收到Producer發過來的訊息後，將其持久化到硬碟，並保留訊息指定時長（可配置），而不關注訊息是否被消費。
3. Consumer從kafka叢集pull資料，並控制獲取訊息的offset

Kafka的設計：

1、吞吐量

高吞吐是kafka需要實現的核心目標之一，為此kafka做了以下一些設計：

1. 資料磁碟持久化：訊息不在記憶體中cache，直接寫入到磁碟，充分利用磁碟的順序讀寫效能
2. zero-copy：減少IO操作步驟
3. 資料批量傳送
4. 資料壓縮
5. Topic劃分為多個partition，提高parallelism

負載均衡

1. producer根據使用者指定的演算法，將訊息傳送到指定的partition
2. 存在多個partiiton，每個partition有自己的replica，每個replica分佈在不同的Broker節點上
3. 多個partition需要選取出lead partition，lead partition負責讀寫，並由zookeeper負責fail over
4. 通過zookeeper管理broker與consumer的動態加入與離開

拉取系統

由於kafka broker會持久化資料，broker沒有記憶體壓力，因此，consumer非常適合採取pull的方式消費資料，具有以下幾點好處：

1. 簡化kafka設計
2. consumer根據消費能力自主控制訊息拉取速度
3. consumer根據自身情況自主選擇消費模式，例如批量，重複消費，從尾端開始消費等

可擴充套件性

當需要增加broker結點時，新增的broker會向zookeeper註冊，而producer及consumer會根據註冊在zookeeper上的watcher感知這些變化，並及時作出調整。

Kafka的應用場景：

1.訊息佇列

比起大多數的訊息系統來說，Kafka有更好的吞吐量，內建的分割槽，冗餘及容錯性，這讓Kafka成為了一個很好的大規模訊息處理應用的解決方案。訊息系統一般吞吐量相對較低，但是需要更小的端到端延時，並常常依賴於Kafka提供的強大的永續性保障。在這個領域，Kafka足以媲美傳統訊息系統，如ActiveMR或RabbitMQ。

2.行為跟蹤

Kafka的另一個應用場景是跟蹤使用者瀏覽頁面、搜尋及其他行為，以釋出-訂閱的模式實時記錄到對應的topic裡。那麼這些結果被訂閱者拿到後，就可以做進一步的實時處理，或實時監控，或放到hadoop/離線資料倉儲裡處理。

3.元資訊監控

作為操作記錄的監控模組來使用，即彙集記錄一些操作資訊，可以理解為運維性質的資料監控吧。

4.日誌收集

日誌收集方面，其實開源產品有很多，包括Scribe、Apache Flume。很多人使用Kafka代替日誌聚合（log aggregation）。日誌聚合一般來說是從伺服器上收集日誌檔案，然後放到一個集中的位置（檔案伺服器或HDFS）進行處理。然而Kafka忽略掉檔案的細節，將其更清晰地抽象成一個個日誌或事件的訊息流。這就讓Kafka處理過程延遲更低，更容易支援多資料來源和分散式資料處理。比起以日誌為中心的系統比如Scribe或者Flume來說，Kafka提供同樣高效的效能和因為複製導致的更高的耐用性保證，以及更低的端到端延遲。

5.流處理

這個場景可能比較多，也很好理解。儲存收集流資料，以提供之後對接的Storm或其他流式計算框架進行處理。很多使用者會將那些從原始topic來的資料進行階段性處理，彙總，擴充或者以其他的方式轉換到新的topic下再繼續後面的處理。例如一個文章推薦的處理流程，可能是先從RSS資料來源中抓取文章的內容，然後將其丟入一個叫做“文章”的topic中；後續操作可能是需要對這個內容進行清理，比如回覆正常資料或者刪除重複資料，最後再將內容匹配的結果返還給使用者。這就在一個獨立的topic之外，產生了一系列的實時資料處理的流程。Strom和Samza是非常著名的實現這種型別資料轉換的框架。

6.事件源

事件源是一種應用程式設計的方式，該方式的狀態轉移被記錄為按時間順序排序的記錄序列。Kafka可以儲存大量的日誌資料，這使得它成為一個對這種方式的應用來說絕佳的後臺。比如動態彙總（News feed）。

7.永續性日誌（commit log）

Kafka可以為一種外部的永續性日誌的分散式系統提供服務。這種日誌可以在節點間備份資料，併為故障節點資料回覆提供一種重新同步的機制。Kafka中日誌壓縮功能為這種用法提供了條件。在這種用法中，Kafka類似於Apache BookKeeper專案。

Kafka的設計要點：

1、直接使用linux 檔案系統的cache，來高效快取資料。

2、採用linux Zero-Copy提高傳送效能。傳統的資料傳送需要傳送4次上下文切換，採用sendfile系統呼叫之後，資料直接在核心態交換，系統上下文切換減少為2次。根據測試結果，可以提高60%的資料傳送效能。Zero-Copy詳細的技術細節可以參考：https://www.ibm.com/developerworks/linux/library/j-zerocopy/

3、資料在磁碟上存取代價為O(1)。kafka以topic來進行訊息管理，每個topic包含多個part（ition），每個part對應一個邏輯log，有多個segment組成。每個segment中儲存多條訊息（見下圖），訊息id由其邏輯位置決定，即從訊息id可直接定位到訊息的儲存位置，避免id到位置的額外對映。每個part在記憶體中對應一個index，記錄每個segment中的第一條訊息偏移。釋出者發到某個topic的訊息會被均勻的分佈到多個part上（隨機或根據使用者指定的回撥函式進行分佈），broker收到釋出訊息往對應part的最後一個segment上新增該訊息，當某個segment上的訊息條數達到配置值或訊息釋出時間超過閾值時，segment上的訊息會被flush到磁碟，只有flush到磁碟上的訊息訂閱者才能訂閱到，segment達到一定的大小後將不會再往該segment寫資料，broker會建立新的segment。

4、顯式分散式，即所有的producer、broker和consumer都會有多個，均為分散式的。Producer和broker之間沒有負載均衡機制。broker和consumer之間利用zookeeper進行負載均衡。所有broker和consumer都會在zookeeper中進行註冊，且zookeeper會儲存他們的一些後設資料資訊。如果某個broker和consumer發生了變化，所有其他的broker和consumer都會得到通知。

一. Concepts

Kafka is used for building real-time data pipelines and streaming apps

• 分散式訊息傳遞
• 網站活躍資料跟蹤
• 日誌聚合
• 流式資料處理
• 資料儲存
• 事件源
• ……

Kafka terminology 術語

1.Topics

Kafka maintains feeds of messages in categories called topics. 
訊息都歸屬於一個類別成為topic,在物理上不同Topic的訊息分開儲存,邏輯上一個Topic的訊息對使用者透明 

2.Partitions

Topics are broken up into ordered commit logs called partitions 
每個Topics劃分為一個或者多個Partition,並且Partition中的每條訊息都被標記了一個sequential id ,也就是offset,並且儲存的資料是可配置儲存時間的 

3.Message Ordering

訊息只保證在同一個Partition中有序,所以,如果要保證從Topic中拿到的資料有序,則需要做到:

• Group messages in a partition by key(producer)
• Configure exactly one consumer instance per partition within a consumer group

kafka能保證的是:

• Message sent by a producer to a particular topic partition will be appended in the order they are sent
• A consumer instance sees messages in the order they are stored in the log
• For a topic with replication factor N, kafka can tolerate up to N-1 server failures without “losing” any messages committed to the log

4.Log

Partition對應邏輯上的Log

5.Replication 副本

• Topics can (and should) be replicated
• The unit of replication is the partition
• Each partition in a topic has 1 leader and 0 or more replicas

• A replica is deemed to be “in-sync” if

  • The replica can communicate with Zookeeper
  • The replica is not “too far” behind the leader(configurable)

• The group of in-sync replicas for a partition is called the ISR(In-Sync-Replicas)

• The Replication factor cannot be lowered

6.kafka durability 可靠性

Durability can be configured with the producer configuration request.required.acks

• 0 : The producer never waits for an ack
• 1 : The producer gets an ack after the leader replica has received the data
• -1 : The producer gets an ack after all ISRs receive the data

Minimum available ISR can also be configured such that an error is returned if enough replicas are not available to replicate data

所以,kafka可以選擇不同的durability來換取不同的吞吐量

Durability	Behaviour	Per Event Latency	Required Acknowledgements(request.required.acks)
Hignest	ACK all ISRs have received	Higest	-1
Medium	ACK once the leader has received	Medium	1
Lowest	No ACKs required	Lowest	0

通用,kafka可以通過增加更多的Broker來提升吞吐量 
一個推薦的配置:

Property	Value
replication	3
min.insync.replicas	2
request.required.acks	-1

7.Broker

Kafka is run as a cluster comparised of one or more servers each of which is called broker 

8.Producer

Processes that publish messages to a kafka topic are called producers

• Producers publish to a topic of their choosing(push) 
  資料載入kafka可以是分散式的,通常是通過”Round-Robin”演算法策略,也可以根據message中的key來進行語義分割”semantic partitioning”來分散式載入,Brokers 通過分割槽來均衡載入
• kafka支援非同步傳送async,非同步傳送訊息是less durable的,但是是高吞吐的
• Producer的載入平衡和ISRs 
  

9.Consumer

Processes that subscribe(訂閱) to tpics and process the feed of published messages are called consumers

• Multiple Consumer can read from the same topic
• Each Consumer is responsible for managing it’s own offset
• Message stay on kafka… they are not removed after they consumed 
  

Consumer可以從任一地方開始消費,然後又回到最大偏移量處,Consumers又可以被劃分為Consumer Group

10.Consumer Group

Consumer Group是顯式分散式,多個Consumer構成組結構,Message只能傳輸給某個Group中的某一個Consumer

• 常用的Consumer Group模式:

  • All consumer instances in one group 
    Acts like a traditional queue with load balancing
  • All consumer instances in different groups 
    All messages are broadcast to all consumer instances
  • “Logical Subscriber” - Many consumer instances in a group 
    Consumers are added for scalability and fault tolerance,Each consumer instance reads from one or more partitions for a topic ,There cannot be more consumer instances than partitions

 
Consumer Groups 提供了topics和partitions的隔離 
 
並且當某個Consumer掛掉後能夠重新平衡

• Consumer Group的應用場景

  • 點對點 
    將所有消費者放到一個Consumer Group
  • 廣播 
    將每個消費者單獨放到一個Consumer Group
  • 水平擴充套件 
    向Consumer Group中新增消費者並進行Rebalance
  • 故障轉移 
    當某個Consumer發生故障時,Consumer Group重新分配分割槽

二. Kafka 核心原理

Kafka設計思想

• 可持久化Message 
  持久化本地檔案系統,設定有效期
• 支援高流量處理 
  面向特定的使用場景而不是通用功能
• 消費狀態儲存在消費端而不是服務端 
  減輕伺服器負擔和互動
• 支援分散式 
  生產者/消費者透明非同步
• 依賴磁碟檔案系統做訊息快取 
  不消耗記憶體
• 高效的磁碟存取 
  複雜度為O(1)
• 強調減少資料的序列化和拷貝開銷 
  批量儲存和傳送、zero-copy
• 支援資料並行載入到Hadoop 
  整合Hadoop

Kafka原理分析

1.儲存

• Partition 
  topic物理上的分組，一個topic可以分為多個partition，每個partition是一個有序的佇列。 
  在Kafka檔案儲存中，同一個topic下有多個不同partition，每個partition為一個目錄，partiton命名規則為topic名稱+有序序號，第一個partiton序號從0開始，序號最大值為partitions數量減1 
   
  每個partion(目錄)相當於一個巨型檔案被平均分配到多個大小相等segment(段)資料檔案中。但每個段segment file訊息數量不一定相等，這種特性方便old segment file快速被刪除。 
  每個partiton只需要支援順序讀寫就行了，segment檔案生命週期由服務端配置引數決定。 
  這樣做的好處就是能快速刪除無用檔案，有效提高磁碟利用率。

• segment file

  • segment file組成：由2大部分組成，分別為index file和data file，此2個檔案一一對應，成對出現，字尾”.index”和“.log”分別表示為segment索引檔案、資料檔案.
  • segment檔案命名規則：partion全域性的第一個segment從0開始，後續每個segment檔名為上一個segment檔案最後一條訊息的offset值。數值最大為64位long大小，19位數字字元長度，沒有數字用0填充。

 
其中.index索引檔案儲存大量後設資料，.log資料檔案儲存大量訊息，索引檔案中後設資料指向對應資料檔案中message的物理偏移地址。他們兩個是一一對應的,對應關係如下 

• Message 
  segment data file由許多message組成，message物理結構如下 
  

引數說明:

關鍵字	解釋說明
8 byte offset	在parition(分割槽)內的每條訊息都有一個有序的id號，這個id號被稱為偏移(offset),它可以唯一確定每條訊息在parition(分割槽)內的位置。即offset表示partiion的第多少message
4 byte message size	message大小
4 byte CRC32	用crc32校驗message
1 byte “magic”	表示本次釋出Kafka服務程式協議版本號
1 byte “attributes”	表示為獨立版本、或標識壓縮型別、或編碼型別。
4 byte key length	表示key的長度,當key為-1時，K byte key欄位不填
K byte key	可選
value bytes payload	表示實際訊息資料。

2. Consumer

• High Level Consumer 
  消費者儲存消費狀態：將從某個Partition讀取的最後一條訊息的offset存於ZooKeeper中
• Low Level Consumer：更好的控制資料的消費 
  同一條訊息讀多次 
  只讀取某個Topic的部分Partition 
  管理事務，從而確保每條訊息被處理一次，且僅被處理一次 
  大量額外工作 
  必須在應用程式中跟蹤offset，從而確定下一條應該消費哪條訊息 
  應用程式需要通過程式獲知每個Partition的Leader是誰 
  必須處理Leader的變化

3.訊息傳遞語義Delivery Semantics

• At least once 
  kafka的預設設定 
  Messages are never lost but maybe redelivered
• At most once 
  Messages are lost but never redelivered
• Exactly once 
  比較難實現 
  Messages are delivered once and only once 
  實現Exactly Once需要考慮: 
  • Must consider two components 
    Durability guarantees when publishing a message 
    Durability guarantees when consuming a message
  • Producer 
    What happens when a produce request was sent but a network error returned before an ack ? 
    RE:Use a single writer per partition and check the latest committed value after network errors
• Consumer 
  include a unique ID(e.g.UUID) and de-duplicate 
  Consider storing offsets with data

解釋:

• 訊息傳遞語義: Producer 角度 
  當Producer向broker傳送訊息時，一旦這條訊息被commit，因為replication的存在，它就不會丟,但是如果Producer傳送資料給broker後，遇到網路問題而造成通訊中斷，那Producer就無法判斷該條訊息是否已經commit 
  理想的解決方案：Producer可以生成一種類似於主鍵的東西，發生故障時冪等性的重試多次，這樣就做到了Exactly once,目前預設情況下一條訊息從Producer到broker是確保了At least once

• 訊息傳遞語義: Consumer : High Level API 
  Consumer在從broker讀取訊息後，可以選擇commit，該操作會在Zookeeper中儲存該Consumer在該Partition中讀取的訊息的offset 
  該Consumer下一次再讀該Partition時會從下一條開始讀取；如未commit，下一次讀取的開始位置會跟上一次commit之後的開始位置相同 
  現實的問題：到底是先處理訊息再commit，還是先commit再處理訊息？

  • 先處理訊息再commit 
    如果在處理完訊息再進行commit之前Consumer發生當機，下次重新開始工作時還會處理剛剛未commit的訊息，實際上該訊息已經被處理過了。這就對應於At least once 
    業務場景使用冪等性：訊息都有一個主鍵，所以訊息的處理往往具有冪等性，即多次處理這一條訊息跟只處理一次是等效的，那就可以認為是Exactly once。
  • 先commit再處理訊息 
    如果Consumer在commit後還沒來得及處理訊息就當機了，下次重新開始工作後就無法讀到剛剛已提交而未處理的訊息，這就對應於At most once

• 訊息傳遞語義: Consumer : Lower Level API 
  Exactly once的實現思想：協調offset和訊息資料 
  經典做法是引入兩階段提交 
  offset和訊息資料放在同一個地方：Consumer拿到資料後可能把資料放到共享空間中，如果把最新的offset和資料本身一起寫到共享空間，那就可以保證資料的輸出和offset的更新要麼都完成，要麼都不完成，間接實現Exactly once 
  High level API而言，offset是存於Zookeeper中的，無法獲取，而Low level API的offset是由自己去維護的，可以實現以上方案

4.高可用性

同一個Partition可能會有多個Replica，需要保證同一個Partition的多個Replica之間的資料一致性 
而這時需要在這些Replication之間選出一個Leader，Producer和Consumer只與這個Leader互動，其它Replica作為Follower從Leader中複製資料

• 副本與高可用性：副本Leader Election演算法

  • Zookeeper中的選舉演算法回顧 
    少數服從多數：確保叢集中一半以上的機器得到同步 
    適合共享叢集配置的系統中，而並不適合需要儲存大量資料的系統，因為需要大量副本集。f個Replica失敗情況下需要2f+1個副本
  • Kafka的做法 
    ISR(in-sync replicas)，這個ISR裡的所有副本都跟上了Leader，只有ISR裡的成員才有被選為Leader的可能 
    在這種模式下，對於f+1個副本，一個Partition能在保證不丟失已經commit的訊息的前提下容忍f個副本的失敗 
    ISR需要的總的副本的個數幾乎是“少數服從多數”的一半

• 副本與高可用性：Replica分配演算法 
  將所有Replica均勻分佈到整個叢集 
  將所有n個Broker和待分配的Partition排序 
  將第i個Partition分配到第(i mod n)個Broker上 
  將第i個Partition的第j個Replica分配到第((i + j) mode n)個Broker上

5. 零拷貝

Kafka通過Message分組和Sendfile系統呼叫實現了zero-copy

• 傳統的socket傳送檔案拷貝 
   
  1.核心態 
  2.使用者態 
  3.核心態 
  4.網路卡快取 
  經歷了核心態和使用者態的拷貝

• sendfile系統呼叫 
   
  避免了核心態與使用者態的上下文切換動作

sendfile 
優點：大塊檔案傳輸效率高 
缺點：小塊檔案效率較低、BIO而不是NIO 
mmap+write 
優點：使用小塊檔案傳輸時效率高 
缺點：比sendfile多消耗CPU、記憶體安全控制複雜 
應用 
Kafka使用第一種，大塊資料傳輸 
RocketMQ使用第二種，小快資料傳輸

三. Use Cases

• Real-Time Stream Processing(combined with Spark Streaming)
• General purpose Message Bus
• Collecting User Activity Data
• Collecting Operational Metrics from applications,servers or devices
• Log Aggregation
• Change Data Capture
• Commit Log for distributed systems

四. Development with Kafka

五. Administration

• list && describe

echo "此Kafka叢集所有的Topic : "
kafka-topics --list --zookeeper dc226.dooioo.cn:2181, dc227.dooioo.cn:2181,dc229.dooioo.cn:2181/kafka

echo "您要檢視的Topic詳細 : "

kafka-topics --describe --zookeeper dc226.dooioo.cn:2181, dc227.dooioo.cn:2181,dc229.dooioo.cn:2181/kafka --topic $topicName

• create topic

kafka-topics --create --zookeeper dc226.dooioo.cn:2181,dc227.dooioo.cn:2181,dc229.dooioo.cn:2181/kafka --replication-factor 1 --pa
rtitions 1 --topic $topicName

• open producer

kafka-console-producer --broker-list 10.22.253.227:9092 --topic $topicName 

• open consumer

kafka-console-consumer --zookeeper 10.22.253.226:2181,10.22.253.227:2181,10.22.253.229:2181/kafka --topic $topicName --from-beginning

六. Cluster Planning

七. Compare

 

更多理論知識：Kafka史上最詳細原理總結  https://blog.csdn.net/ychenfeng/article/details/74980531

參考資料：

• Apache Kafka網站
• 專案設計討論
• Github映象
• Morten Kjetland對Apache Kafka的介紹
• Quora上與RabbitMQ的對比
• Kafka: a Distributed Messaging System for Log Processing
• Zero-copy原理
• Kafka與Hadoop
• kafka實戰 https://www.cnblogs.com/hei12138/p/7805475.html
• kafka 基礎知識梳理  https://www.cnblogs.com/yangxiaoyi/p/7359236.html