Kafka入門經典教程
一、基本概念
介紹
Kafka是一個分布式的、可分區的、可復制的消息系統。它提供了普通消息系統的功能，但具有自己獨特的設計。
這個獨特的設計是什麽樣的呢？
首先讓我們看幾個基本的消息系統術語：
Kafka將消息以topic為單位進行歸納。
將向Kafka topic發布消息的程序成為producers.
將預訂topics並消費消息的程序成為consumer.
Kafka以集群的方式運行，可以由一個或多個服務組成，每個服務叫做一個broker.
producers通過網絡將消息發送到Kafka集群，集群向消費者提供消息，如下圖所示：
客戶端和服務端通過TCP協議通信。Kafka提供了Java客戶端，並且對多種語言都提供了支持。
Topics 和Logs
先來看一下Kafka提供的一個抽象概念:topic.
一個topic是對一組消息的歸納。對每個topic，Kafka 對它的日誌進行了分區，如下圖所示：
每個分區都由一系列有序的、不可變的消息組成，這些消息被連續的追加到分區中。分區中的每個消息都有一個連續的序列號叫做offset,用來在分區中唯一的標識這個消息。
在一個可配置的時間段內，Kafka集群保留所有發布的消息，不管這些消息有沒有被消費。比如，如果消息的保存策略被設置為2天，那麽在一個消息被發布的兩天時間內，它都是可以被消費的。之後它將被丟棄以釋放空間。Kafka的性能是和數據量無關的常量級的，所以保留太多的數據並不是問題。
實際上每個consumer唯一需要維護的數據是消息在日誌中的位置，也就是offset.這個offset有consumer來維護：一般情況下隨著consumer不斷的讀取消息，這offset的值不斷增加，但其實consumer可以以任意的順序讀取消息，比如它可以將offset設置成為一個舊的值來重讀之前的消息。
以上特點的結合，使Kafka consumers非常的輕量級：它們可以在不對集群和其他consumer造成影響的情況下讀取消息。你可以使用命令行來"tail"消息而不會對其他正在消費消息的consumer造成影響。
將日誌分區可以達到以下目的：首先這使得每個日誌的數量不會太大，可以在單個服務上保存。另外每個分區可以單獨發布和消費，為並發操作topic提供了一種可能。
分布式
每個分區在Kafka集群的若幹服務中都有副本，這樣這些持有副本的服務可以共同處理數據和請求，副本數量是可以配置的。副本使Kafka具備了容錯能力。
每個分區都由一個服務器作為“leader”，零或若幹服務器作為“followers”,leader負責處理消息的讀和寫，followers則去復制leader.如果leader down了，followers中的一臺則會自動成為leader。集群中的每個服務都會同時扮演兩個角色：作為它所持有的一部分分區的leader，同時作為其他分區的followers，這樣集群就會據有較好的負載均衡。
Producers
Producer將消息發布到它指定的topic中,並負責決定發布到哪個分區。通常簡單的由負載均衡機制隨機選擇分區，但也可以通過特定的分區函數選擇分區。使用的更多的是第二種。
Consumers
發布消息通常有兩種模式：隊列模式（queuing）和發布-訂閱模式(publish-subscribe)。隊列模式中，consumers可以同時從服務端讀取消息，每個消息只被其中一個consumer讀到；發布-訂閱模式中消息被廣播到所有的consumer中。Consumers可以加入一個consumer 組，共同競爭一個topic，topic中的消息將被分發到組中的一個成員中。同一組中的consumer可以在不同的程序中，也可以在不同的機器上。如果所有的consumer都在一個組中，這就成為了傳統的隊列模式，在各consumer中實現負載均衡。如果所有的consumer都不在不同的組中，這就成為了發布-訂閱模式，所有的消息都被分發到所有的consumer中。更常見的是，每個topic都有若幹數量的consumer組，每個組都是一個邏輯上的“訂閱者”，為了容錯和更好的穩定性，每個組由若幹consumer組成。這其實就是一個發布-訂閱模式，只不過訂閱者是個組而不是單個consumer。
由兩個機器組成的集群擁有4個分區 (P0-P3) 2個consumer組. A組有兩個consumerB組有4個
相比傳統的消息系統，Kafka可以很好的保證有序性。
傳統的隊列在服務器上保存有序的消息，如果多個consumers同時從這個服務器消費消息，服務器就會以消息存儲的順序向consumer分發消息。雖然服務器按順序發布消息，但是消息是被異步的分發到各consumer上，所以當消息到達時可能已經失去了原來的順序，這意味著並發消費將導致順序錯亂。為了避免故障，這樣的消息系統通常使用“專用consumer”的概念，其實就是只允許一個消費者消費消息，當然這就意味著失去了並發性。
在這方面Kafka做的更好，通過分區的概念，Kafka可以在多個consumer組並發的情況下提供較好的有序性和負載均衡。將每個分區分只分發給一個consumer組，這樣一個分區就只被這個組的一個consumer消費，就可以順序的消費這個分區的消息。因為有多個分區，依然可以在多個consumer組之間進行負載均衡。註意consumer組的數量不能多於分區的數量，也就是有多少分區就允許多少並發消費。
Kafka只能保證一個分區之內消息的有序性，在不同的分區之間是不可以的，這已經可以滿足大部分應用的需求。如果需要topic中所有消息的有序性，那就只能讓這個topic只有一個分區，當然也就只有一個consumer組消費它。
二、環境搭建
Step 1: 下載Kafka
點擊下載最新的版本並解壓.
> tar -xzf kafka_2.9.2-0.8.1.1.tgz
> cd kafka_2.9.2-0.8.1.1
復制代碼
Step 2: 啟動服務
Kafka用到了Zookeeper，所有首先啟動Zookper，下面簡單的啟用一個單實例的Zookkeeper服務。可以在命令的結尾加個&符號，這樣就可以啟動後離開控制臺。
> bin/zookeeper-server-start.sh config/zookeeper.properties &
[2013-04-22 15:01:37,495] INFO Reading configuration from: config/zookeeper.properties (org.apache.zookeeper.server.quorum.QuorumPeerConfig)
...
復制代碼
現在啟動Kafka:
> bin/kafka-server-start.sh config/server.properties
[2013-04-22 15:01:47,028] INFO Verifying properties (kafka.utils.VerifiableProperties)
[2013-04-22 15:01:47,051] INFO Property socket.send.buffer.bytes is overridden to 1048576 (kafka.utils.VerifiableProperties)
...
復制代碼
Step 3: 創建 topic
創建一個叫做“test”的topic，它只有一個分區，一個副本。
> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
復制代碼
可以通過list命令查看創建的topic:
> bin/kafka-topics.sh --list --zookeeper localhost:2181
test
復制代碼
除了手動創建topic，還可以配置broker讓它自動創建topic.
Step 4:發送消息.
Kafka 使用一個簡單的命令行producer，從文件中或者從標準輸入中讀取消息並發送到服務端。默認的每條命令將發送一條消息。
運行producer並在控制臺中輸一些消息，這些消息將被發送到服務端：
> bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
This is a messageThis is another message
復制代碼
ctrl+c可以退出發送。
Step 5: 啟動consumer
Kafka also has a command line consumer that will dump out messages to standard output.
Kafka也有一個命令行consumer可以讀取消息並輸出到標準輸出：
> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test --from-beginning
This is a message
This is another message
復制代碼
你在一個終端中運行consumer命令行，另一個終端中運行producer命令行，就可以在一個終端輸入消息，另一個終端讀取消息。
這兩個命令都有自己的可選參數，可以在運行的時候不加任何參數可以看到幫助信息。
Step 6: 搭建一個多個broker的集群
剛才只是啟動了單個broker，現在啟動有3個broker組成的集群，這些broker節點也都是在本機上的：
首先為每個節點編寫配置文件：
> cp config/server.properties config/server-1.properties
> cp config/server.properties config/server-2.properties
復制代碼
在拷貝出的新文件中添加以下參數：
config/server-1.properties:
broker.id=1
port=9093
log.dir=/tmp/kafka-logs-1
復制代碼
config/server-2.properties:
broker.id=2
port=9094
log.dir=/tmp/kafka-logs-2
復制代碼
broker.id在集群中唯一的標註一個節點，因為在同一個機器上，所以必須制定不同的端口和日誌文件，避免數據被覆蓋。
We already have Zookeeper and our single node started, so we just need to start the two new nodes:
剛才已經啟動可Zookeeper和一個節點，現在啟動另外兩個節點：
> bin/kafka-server-start.sh config/server-1.properties &
...
> bin/kafka-server-start.sh config/server-2.properties &
...
復制代碼
創建一個擁有3個副本的topic:
> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 1 --topic my-replicated-topic
復制代碼
現在我們搭建了一個集群，怎麽知道每個節點的信息呢？運行“"describe topics”命令就可以了：
> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic
復制代碼
Topic:my-replicated-topic PartitionCount:1 ReplicationFactor:3 Configs:
Topic: my-replicated-topic Partition: 0 Leader: 1 Replicas: 1,2,0 Isr: 1,2,0
復制代碼
下面解釋一下這些輸出。第一行是對所有分區的一個描述，然後每個分區都會對應一行，因為我們只有一個分區所以下面就只加了一行。
leader：負責處理消息的讀和寫，leader是從所有節點中隨機選擇的.
replicas：列出了所有的副本節點，不管節點是否在服務中.
isr：是正在服務中的節點.
在我們的例子中，節點1是作為leader運行。
向topic發送消息：
> bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-replicated-topic
復制代碼
...
my test message 1my test message 2^C
復制代碼
消費這些消息：
> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic
...
my test message 1
my test message 2
^C
測試一下容錯能力.Broker 1作為leader運行，現在我們kill掉它：
> ps | grep server-1.properties7564 ttys002 0:15.91 /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/java...
> kill -9 7564
復制代碼
另外一個節點被選做了leader,node 1 不再出現在 in-sync 副本列表中：
> bin/kafka-topics.sh --describe --zookeeper localhost:218192 --topic my-replicated-topic
Topic:my-replicated-topic PartitionCount:1 ReplicationFactor:3 Configs:
Topic: my-replicated-topic Partition: 0 Leader: 2 Replicas: 1,2,0 Isr: 2,0
復制代碼
雖然最初負責續寫消息的leader down掉了，但之前的消息還是可以消費的：
> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic
...
my test message 1
my test message 2
復制代碼
看來Kafka的容錯機制還是不錯的。
三、搭建Kafka開發環境
我們搭建了kafka的服務器，並可以使用Kafka的命令行工具創建topic，發送和接收消息。下面我們來搭建kafka的開發環境。
添加依賴
搭建開發環境需要引入kafka的jar包，一種方式是將Kafka安裝包中lib下的jar包加入到項目的classpath中，這種比較簡單了。不過我們使用另一種更加流行的方式：使用maven管理jar包依賴。
創建好maven項目後，在pom.xml中添加以下依賴：
org.apache.kafka
kafka_2.10
0.8.0
復制代碼
添加依賴後你會發現有兩個jar包的依賴找不到。沒關系我都幫你想好了，點擊這裏下載這兩個jar包，解壓後你有兩種選擇，第一種是使用mvn的install命令將jar包安裝到本地倉庫，另一種是直接將解壓後的文件夾拷貝到mvn本地倉庫的com文件夾下，比如我的本地倉庫是d:\mvn,完成後我的目錄結構是這樣的：
配置程序
首先是一個充當配置文件作用的接口,配置了Kafka的各種連接參數：
package com.sohu.kafkademon;
public interface KafkaProperties
{
final static String zkConnect = "10.22.10.139:2181";
final static String groupId = "group1";
final static String topic = "topic1";
final static String kafkaServerURL = "10.22.10.139";
final static int kafkaServerPort = 9092;
final static int kafkaProducerBufferSize = 64 * 1024;
final static int connectionTimeOut = 20000;
final static int reconnectInterval = 10000;
final static String topic2 = "topic2";
final static String topic3 = "topic3";
final static String clientId = "SimpleConsumerDemoClient";
}
復制代碼
producer
package com.sohu.kafkademon;
import java.util.Properties;
import kafka.producer.KeyedMessage;
import kafka.producer.ProducerConfig;
/**
* @author leicui [email protected]
*/
public class KafkaProducer extends Thread
{
private final kafka.javaapi.producer.Producer producer;
private final String topic;
private final Properties props = new Properties();
public KafkaProducer(String topic)
{
props.put("serializer.class", "kafka.serializer.StringEncoder");
props.put("metadata.broker.list", "10.22.10.139:9092");
producer = new kafka.javaapi.producer.Producer(new ProducerConfig(props));
this.topic = topic;
}
@Override
public void run() {
int messageNo = 1;
while (true)
{
String messageStr = new String("Message_" + messageNo);
System.out.println("Send:" + messageStr);
producer.send(new KeyedMessage(topic, messageStr));
messageNo++;
try {
sleep(3000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
}
復制代碼
consumer
package com.sohu.kafkademon;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Properties;
import kafka.consumer.ConsumerConfig;
import kafka.consumer.ConsumerIterator;
import kafka.consumer.KafkaStream;
import kafka.javaapi.consumer.ConsumerConnector;
/**
* @author leicui [email protected]
*/
public class KafkaConsumer extends Thread
{
private final ConsumerConnector consumer;
private final String topic;
public KafkaConsumer(String topic)
{
consumer = kafka.consumer.Consumer.createJavaConsumerConnector(
createConsumerConfig());
this.topic = topic;
}
private static ConsumerConfig createConsumerConfig()
{
Properties props = new Properties();
props.put("zookeeper.connect", KafkaProperties.zkConnect);
props.put("group.id", KafkaProperties.groupId);
props.put("zookeeper.session.timeout.ms", "40000");
props.put("zookeeper.sync.time.ms", "200");
props.put("auto.commit.interval.ms", "1000");
return new ConsumerConfig(props);
}
@Override
public void run() {
Map topicCountMap = new HashMap();
topicCountMap.put(topic, new Integer(1));
Map>> consumerMap = consumer.createMessageStreams(topicCountMap);
KafkaStream stream = consumerMap.get(topic).get(0);
ConsumerIterator it = stream.iterator();
while (it.hasNext()) {
System.out.println("receive：" + new String(it.next().message()));
try {
sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
復制代碼
簡單的發送接收
運行下面這個程序，就可以進行簡單的發送接收消息了：
package com.sohu.kafkademon;
/**
* @author leicui [email protected]
*/
public class KafkaConsumerProducerDemo
{
public static void main(String[] args)
{
KafkaProducer producerThread = new KafkaProducer(KafkaProperties.topic);
producerThread.start();
KafkaConsumer consumerThread = new KafkaConsumer(KafkaProperties.topic);
consumerThread.start();
}
}
復制代碼
高級別的consumer
下面是比較負載的發送接收的程序：
package com.sohu.kafkademon;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Properties;
import kafka.consumer.ConsumerConfig;
import kafka.consumer.ConsumerIterator;
import kafka.consumer.KafkaStream;
import kafka.javaapi.consumer.ConsumerConnector;
/**
* @author leicui [email protected]
*/
public class KafkaConsumer extends Thread
{
private final ConsumerConnector consumer;
private final String topic;
public KafkaConsumer(String topic)
{
consumer = kafka.consumer.Consumer.createJavaConsumerConnector(
createConsumerConfig());
this.topic = topic;
}
private static ConsumerConfig createConsumerConfig()
{
Properties props = new Properties();
props.put("zookeeper.connect", KafkaProperties.zkConnect);
props.put("group.id", KafkaProperties.groupId);
props.put("zookeeper.session.timeout.ms", "40000");
props.put("zookeeper.sync.time.ms", "200");
props.put("auto.commit.interval.ms", "1000");
return new ConsumerConfig(props);
}
@Override
public void run() {
Map topicCountMap = new HashMap();
topicCountMap.put(topic, new Integer(1));
Map>> consumerMap = consumer.createMessageStreams(topicCountMap);
KafkaStream stream = consumerMap.get(topic).get(0);
ConsumerIterator it = stream.iterator();
while (it.hasNext()) {
System.out.println("receive：" + new String(it.next().message()));
try {
sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
四、數據持久化
不要畏懼文件系統!
Kafka大量依賴文件系統去存儲和緩存消息。對於硬盤有個傳統的觀念是硬盤總是很慢，這使很多人懷疑基於文件系統的架構能否提供優異的性能。實際上硬盤的快慢完全取決於使用它的方式。設計良好的硬盤架構可以和內存一樣快。
在6塊7200轉的SATA RAID-5磁盤陣列的線性寫速度差不多是600MB/s，但是隨即寫的速度卻是100k/s，差了差不多6000倍。現代的操作系統都對次做了大量的優化，使用了 read-ahead 和 write-behind的技巧，讀取的時候成塊的預讀取數據，寫的時候將各種微小瑣碎的邏輯寫入組織合並成一次較大的物理寫入。對此的深入討論可以查看這裏，它們發現線性的訪問磁盤，很多時候比隨機的內存訪問快得多。
為了提高性能，現代操作系統往往使用內存作為磁盤的緩存，現代操作系統樂於把所有空閑內存用作磁盤緩存，雖然這可能在緩存回收和重新分配時犧牲一些性能。所有的磁盤讀寫操作都會經過這個緩存，這不太可能被繞開除非直接使用I/O。所以雖然每個程序都在自己的線程裏只緩存了一份數據，但在操作系統的緩存裏還有一份，這等於存了兩份數據。
另外再來討論一下JVM,以下兩個事實是眾所周知的：
?Java對象占用空間是非常大的，差不多是要存儲的數據的兩倍甚至更高。
?隨著堆中數據量的增加，垃圾回收回變的越來越困難。
基於以上分析，如果把數據緩存在內存裏，因為需要存儲兩份，不得不使用兩倍的內存空間，Kafka基於JVM，又不得不將空間再次加倍,再加上要避免GC帶來的性能影響，在一個32G內存的機器上，不得不使用到28-30G的內存空間。並且當系統重啟的時候，又必須要將數據刷到內存中（ 10GB 內存差不多要用10分鐘），就算使用冷刷新（不是一次性刷進內存，而是在使用數據的時候沒有就刷到內存）也會導致最初的時候新能非常慢。但是使用文件系統，即使系統重啟了，也不需要刷新數據。使用文件系統也簡化了維護數據一致性的邏輯。
所以與傳統的將數據緩存在內存中然後刷到硬盤的設計不同，Kafka直接將數據寫到了文件系統的日誌中。
常量時間的操作效率
在大多數的消息系統中，數據持久化的機制往往是為每個cosumer提供一個B樹或者其他的隨機讀寫的數據結構。B樹當然是很棒的，但是也帶了一些代價：比如B樹的復雜度是O(log N)，O(log N)通常被認為就是常量復雜度了，但對於硬盤操作來說並非如此。磁盤進行一次搜索需要10ms，每個硬盤在同一時間只能進行一次搜索，這樣並發處理就成了問題。雖然存儲系統使用緩存進行了大量優化，但是對於樹結構的性能的觀察結果卻表明，它的性能往往隨著數據的增長而線性下降，數據增長一倍，速度就會降低一倍。
直觀的講，對於主要用於日誌處理的消息系統，數據的持久化可以簡單的通過將數據追加到文件中實現，讀的時候從文件中讀就好了。這樣做的好處是讀和寫都是 O(1) 的，並且讀操作不會阻塞寫操作和其他操作。這樣帶來的性能優勢是很明顯的，因為性能和數據的大小沒有關系了。
既然可以使用幾乎沒有容量限制（相對於內存來說）的硬盤空間建立消息系統，就可以在沒有性能損失的情況下提供一些一般消息系統不具備的特性。比如，一般的消息系統都是在消息被消費後立即刪除，Kafka卻可以將消息保存一段時間（比如一星期），這給consumer提供了很好的機動性和靈活性，這點在今後的文章中會有詳述。
五、消息傳輸的事務定義
之前討論了consumer和producer是怎麽工作的，現在來討論一下數據傳輸方面。數據傳輸的事務定義通常有以下三種級別：
最多一次: 消息不會被重復發送，最多被傳輸一次，但也有可能一次不傳輸。
最少一次: 消息不會被漏發送，最少被傳輸一次，但也有可能被重復傳輸.
精確的一次（Exactly once）: 不會漏傳輸也不會重復傳輸,每個消息都傳輸被一次而且僅僅被傳輸一次，這是大家所期望的。
大多數消息系統聲稱可以做到“精確的一次”，但是仔細閱讀它們的的文檔可以看到裏面存在誤導，比如沒有說明當consumer或producer失敗時怎麽樣，或者當有多個consumer並行時怎麽樣，或寫入硬盤的數據丟失時又會怎麽樣。kafka的做法要更先進一些。當發布消息時，Kafka有一個“committed”的概念，一旦消息被提交了，只要消息被寫入的分區的所在的副本broker是活動的，數據就不會丟失。關於副本的活動的概念，下節文檔會討論。現在假設broker是不會down的。
如果producer發布消息時發生了網絡錯誤，但又不確定實在提交之前發生的還是提交之後發生的，這種情況雖然不常見，但是必須考慮進去，現在Kafka版本還沒有解決這個問題，將來的版本正在努力嘗試解決。
並不是所有的情況都需要“精確的一次”這樣高的級別，Kafka允許producer靈活的指定級別。比如producer可以指定必須等待消息被提交的通知，或者完全的異步發送消息而不等待任何通知，或者僅僅等待leader聲明它拿到了消息（followers沒有必要）。
現在從consumer的方面考慮這個問題，所有的副本都有相同的日誌文件和相同的offset，consumer維護自己消費的消息的offset，如果consumer不會崩潰當然可以在內存中保存這個值，當然誰也不能保證這點。如果consumer崩潰了，會有另外一個consumer接著消費消息，它需要從一個合適的offset繼續處理。這種情況下可以有以下選擇：
consumer可以先讀取消息，然後將offset寫入日誌文件中，然後再處理消息。這存在一種可能就是在存儲offset後還沒處理消息就crash了，新的consumer繼續從這個offset處理，那麽就會有些消息永遠不會被處理，這就是上面說的“最多一次”。
consumer可以先讀取消息，處理消息，最後記錄offset，當然如果在記錄offset之前就crash了，新的consumer會重復的消費一些消息，這就是上面說的“最少一次”。
“精確一次”可以通過將提交分為兩個階段來解決：保存了offset後提交一次，消息處理成功之後再提交一次。但是還有個更簡單的做法：將消息的offset和消息被處理後的結果保存在一起。比如用Hadoop ETL處理消息時，將處理後的結果和offset同時保存在HDFS中，這樣就能保證消息和offser同時被處理了。
更多詳細源碼參考來源：技術網站請查看這裏歡迎大家一起學習研究相關技術，源碼獲取請加求求（企鵝）: 2042849237
Kafka入門經典教程