問題導(dǎo)讀 1.Kafka獨(dú)特設(shè)計在什么地方？ 2.Kafka如何搭建及創(chuàng)建topic、發(fā)送消息、消費(fèi)消息？ 3.如何書寫Kafka程序？ 4.數(shù)據(jù)傳輸?shù)氖聞?wù)定義有哪三種？ 5.Kafka判斷一個節(jié)點(diǎn)是否活著有哪兩個條件？ 6.producer是否直接將數(shù)據(jù)發(fā)送到broker的leader(主節(jié)點(diǎn))？ 7.Kafa consumer是否可以消費(fèi)指定分區(qū)消息？ 8.Kafka消息是采用Pull模式，還是Push模式？ 9.Procuder API有哪兩種？ 10.Kafka存儲在硬盤上的消息格式是什么？

?

一、基本概念

介紹

Kafka是一個分布式的、可分區(qū)的、可復(fù)制的消息系統(tǒng)。它提供了普通消息系統(tǒng)的功能，但具有自己獨(dú)特的設(shè)計。

這個獨(dú)特的設(shè)計是什么樣的呢？

首先讓我們看幾個基本的消息系統(tǒng)術(shù)語：
Kafka將消息以topic為單位進(jìn)行歸納。
將向Kafka topic發(fā)布消息的程序成為producers.
將預(yù)訂topics并消費(fèi)消息的程序成為consumer.
Kafka以集群的方式運(yùn)行，可以由一個或多個服務(wù)組成，每個服務(wù)叫做一個broker.
producers通過網(wǎng)絡(luò)將消息發(fā)送到Kafka集群，集群向消費(fèi)者提供消息，如下圖所示：

<ignore_js_op>?

客戶端和服務(wù)端通過TCP協(xié)議通信。Kafka提供了Java客戶端，并且對多種語言都提供了支持。


Topics 和Logs

先來看一下Kafka提供的一個抽象概念:topic.
一個topic是對一組消息的歸納。對每個topic，Kafka 對它的日志進(jìn)行了分區(qū)，如下圖所示：
<ignore_js_op>?

每個分區(qū)都由一系列有序的、不可變的消息組成，這些消息被連續(xù)的追加到分區(qū)中。分區(qū)中的每個消息都有一個連續(xù)的序列號叫做offset,用來在分區(qū)中唯一的標(biāo)識這個消息。
在一個可配置的時間段內(nèi)，Kafka集群保留所有發(fā)布的消息，不管這些消息有沒有被消費(fèi)。比如，如果消息的保存策略被設(shè)置為2天，那么在一個消息被發(fā)布的兩天時間內(nèi)，它都是可以被消費(fèi)的。之后它將被丟棄以釋放空間。Kafka的性能是和數(shù)據(jù)量無關(guān)的常量級的，所以保留太多的數(shù)據(jù)并不是問題。

實(shí)際上每個consumer唯一需要維護(hù)的數(shù)據(jù)是消息在日志中的位置，也就是offset.這個offset有consumer來維護(hù)：一般情況下隨著consumer不斷的讀取消息，這offset的值不斷增加，但其實(shí)consumer可以以任意的順序讀取消息，比如它可以將offset設(shè)置成為一個舊的值來重讀之前的消息。

以上特點(diǎn)的結(jié)合，使Kafka consumers非常的輕量級：它們可以在不對集群和其他consumer造成影響的情況下讀取消息。你可以使用命令行來"tail"消息而不會對其他正在消費(fèi)消息的consumer造成影響。

將日志分區(qū)可以達(dá)到以下目的：首先這使得每個日志的數(shù)量不會太大，可以在單個服務(wù)上保存。另外每個分區(qū)可以單獨(dú)發(fā)布和消費(fèi)，為并發(fā)操作topic提供了一種可能。

分布式

每個分區(qū)在Kafka集群的若干服務(wù)中都有副本，這樣這些持有副本的服務(wù)可以共同處理數(shù)據(jù)和請求，副本數(shù)量是可以配置的。副本使Kafka具備了容錯能力。
每個分區(qū)都由一個服務(wù)器作為“l(fā)eader”，零或若干服務(wù)器作為“followers”,leader負(fù)責(zé)處理消息的讀和寫，followers則去復(fù)制leader.如果leader down了，followers中的一臺則會自動成為leader。集群中的每個服務(wù)都會同時扮演兩個角色：作為它所持有的一部分分區(qū)的leader，同時作為其他分區(qū)的followers，這樣集群就會據(jù)有較好的負(fù)載均衡。

Producers

Producer將消息發(fā)布到它指定的topic中,并負(fù)責(zé)決定發(fā)布到哪個分區(qū)。通常簡單的由負(fù)載均衡機(jī)制隨機(jī)選擇分區(qū)，但也可以通過特定的分區(qū)函數(shù)選擇分區(qū)。使用的更多的是第二種。


Consumers

發(fā)布消息通常有兩種模式：隊列模式（queuing）和發(fā)布-訂閱模式(publish-subscribe)。隊列模式中，consumers可以同時從服務(wù)端讀取消息，每個消息只被其中一個consumer讀到；發(fā)布-訂閱模式中消息被廣播到所有的consumer中。Consumers可以加入一個consumer 組，共同競爭一個topic，topic中的消息將被分發(fā)到組中的一個成員中。同一組中的consumer可以在不同的程序中，也可以在不同的機(jī)器上。如果所有的consumer都在一個組中，這就成為了傳統(tǒng)的隊列模式，在各consumer中實(shí)現(xiàn)負(fù)載均衡。如果所有的consumer都不在不同的組中，這就成為了發(fā)布-訂閱模式，所有的消息都被分發(fā)到所有的consumer中。更常見的是，每個topic都有若干數(shù)量的consumer組，每個組都是一個邏輯上的“訂閱者”，為了容錯和更好的穩(wěn)定性，每個組由若干consumer組成。這其實(shí)就是一個發(fā)布-訂閱模式，只不過訂閱者是個組而不是單個consumer。

<ignore_js_op>?

由兩個機(jī)器組成的集群擁有4個分區(qū) (P0-P3) 2個consumer組. A組有兩個consumerB組有4個

相比傳統(tǒng)的消息系統(tǒng)，Kafka可以很好的保證有序性。
傳統(tǒng)的隊列在服務(wù)器上保存有序的消息，如果多個consumers同時從這個服務(wù)器消費(fèi)消息，服務(wù)器就會以消息存儲的順序向consumer分發(fā)消息。雖然服務(wù)器按順序發(fā)布消息，但是消息是被異步的分發(fā)到各consumer上，所以當(dāng)消息到達(dá)時可能已經(jīng)失去了原來的順序，這意味著并發(fā)消費(fèi)將導(dǎo)致順序錯亂。為了避免故障，這樣的消息系統(tǒng)通常使用“專用consumer”的概念，其實(shí)就是只允許一個消費(fèi)者消費(fèi)消息，當(dāng)然這就意味著失去了并發(fā)性。

在這方面Kafka做的更好，通過分區(qū)的概念，Kafka可以在多個consumer組并發(fā)的情況下提供較好的有序性和負(fù)載均衡。將每個分區(qū)分只分發(fā)給一個consumer組，這樣一個分區(qū)就只被這個組的一個consumer消費(fèi)，就可以順序的消費(fèi)這個分區(qū)的消息。因為有多個分區(qū)，依然可以在多個consumer組之間進(jìn)行負(fù)載均衡。注意consumer組的數(shù)量不能多于分區(qū)的數(shù)量，也就是有多少分區(qū)就允許多少并發(fā)消費(fèi)。

Kafka只能保證一個分區(qū)之內(nèi)消息的有序性，在不同的分區(qū)之間是不可以的，這已經(jīng)可以滿足大部分應(yīng)用的需求。如果需要topic中所有消息的有序性，那就只能讓這個topic只有一個分區(qū)，當(dāng)然也就只有一個consumer組消費(fèi)它。

###########################################

二、環(huán)境搭建

注意：要在/etc/hosts里面添加主機(jī)名

如：

127.0.0.1 hchtest3

10.72.16.xx hchtest3

Step 1: 下載Kafka

點(diǎn)擊下載最新的版本并解壓.

> tar -xzf kafka_2.9.2-0.8.1.1.tgz

> cd kafka_2.9.2-0.8.1.1

復(fù)制代碼

Step 2: 啟動服務(wù)

Kafka用到了Zookeeper，所有首先啟動Zookper，下面簡單的啟用一個單實(shí)例的Zookkeeper服務(wù)。可以在命令的結(jié)尾加個&符號，這樣就可以啟動后離開控制臺。

> 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)

...

復(fù)制代碼

現(xiàn)在啟動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)

...

復(fù)制代碼

Step 3: 創(chuàng)建 topic

創(chuàng)建一個叫做“test”的topic，它只有一個分區(qū)，一個副本。

> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test

復(fù)制代碼

可以通過list命令查看創(chuàng)建的topic:

> bin/kafka-topics.sh --list --zookeeper localhost:2181

test

復(fù)制代碼

除了手動創(chuàng)建topic，還可以配置broker讓它自動創(chuàng)建topic.

Step 4:發(fā)送消息.

Kafka 使用一個簡單的命令行producer，從文件中或者從標(biāo)準(zhǔn)輸入中讀取消息并發(fā)送到服務(wù)端。默認(rèn)的每條命令將發(fā)送一條消息。

運(yùn)行producer并在控制臺中輸一些消息，這些消息將被發(fā)送到服務(wù)端：

> bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test?

This is a messageThis is another message

復(fù)制代碼

ctrl+c可以退出發(fā)送。

Step 5: 啟動consumer

Kafka also has a command line consumer that will dump out messages to standard output.
Kafka也有一個命令行consumer可以讀取消息并輸出到標(biāo)準(zhǔn)輸出：

> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test --from-beginning

This is a message

This is another message

復(fù)制代碼

你在一個終端中運(yùn)行consumer命令行，另一個終端中運(yùn)行producer命令行，就可以在一個終端輸入消息，另一個終端讀取消息。
這兩個命令都有自己的可選參數(shù)，可以在運(yùn)行的時候不加任何參數(shù)可以看到幫助信息。

Step 6: 搭建一個多個broker的集群

剛才只是啟動了單個broker，現(xiàn)在啟動有3個broker組成的集群，這些broker節(jié)點(diǎn)也都是在本機(jī)上的：
首先為每個節(jié)點(diǎn)編寫配置文件：

> cp config/server.properties config/server-1.properties

> cp config/server.properties config/server-2.properties

復(fù)制代碼

在拷貝出的新文件中添加以下參數(shù)：

config/server-1.properties:

? ? broker.id=1

? ? port=9093

? ? log.dir=/tmp/kafka-logs-1

復(fù)制代碼

config/server-2.properties:

? ? broker.id=2

? ? port=9094

? ? log.dir=/tmp/kafka-logs-2

復(fù)制代碼

broker.id在集群中唯一的標(biāo)注一個節(jié)點(diǎn)，因為在同一個機(jī)器上，所以必須制定不同的端口和日志文件，避免數(shù)據(jù)被覆蓋。

We already have Zookeeper and our single node started, so we just need to start the two new nodes:
剛才已經(jīng)啟動可Zookeeper和一個節(jié)點(diǎn)，現(xiàn)在啟動另外兩個節(jié)點(diǎn)：

> bin/kafka-server-start.sh config/server-1.properties &

...

> bin/kafka-server-start.sh config/server-2.properties &

...

復(fù)制代碼

創(chuàng)建一個擁有3個副本的topic:

> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 1 --topic my-replicated-topic

復(fù)制代碼

現(xiàn)在我們搭建了一個集群，怎么知道每個節(jié)點(diǎn)的信息呢？運(yùn)行“"describe topics”命令就可以了：

> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic

復(fù)制代碼

?

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

復(fù)制代碼

下面解釋一下這些輸出。第一行是對所有分區(qū)的一個描述，然后每個分區(qū)都會對應(yīng)一行，因為我們只有一個分區(qū)所以下面就只加了一行。
leader：負(fù)責(zé)處理消息的讀和寫，leader是從所有節(jié)點(diǎn)中隨機(jī)選擇的.
replicas：列出了所有的副本節(jié)點(diǎn)，不管節(jié)點(diǎn)是否在服務(wù)中.
isr：是正在服務(wù)中的節(jié)點(diǎn).
在我們的例子中，節(jié)點(diǎn)1是作為leader運(yùn)行。
向topic發(fā)送消息：

> bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-replicated-topic

復(fù)制代碼

?

...

my test message 1my test message 2^C

復(fù)制代碼

消費(fèi)這些消息：

> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic

復(fù)制代碼

?

...

my test message 1

my test message 2

^C

復(fù)制代碼

測試一下容錯能力.Broker 1作為leader運(yùn)行，現(xiàn)在我們kill掉它：

> ps | grep server-1.properties7564 ttys002? ? 0:15.91 /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/java...

> kill -9 7564

復(fù)制代碼

另外一個節(jié)點(diǎn)被選做了leader,node 1 不再出現(xiàn)在 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

復(fù)制代碼

雖然最初負(fù)責(zé)續(xù)寫消息的leader down掉了，但之前的消息還是可以消費(fèi)的：

> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic

...

my test message 1

my test message 2

復(fù)制代碼

看來Kafka的容錯機(jī)制還是不錯的。

################################################

三、搭建Kafka開發(fā)環(huán)境

我們搭建了kafka的服務(wù)器，并可以使用Kafka的命令行工具創(chuàng)建topic，發(fā)送和接收消息。下面我們來搭建kafka的開發(fā)環(huán)境。
添加依賴

搭建開發(fā)環(huán)境需要引入kafka的jar包，一種方式是將Kafka安裝包中l(wèi)ib下的jar包加入到項目的classpath中，這種比較簡單了。不過我們使用另一種更加流行的方式：使用maven管理jar包依賴。
創(chuàng)建好maven項目后，在pom.xml中添加以下依賴：

<dependency>

? ?? ???<groupId> org.apache.kafka</groupId >

? ?? ???<artifactId> kafka_2.10</artifactId >

? ?? ???<version> 0.8.0</ version>

</dependency>

復(fù)制代碼

添加依賴后你會發(fā)現(xiàn)有兩個jar包的依賴找不到。沒關(guān)系我都幫你想好了，點(diǎn)擊這里下載這兩個jar包，解壓后你有兩種選擇，第一種是使用mvn的install命令將jar包安裝到本地倉庫，另一種是直接將解壓后的文件夾拷貝到mvn本地倉庫的com文件夾下，比如我的本地倉庫是d:\mvn,完成后我的目錄結(jié)構(gòu)是這樣的：

<ignore_js_op>?


配置程序

首先是一個充當(dāng)配置文件作用的接口,配置了Kafka的各種連接參數(shù)：

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";

}

復(fù)制代碼

producer

package com.sohu.kafkademon;

import java.util.Properties;

import kafka.producer.KeyedMessage;

import kafka.producer.ProducerConfig;

/**

* @author leicui?bourne_cui@163.com

*/

public class KafkaProducer extends Thread

{

? ? private final kafka.javaapi.producer.Producer<Integer, String> 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<Integer, String>(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<Integer, String>(topic, messageStr));

? ?? ?? ?? ?messageNo++;

? ?? ?? ?? ?try {

? ?? ?? ?? ?? ? sleep(3000);

? ?? ?? ?? ?} catch (InterruptedException e) {

? ?? ?? ?? ?? ? // TODO Auto-generated catch block

? ?? ?? ?? ?? ? e.printStackTrace();

? ?? ?? ?? ?}

? ?? ???}

? ? }

}

復(fù)制代碼

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?bourne_cui@163.com

*/

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<String, Integer> topicCountMap = new HashMap<String, Integer>();

? ?? ???topicCountMap.put(topic, new Integer(1));

? ?? ???Map<String, List<KafkaStream<byte[], byte[]>>> consumerMap = consumer.createMessageStreams(topicCountMap);

? ?? ???KafkaStream<byte[], byte[]> stream = consumerMap.get(topic).get(0);

? ?? ???ConsumerIterator<byte[], byte[]> it = stream.iterator();

? ?? ???while (it.hasNext()) {

? ?? ?? ?? ?System.out.println("receive：" + new String(it.next().message()));

? ?? ?? ?? ?try {

? ?? ?? ?? ?? ? sleep(3000);

? ?? ?? ?? ?} catch (InterruptedException e) {

? ?? ?? ?? ?? ? e.printStackTrace();

? ?? ?? ?? ?}

? ?? ???}

? ? }

}

復(fù)制代碼

簡單的發(fā)送接收

運(yùn)行下面這個程序，就可以進(jìn)行簡單的發(fā)送接收消息了：

package com.sohu.kafkademon;

/**

* @author leicui?bourne_cui@163.com

*/

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();

? ? }

}

復(fù)制代碼

高級別的consumer

下面是比較負(fù)載的發(fā)送接收的程序：

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?bourne_cui@163.com

*/

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<String, Integer> topicCountMap = new HashMap<String, Integer>();

? ?? ???topicCountMap.put(topic, new Integer(1));

? ?? ???Map<String, List<KafkaStream<byte[], byte[]>>> consumerMap = consumer.createMessageStreams(topicCountMap);

? ?? ???KafkaStream<byte[], byte[]> stream = consumerMap.get(topic).get(0);

? ?? ???ConsumerIterator<byte[], byte[]> it = stream.iterator();

? ?? ???while (it.hasNext()) {

? ?? ?? ?? ?System.out.println("receive：" + new String(it.next().message()));

? ?? ?? ?? ?try {

? ?? ?? ?? ?? ? sleep(3000);

? ?? ?? ?? ?} catch (InterruptedException e) {

? ?? ?? ?? ?? ? e.printStackTrace();

? ?? ?? ?? ?}

? ?? ???}

? ? }

}

復(fù)制代碼

############################################################

四、數(shù)據(jù)持久化


不要畏懼文件系統(tǒng)!

Kafka大量依賴文件系統(tǒng)去存儲和緩存消息。對于硬盤有個傳統(tǒng)的觀念是硬盤總是很慢，這使很多人懷疑基于文件系統(tǒng)的架構(gòu)能否提供優(yōu)異的性能。實(shí)際上硬盤的快慢完全取決于使用它的方式。設(shè)計良好的硬盤架構(gòu)可以和內(nèi)存一樣快。

在6塊7200轉(zhuǎn)的SATA RAID-5磁盤陣列的線性寫速度差不多是600MB/s，但是隨即寫的速度卻是100k/s，差了差不多6000倍。現(xiàn)代的操作系統(tǒng)都對次做了大量的優(yōu)化，使用了 read-ahead 和 write-behind的技巧，讀取的時候成塊的預(yù)讀取數(shù)據(jù)，寫的時候?qū)⒏鞣N微小瑣碎的邏輯寫入組織合并成一次較大的物理寫入。對此的深入討論可以查看這里，它們發(fā)現(xiàn)線性的訪問磁盤，很多時候比隨機(jī)的內(nèi)存訪問快得多。

為了提高性能，現(xiàn)代操作系統(tǒng)往往使用內(nèi)存作為磁盤的緩存，現(xiàn)代操作系統(tǒng)樂于把所有空閑內(nèi)存用作磁盤緩存，雖然這可能在緩存回收和重新分配時犧牲一些性能。所有的磁盤讀寫操作都會經(jīng)過這個緩存，這不太可能被繞開除非直接使用I/O。所以雖然每個程序都在自己的線程里只緩存了一份數(shù)據(jù)，但在操作系統(tǒng)的緩存里還有一份，這等于存了兩份數(shù)據(jù)。

另外再來討論一下JVM,以下兩個事實(shí)是眾所周知的：

?Java對象占用空間是非常大的，差不多是要存儲的數(shù)據(jù)的兩倍甚至更高。

?隨著堆中數(shù)據(jù)量的增加，垃圾回收回變的越來越困難。

基于以上分析，如果把數(shù)據(jù)緩存在內(nèi)存里，因為需要存儲兩份，不得不使用兩倍的內(nèi)存空間，Kafka基于JVM，又不得不將空間再次加倍,再加上要避免GC帶來的性能影響，在一個32G內(nèi)存的機(jī)器上，不得不使用到28-30G的內(nèi)存空間。并且當(dāng)系統(tǒng)重啟的時候，又必須要將數(shù)據(jù)刷到內(nèi)存中（ 10GB 內(nèi)存差不多要用10分鐘），就算使用冷刷新（不是一次性刷進(jìn)內(nèi)存，而是在使用數(shù)據(jù)的時候沒有就刷到內(nèi)存）也會導(dǎo)致最初的時候新能非常慢。但是使用文件系統(tǒng)，即使系統(tǒng)重啟了，也不需要刷新數(shù)據(jù)。使用文件系統(tǒng)也簡化了維護(hù)數(shù)據(jù)一致性的邏輯。

所以與傳統(tǒng)的將數(shù)據(jù)緩存在內(nèi)存中然后刷到硬盤的設(shè)計不同，Kafka直接將數(shù)據(jù)寫到了文件系統(tǒng)的日志中。

常量時間的操作效率

在大多數(shù)的消息系統(tǒng)中，數(shù)據(jù)持久化的機(jī)制往往是為每個cosumer提供一個B樹或者其他的隨機(jī)讀寫的數(shù)據(jù)結(jié)構(gòu)。B樹當(dāng)然是很棒的，但是也帶了一些代價：比如B樹的復(fù)雜度是O(log N)，O(log N)通常被認(rèn)為就是常量復(fù)雜度了，但對于硬盤操作來說并非如此。磁盤進(jìn)行一次搜索需要10ms，每個硬盤在同一時間只能進(jìn)行一次搜索，這樣并發(fā)處理就成了問題。雖然存儲系統(tǒng)使用緩存進(jìn)行了大量優(yōu)化，但是對于樹結(jié)構(gòu)的性能的觀察結(jié)果卻表明，它的性能往往隨著數(shù)據(jù)的增長而線性下降，數(shù)據(jù)增長一倍，速度就會降低一倍。

直觀的講，對于主要用于日志處理的消息系統(tǒng)，數(shù)據(jù)的持久化可以簡單的通過將數(shù)據(jù)追加到文件中實(shí)現(xiàn)，讀的時候從文件中讀就好了。這樣做的好處是讀和寫都是 O(1) 的，并且讀操作不會阻塞寫操作和其他操作。這樣帶來的性能優(yōu)勢是很明顯的，因為性能和數(shù)據(jù)的大小沒有關(guān)系了。

既然可以使用幾乎沒有容量限制（相對于內(nèi)存來說）的硬盤空間建立消息系統(tǒng)，就可以在沒有性能損失的情況下提供一些一般消息系統(tǒng)不具備的特性。比如，一般的消息系統(tǒng)都是在消息被消費(fèi)后立即刪除，Kafka卻可以將消息保存一段時間（比如一星期），這給consumer提供了很好的機(jī)動性和靈活性，這點(diǎn)在今后的文章中會有詳述。

############################################################

五、消息傳輸?shù)氖聞?wù)定義

之前討論了consumer和producer是怎么工作的，現(xiàn)在來討論一下數(shù)據(jù)傳輸方面。數(shù)據(jù)傳輸?shù)氖聞?wù)定義通常有以下三種級別：

• 最多一次: 消息不會被重復(fù)發(fā)送，最多被傳輸一次，但也有可能一次不傳輸。
• 最少一次: 消息不會被漏發(fā)送，最少被傳輸一次，但也有可能被重復(fù)傳輸.
• 精確的一次（Exactly once）: 不會漏傳輸也不會重復(fù)傳輸,每個消息都傳輸被一次而且僅僅被傳輸一次，這是大家所期望的。

大多數(shù)消息系統(tǒng)聲稱可以做到“精確的一次”，但是仔細(xì)閱讀它們的的文檔可以看到里面存在誤導(dǎo)，比如沒有說明當(dāng)consumer或producer失敗時怎么樣，或者當(dāng)有多個consumer并行時怎么樣，或?qū)懭胗脖P的數(shù)據(jù)丟失時又會怎么樣。kafka的做法要更先進(jìn)一些。當(dāng)發(fā)布消息時，Kafka有一個“committed”的概念，一旦消息被提交了，只要消息被寫入的分區(qū)的所在的副本broker是活動的，數(shù)據(jù)就不會丟失。關(guān)于副本的活動的概念，下節(jié)文檔會討論。現(xiàn)在假設(shè)broker是不會down的。

如果producer發(fā)布消息時發(fā)生了網(wǎng)絡(luò)錯誤，但又不確定實(shí)在提交之前發(fā)生的還是提交之后發(fā)生的，這種情況雖然不常見，但是必須考慮進(jìn)去，現(xiàn)在Kafka版本還沒有解決這個問題，將來的版本正在努力嘗試解決。

并不是所有的情況都需要“精確的一次”這樣高的級別，Kafka允許producer靈活的指定級別。比如producer可以指定必須等待消息被提交的通知，或者完全的異步發(fā)送消息而不等待任何通知，或者僅僅等待leader聲明它拿到了消息（followers沒有必要）。

現(xiàn)在從consumer的方面考慮這個問題，所有的副本都有相同的日志文件和相同的offset，consumer維護(hù)自己消費(fèi)的消息的offset，如果consumer不會崩潰當(dāng)然可以在內(nèi)存中保存這個值，當(dāng)然誰也不能保證這點(diǎn)。如果consumer崩潰了，會有另外一個consumer接著消費(fèi)消息，它需要從一個合適的offset繼續(xù)處理。這種情況下可以有以下選擇：

• consumer可以先讀取消息，然后將offset寫入日志文件中，然后再處理消息。這存在一種可能就是在存儲offset后還沒處理消息就crash了，新的consumer繼續(xù)從這個offset處理，那么就會有些消息永遠(yuǎn)不會被處理，這就是上面說的“最多一次”。
• consumer可以先讀取消息，處理消息，最后記錄offset，當(dāng)然如果在記錄offset之前就crash了，新的consumer會重復(fù)的消費(fèi)一些消息，這就是上面說的“最少一次”。
• “精確一次”可以通過將提交分為兩個階段來解決：保存了offset后提交一次，消息處理成功之后再提交一次。但是還有個更簡單的做法：將消息的offset和消息被處理后的結(jié)果保存在一起。比如用Hadoop ETL處理消息時，將處理后的結(jié)果和offset同時保存在HDFS中，這樣就能保證消息和offser同時被處理了。

############################################################

六、性能優(yōu)化

Kafka在提高效率方面做了很大努力。Kafka的一個主要使用場景是處理網(wǎng)站活動日志，吞吐量是非常大的，每個頁面都會產(chǎn)生好多次寫操作。讀方面，假設(shè)每個消息只被消費(fèi)一次，讀的量的也是很大的，Kafka也盡量使讀的操作更輕量化。

我們之前討論了磁盤的性能問題，線性讀寫的情況下影響磁盤性能問題大約有兩個方面：太多的瑣碎的I/O操作和太多的字節(jié)拷貝。I/O問題發(fā)生在客戶端和服務(wù)端之間，也發(fā)生在服務(wù)端內(nèi)部的持久化的操作中。

消息集（message set）
為了避免這些問題，Kafka建立了“消息集（message set）”的概念，將消息組織到一起，作為處理的單位。以消息集為單位處理消息，比以單個的消息為單位處理，會提升不少性能。Producer把消息集一塊發(fā)送給服務(wù)端，而不是一條條的發(fā)送；服務(wù)端把消息集一次性的追加到日志文件中，這樣減少了瑣碎的I/O操作。consumer也可以一次性的請求一個消息集。

另外一個性能優(yōu)化是在字節(jié)拷貝方面。在低負(fù)載的情況下這不是問題，但是在高負(fù)載的情況下它的影響還是很大的。為了避免這個問題，Kafka使用了標(biāo)準(zhǔn)的二進(jìn)制消息格式，這個格式可以在producer,broker和producer之間共享而無需做任何改動。

zero copy
Broker維護(hù)的消息日志僅僅是一些目錄文件，消息集以固定隊的格式寫入到日志文件中，這個格式producer和consumer是共享的，這使得Kafka可以一個很重要的點(diǎn)進(jìn)行優(yōu)化：消息在網(wǎng)絡(luò)上的傳遞。現(xiàn)代的unix操作系統(tǒng)提供了高性能的將數(shù)據(jù)從頁面緩存發(fā)送到socket的系統(tǒng)函數(shù)，在linux中，這個函數(shù)是sendfile.

為了更好的理解sendfile的好處，我們先來看下一般將數(shù)據(jù)從文件發(fā)送到socket的數(shù)據(jù)流向：

• 操作系統(tǒng)把數(shù)據(jù)從文件拷貝內(nèi)核中的頁緩存中
• 應(yīng)用程序從頁緩存從把數(shù)據(jù)拷貝自己的內(nèi)存緩存中
• 應(yīng)用程序?qū)?shù)據(jù)寫入到內(nèi)核中socket緩存中
• 操作系統(tǒng)把數(shù)據(jù)從socket緩存中拷貝到網(wǎng)卡接口緩存，從這里發(fā)送到網(wǎng)絡(luò)上。

這顯然是低效率的，有4次拷貝和2次系統(tǒng)調(diào)用。Sendfile通過直接將數(shù)據(jù)從頁面緩存發(fā)送網(wǎng)卡接口緩存，避免了重復(fù)拷貝，大大的優(yōu)化了性能。
在一個多consumers的場景里，數(shù)據(jù)僅僅被拷貝到頁面緩存一次而不是每次消費(fèi)消息的時候都重復(fù)的進(jìn)行拷貝。這使得消息以近乎網(wǎng)絡(luò)帶寬的速率發(fā)送出去。這樣在磁盤層面你幾乎看不到任何的讀操作，因為數(shù)據(jù)都是從頁面緩存中直接發(fā)送到網(wǎng)絡(luò)上去了。
這篇文章詳細(xì)介紹了sendfile和zero-copy技術(shù)在Java方面的應(yīng)用。

數(shù)據(jù)壓縮
很多時候，性能的瓶頸并非CPU或者硬盤而是網(wǎng)絡(luò)帶寬，對于需要在數(shù)據(jù)中心之間傳送大量數(shù)據(jù)的應(yīng)用更是如此。當(dāng)然用戶可以在沒有Kafka支持的情況下各自壓縮自己的消息，但是這將導(dǎo)致較低的壓縮率，因為相比于將消息單獨(dú)壓縮，將大量文件壓縮在一起才能起到最好的壓縮效果。
Kafka采用了端到端的壓縮：因為有“消息集”的概念，客戶端的消息可以一起被壓縮后送到服務(wù)端，并以壓縮后的格式寫入日志文件，以壓縮的格式發(fā)送到consumer，消息從producer發(fā)出到consumer拿到都被是壓縮的，只有在consumer使用的時候才被解壓縮，所以叫做“端到端的壓縮”。
Kafka支持GZIP和Snappy壓縮協(xié)議。更詳細(xì)的內(nèi)容可以查看這里。

##########################################################

七、Producer和Consumer


Kafka Producer消息發(fā)送
producer直接將數(shù)據(jù)發(fā)送到broker的leader(主節(jié)點(diǎn))，不需要在多個節(jié)點(diǎn)進(jìn)行分發(fā)。為了幫助producer做到這點(diǎn)，所有的Kafka節(jié)點(diǎn)都可以及時的告知:哪些節(jié)點(diǎn)是活動的，目標(biāo)topic目標(biāo)分區(qū)的leader在哪。這樣producer就可以直接將消息發(fā)送到目的地了。

客戶端控制消息將被分發(fā)到哪個分區(qū)。可以通過負(fù)載均衡隨機(jī)的選擇，或者使用分區(qū)函數(shù)。Kafka允許用戶實(shí)現(xiàn)分區(qū)函數(shù)，指定分區(qū)的key，將消息hash到不同的分區(qū)上(當(dāng)然有需要的話，也可以覆蓋這個分區(qū)函數(shù)自己實(shí)現(xiàn)邏輯).比如如果你指定的key是user id，那么同一個用戶發(fā)送的消息都被發(fā)送到同一個分區(qū)上。經(jīng)過分區(qū)之后，consumer就可以有目的的消費(fèi)某個分區(qū)的消息。

異步發(fā)送
批量發(fā)送可以很有效的提高發(fā)送效率。Kafka producer的異步發(fā)送模式允許進(jìn)行批量發(fā)送，先將消息緩存在內(nèi)存中，然后一次請求批量發(fā)送出去。這個策略可以配置的，比如可以指定緩存的消息達(dá)到某個量的時候就發(fā)出去，或者緩存了固定的時間后就發(fā)送出去（比如100條消息就發(fā)送，或者每5秒發(fā)送一次）。這種策略將大大減少服務(wù)端的I/O次數(shù)。

既然緩存是在producer端進(jìn)行的，那么當(dāng)producer崩潰時，這些消息就會丟失。Kafka0.8.1的異步發(fā)送模式還不支持回調(diào)，就不能在發(fā)送出錯時進(jìn)行處理。Kafka 0.9可能會增加這樣的回調(diào)函數(shù)。見Proposed Producer API.

Kafka Consumer
Kafa consumer消費(fèi)消息時，向broker發(fā)出"fetch"請求去消費(fèi)特定分區(qū)的消息。consumer指定消息在日志中的偏移量（offset），就可以消費(fèi)從這個位置開始的消息。customer擁有了offset的控制權(quán)，可以向后回滾去重新消費(fèi)之前的消息，這是很有意義的。

推還是拉？
Kafka最初考慮的問題是，customer應(yīng)該從brokes拉取消息還是brokers將消息推送到consumer，也就是pull還push。在這方面，Kafka遵循了一種大部分消息系統(tǒng)共同的傳統(tǒng)的設(shè)計：producer將消息推送到broker，consumer從broker拉取消息。

一些消息系統(tǒng)比如Scribe和Apache Flume采用了push模式，將消息推送到下游的consumer。這樣做有好處也有壞處：由broker決定消息推送的速率，對于不同消費(fèi)速率的consumer就不太好處理了。消息系統(tǒng)都致力于讓consumer以最大的速率最快速的消費(fèi)消息，但不幸的是，push模式下，當(dāng)broker推送的速率遠(yuǎn)大于consumer消費(fèi)的速率時，consumer恐怕就要崩潰了。最終Kafka還是選取了傳統(tǒng)的pull模式。

Pull模式的另外一個好處是consumer可以自主決定是否批量的從broker拉取數(shù)據(jù)。Push模式必須在不知道下游consumer消費(fèi)能力和消費(fèi)策略的情況下決定是立即推送每條消息還是緩存之后批量推送。如果為了避免consumer崩潰而采用較低的推送速率，將可能導(dǎo)致一次只推送較少的消息而造成浪費(fèi)。Pull模式下，consumer就可以根據(jù)自己的消費(fèi)能力去決定這些策略。

Pull有個缺點(diǎn)是，如果broker沒有可供消費(fèi)的消息，將導(dǎo)致consumer不斷在循環(huán)中輪詢，直到新消息到t達(dá)。為了避免這點(diǎn)，Kafka有個參數(shù)可以讓consumer阻塞知道新消息到達(dá)(當(dāng)然也可以阻塞知道消息的數(shù)量達(dá)到某個特定的量這樣就可以批量發(fā)送)。

消費(fèi)狀態(tài)跟蹤
對消費(fèi)消息狀態(tài)的記錄也是很重要的。
大部分消息系統(tǒng)在broker端的維護(hù)消息被消費(fèi)的記錄：一個消息被分發(fā)到consumer后broker就馬上進(jìn)行標(biāo)記或者等待customer的通知后進(jìn)行標(biāo)記。這樣也可以在消息在消費(fèi)后立馬就刪除以減少空間占用。

但是這樣會不會有什么問題呢？如果一條消息發(fā)送出去之后就立即被標(biāo)記為消費(fèi)過的，一旦consumer處理消息時失敗了（比如程序崩潰）消息就丟失了。為了解決這個問題，很多消息系統(tǒng)提供了另外一個個功能：當(dāng)消息被發(fā)送出去之后僅僅被標(biāo)記為已發(fā)送狀態(tài)，當(dāng)接到consumer已經(jīng)消費(fèi)成功的通知后才標(biāo)記為已被消費(fèi)的狀態(tài)。這雖然解決了消息丟失的問題，但產(chǎn)生了新問題，首先如果consumer處理消息成功了但是向broker發(fā)送響應(yīng)時失敗了，這條消息將被消費(fèi)兩次。第二個問題時，broker必須維護(hù)每條消息的狀態(tài)，并且每次都要先鎖住消息然后更改狀態(tài)然后釋放鎖。這樣麻煩又來了，且不說要維護(hù)大量的狀態(tài)數(shù)據(jù)，比如如果消息發(fā)送出去但沒有收到消費(fèi)成功的通知，這條消息將一直處于被鎖定的狀態(tài)，
Kafka采用了不同的策略。Topic被分成了若干分區(qū)，每個分區(qū)在同一時間只被一個consumer消費(fèi)。這意味著每個分區(qū)被消費(fèi)的消息在日志中的位置僅僅是一個簡單的整數(shù)：offset。這樣就很容易標(biāo)記每個分區(qū)消費(fèi)狀態(tài)就很容易了，僅僅需要一個整數(shù)而已。這樣消費(fèi)狀態(tài)的跟蹤就很簡單了。

這帶來了另外一個好處：consumer可以把offset調(diào)成一個較老的值，去重新消費(fèi)老的消息。這對傳統(tǒng)的消息系統(tǒng)來說看起來有些不可思議，但確實(shí)是非常有用的，誰規(guī)定了一條消息只能被消費(fèi)一次呢？consumer發(fā)現(xiàn)解析數(shù)據(jù)的程序有bug，在修改bug后再來解析一次消息，看起來是很合理的額呀！

離線處理消息
高級的數(shù)據(jù)持久化允許consumer每個隔一段時間批量的將數(shù)據(jù)加載到線下系統(tǒng)中比如Hadoop或者數(shù)據(jù)倉庫。這種情況下，Hadoop可以將加載任務(wù)分拆，拆成每個broker或每個topic或每個分區(qū)一個加載任務(wù)。Hadoop具有任務(wù)管理功能，當(dāng)一個任務(wù)失敗了就可以重啟而不用擔(dān)心數(shù)據(jù)被重新加載，只要從上次加載的位置繼續(xù)加載消息就可以了。

#########################################################


八、主從同步


Kafka允許topic的分區(qū)擁有若干副本，這個數(shù)量是可以配置的，你可以為每個topci配置副本的數(shù)量。Kafka會自動在每個個副本上備份數(shù)據(jù)，所以當(dāng)一個節(jié)點(diǎn)down掉時數(shù)據(jù)依然是可用的。

Kafka的副本功能不是必須的，你可以配置只有一個副本，這樣其實(shí)就相當(dāng)于只有一份數(shù)據(jù)。
創(chuàng)建副本的單位是topic的分區(qū)，每個分區(qū)都有一個leader和零或多個followers.所有的讀寫操作都由leader處理，一般分區(qū)的數(shù)量都比broker的數(shù)量多的多，各分區(qū)的leader均勻的分布在brokers中。所有的followers都復(fù)制leader的日志，日志中的消息和順序都和leader中的一致。flowers向普通的consumer那樣從leader那里拉取消息并保存在自己的日志文件中。

許多分布式的消息系統(tǒng)自動的處理失敗的請求，它們對一個節(jié)點(diǎn)是否

著（alive）”有著清晰的定義。Kafka判斷一個節(jié)點(diǎn)是否活著有兩個條件：

• 節(jié)點(diǎn)必須可以維護(hù)和ZooKeeper的連接，Zookeeper通過心跳機(jī)制檢查每個節(jié)點(diǎn)的連接。
• 如果節(jié)點(diǎn)是個follower,他必須能及時的同步leader的寫操作，延時不能太久。

符合以上條件的節(jié)點(diǎn)準(zhǔn)確的說應(yīng)該是“同步中的（in sync）”，而不是模糊的說是“活著的”或是“失敗的”。Leader會追蹤所有“同步中”的節(jié)點(diǎn)，一旦一個down掉了，或是卡住了，或是延時太久，leader就會把它移除。至于延時多久算是“太久”，是由參數(shù)replica.lag.max.messages決定的，怎樣算是卡住了，怎是由參數(shù)replica.lag.time.max.ms決定的。?

只有當(dāng)消息被所有的副本加入到日志中時，才算是“committed”，只有committed的消息才會發(fā)送給consumer，這樣就不用擔(dān)心一旦leader down掉了消息會丟失。Producer也可以選擇是否等待消息被提交的通知，這個是由參數(shù)request.required.acks決定的。
Kafka保證只要有一個“同步中”的節(jié)點(diǎn)，“committed”的消息就不會丟失。

Leader的選擇
Kafka的核心是日志文件，日志文件在集群中的同步是分布式數(shù)據(jù)系統(tǒng)最基礎(chǔ)的要素。

如果leaders永遠(yuǎn)不會down的話我們就不需要followers了！一旦leader down掉了，需要在followers中選擇一個新的leader.但是followers本身有可能延時太久或者crash，所以必須選擇高質(zhì)量的follower作為leader.必須保證，一旦一個消息被提交了，但是leader down掉了，新選出的leader必須可以提供這條消息。大部分的分布式系統(tǒng)采用了多數(shù)投票法則選擇新的leader,對于多數(shù)投票法則，就是根據(jù)所有副本節(jié)點(diǎn)的狀況動態(tài)的選擇最適合的作為leader.Kafka并不是使用這種方法。

Kafaka動態(tài)維護(hù)了一個同步狀態(tài)的副本的集合（a set of in-sync replicas），簡稱ISR，在這個集合中的節(jié)點(diǎn)都是和leader保持高度一致的，任何一條消息必須被這個集合中的每個節(jié)點(diǎn)讀取并追加到日志中了，才回通知外部這個消息已經(jīng)被提交了。因此這個集合中的任何一個節(jié)點(diǎn)隨時都可以被選為leader.ISR在ZooKeeper中維護(hù)。ISR中有f+1個節(jié)點(diǎn)，就可以允許在f個節(jié)點(diǎn)down掉的情況下不會丟失消息并正常提供服。ISR的成員是動態(tài)的，如果一個節(jié)點(diǎn)被淘汰了，當(dāng)它重新達(dá)到“同步中”的狀態(tài)時，他可以重新加入ISR.這種leader的選擇方式是非常快速的，適合kafka的應(yīng)用場景。

一個邪惡的想法：如果所有節(jié)點(diǎn)都down掉了怎么辦？Kafka對于數(shù)據(jù)不會丟失的保證，是基于至少一個節(jié)點(diǎn)是存活的，一旦所有節(jié)點(diǎn)都down了，這個就不能保證了。
實(shí)際應(yīng)用中，當(dāng)所有的副本都down掉時，必須及時作出反應(yīng)。可以有以下兩種選擇:

• 等待ISR中的任何一個節(jié)點(diǎn)恢復(fù)并擔(dān)任leader。
• 選擇所有節(jié)點(diǎn)中（不只是ISR）第一個恢復(fù)的節(jié)點(diǎn)作為leader.

這是一個在可用性和連續(xù)性之間的權(quán)衡。如果等待ISR中的節(jié)點(diǎn)恢復(fù)，一旦ISR中的節(jié)點(diǎn)起不起來或者數(shù)據(jù)都是了，那集群就永遠(yuǎn)恢復(fù)不了了。如果等待ISR意外的節(jié)點(diǎn)恢復(fù)，這個節(jié)點(diǎn)的數(shù)據(jù)就會被作為線上數(shù)據(jù)，有可能和真實(shí)的數(shù)據(jù)有所出入，因為有些數(shù)據(jù)它可能還沒同步到。Kafka目前選擇了第二種策略，在未來的版本中將使這個策略的選擇可配置，可以根據(jù)場景靈活的選擇。
這種窘境不只Kafka會遇到，幾乎所有的分布式數(shù)據(jù)系統(tǒng)都會遇到。

副本管理
以上僅僅以一個topic一個分區(qū)為例子進(jìn)行了討論，但實(shí)際上一個Kafka將會管理成千上萬的topic分區(qū).Kafka盡量的使所有分區(qū)均勻的分布到集群所有的節(jié)點(diǎn)上而不是集中在某些節(jié)點(diǎn)上，另外主從關(guān)系也盡量均衡這樣每個幾點(diǎn)都會擔(dān)任一定比例的分區(qū)的leader.
優(yōu)化leader的選擇過程也是很重要的，它決定了系統(tǒng)發(fā)生故障時的空窗期有多久。Kafka選擇一個節(jié)點(diǎn)作為“controller”,當(dāng)發(fā)現(xiàn)有節(jié)點(diǎn)down掉的時候它負(fù)責(zé)在游泳分區(qū)的所有節(jié)點(diǎn)中選擇新的leader,這使得Kafka可以批量的高效的管理所有分區(qū)節(jié)點(diǎn)的主從關(guān)系。如果controller down掉了，活著的節(jié)點(diǎn)中的一個會備切換為新的controller.

###################################################

九、客戶端API

Kafka Producer APIs
Procuder API有兩種：kafka.producer.SyncProducer和kafka.producer.async.AsyncProducer.它們都實(shí)現(xiàn)了同一個接口：

class Producer {

/* 將消息發(fā)送到指定分區(qū) */

publicvoid send(kafka.javaapi.producer.ProducerData<K,V> producerData);

/* 批量發(fā)送一批消息 */

publicvoid send(java.util.List<kafka.javaapi.producer.ProducerData<K,V>> producerData);

/* 關(guān)閉producer */

publicvoid close();

}

復(fù)制代碼

Producer API提供了以下功能：

• 可以將多個消息緩存到本地隊列里，然后異步的批量發(fā)送到broker，可以通過參數(shù)producer.type=async做到。緩存的大小可以通過一些參數(shù)指定：queue.time和batch.size。一個后臺線程（(kafka.producer.async.ProducerSendThread）從隊列中取出數(shù)據(jù)并讓kafka.producer.EventHandler將消息發(fā)送到broker，也可以通過參數(shù)event.handler定制handler，在producer端處理數(shù)據(jù)的不同的階段注冊處理器，比如可以對這一過程進(jìn)行日志追蹤，或進(jìn)行一些監(jiān)控。只需實(shí)現(xiàn)kafka.producer.async.CallbackHandler接口，并在callback.handler中配置。
• 自己編寫Encoder來序列化消息，只需實(shí)現(xiàn)下面這個接口。默認(rèn)的Encoder是kafka.serializer.DefaultEncoder。
  
  • interface Encoder<T> {
  • public Message toMessage(T data);
  • }
• 提供了基于Zookeeper的broker自動感知能力，可以通過參數(shù)zk.connect實(shí)現(xiàn)。如果不使用Zookeeper，也可以使用broker.list參數(shù)指定一個靜態(tài)的brokers列表，這樣消息將被隨機(jī)的發(fā)送到一個broker上，一旦選中的broker失敗了，消息發(fā)送也就失敗了。
• 通過分區(qū)函數(shù)kafka.producer.Partitioner類對消息分區(qū)。
  
  • interface Partitioner<T> {
  • int partition(T key, int numPartitions);
  • }
  
  分區(qū)函數(shù)有兩個參數(shù)：key和可用的分區(qū)數(shù)量，從分區(qū)列表中選擇一個分區(qū)并返回id。默認(rèn)的分區(qū)策略是hash(key)%numPartitions.如果key是null,就隨機(jī)的選擇一個。可以通過參數(shù)partitioner.class定制分區(qū)函數(shù)。

KafKa Consumer APIs

Consumer API有兩個級別。低級別的和一個指定的broker保持連接，并在接收完消息后關(guān)閉連接，這個級別是無狀態(tài)的，每次讀取消息都帶著offset。
高級別的API隱藏了和brokers連接的細(xì)節(jié)，在不必關(guān)心服務(wù)端架構(gòu)的情況下和服務(wù)端通信。還可以自己維護(hù)消費(fèi)狀態(tài)，并可以通過一些條件指定訂閱特定的topic,比如白名單黑名單或者正則表達(dá)式。

低級別的API

class SimpleConsumer {

/*向一個broker發(fā)送讀取請求并得到消息集 */

public ByteBufferMessageSet fetch(FetchRequest request);

/*向一個broker發(fā)送讀取請求并得到一個相應(yīng)集 */

public MultiFetchResponse multifetch(List<FetchRequest> fetches);

/**

* 得到指定時間之前的offsets

* 返回值是offsets列表，以倒序排序

* @param time: 時間，毫秒,

* 如果指定為OffsetRequest$.MODULE$.LATIEST_TIME(), 得到最新的offset.

* 如果指定為OffsetRequest$.MODULE$.EARLIEST_TIME(),得到最老的offset.

*/

publiclong[] getOffsetsBefore(String topic, int partition, long time, int maxNumOffsets);

}

復(fù)制代碼

低級別的API是高級別API實(shí)現(xiàn)的基礎(chǔ)，也是為了一些對維持消費(fèi)狀態(tài)有特殊需求的場景，比如Hadoop?consumer這樣的離線consumer。

高級別的API

/* 創(chuàng)建連接 */

ConsumerConnector connector = Consumer.create(consumerConfig);

interface ConsumerConnector {

/**

* 這個方法可以得到一個流的列表，每個流都是MessageAndMetadata的迭代，通過MessageAndMetadata可以拿到消息和其他的元數(shù)據(jù)（目前之后topic）

* Input: a map of <topic, #streams>

* Output: a map of <topic, list of message streams>

*/

public Map<String,List<KafkaStream>> createMessageStreams(Map<String,Int> topicCountMap);

/**

* 你也可以得到一個流的列表，它包含了符合TopicFiler的消息的迭代，

* 一個TopicFilter是一個封裝了白名單或黑名單的正則表達(dá)式。

*/

public List<KafkaStream> createMessageStreamsByFilter(

TopicFilter topicFilter, int numStreams);

/* 提交目前消費(fèi)到的offset */

public commitOffsets()

/* 關(guān)閉連接 */

public shutdown()

}

復(fù)制代碼

這個API圍繞著由KafkaStream實(shí)現(xiàn)的迭代器展開，每個流代表一系列從一個或多個分區(qū)多和broker上匯聚來的消息，每個流由一個線程處理，所以客戶端可以在創(chuàng)建的時候通過參數(shù)指定想要幾個流。一個流是多個分區(qū)多個broker的合并，但是每個分區(qū)的消息只會流向一個流。

每調(diào)用一次createMessageStreams都會將consumer注冊到topic上，這樣consumer和brokers之間的負(fù)載均衡就會進(jìn)行調(diào)整。API鼓勵每次調(diào)用創(chuàng)建更多的topic流以減少這種調(diào)整。createMessageStreamsByFilter方法注冊監(jiān)聽可以感知新的符合filter的tipic。

#######################################################

十、消息和日志



消息由一個固定長度的頭部和可變長度的字節(jié)數(shù)組組成。頭部包含了一個版本號和CRC32校驗碼。

/**

* 具有N個字節(jié)的消息的格式如下

*

* 如果版本號是0

*

* 1. 1個字節(jié)的 "magic" 標(biāo)記

*

* 2. 4個字節(jié)的CRC32校驗碼

*

* 3. N - 5個字節(jié)的具體信息

*

* 如果版本號是1

*

* 1. 1個字節(jié)的 "magic" 標(biāo)記

*

* 2.1個字節(jié)的參數(shù)允許標(biāo)注一些附加的信息比如是否壓縮了，解碼類型等

*

* 3.4個字節(jié)的CRC32校驗碼

*

* 4. N - 6 個字節(jié)的具體信息

*

*/

復(fù)制代碼

日志一個叫做“my_topic”且有兩個分區(qū)的的topic,它的日志有兩個文件夾組成，my_topic_0和my_topic_1,每個文件夾里放著具體的數(shù)據(jù)文件，每個數(shù)據(jù)文件都是一系列的日志實(shí)體，每個日志實(shí)體有一個4個字節(jié)的整數(shù)N標(biāo)注消息的長度，后邊跟著N個字節(jié)的消息。每個消息都可以由一個64位的整數(shù)offset標(biāo)注，offset標(biāo)注了這條消息在發(fā)送到這個分區(qū)的消息流中的起始位置。每個日志文件的名稱都是這個文件第一條日志的offset.所以第一個日志文件的名字就是00000000000.kafka.所以每相鄰的兩個文件名字的差就是一個數(shù)字S,S差不多就是配置文件中指定的日志文件的最大容量。
消息的格式都由一個統(tǒng)一的接口維護(hù)，所以消息可以在producer,broker和consumer之間無縫的傳遞。存儲在硬盤上的消息格式如下所示：

• 消息長度: 4 bytes (value: 1+4+n)
• 版本號: 1 byte
• CRC校驗碼: 4 bytes
• 具體的消息: n bytes

<ignore_js_op>?


寫操作消息被不斷的追加到最后一個日志的末尾，當(dāng)日志的大小達(dá)到一個指定的值時就會產(chǎn)生一個新的文件。對于寫操作有兩個參數(shù)，一個規(guī)定了消息的數(shù)量達(dá)到這個值時必須將數(shù)據(jù)刷新到硬盤上，另外一個規(guī)定了刷新到硬盤的時間間隔，這對數(shù)據(jù)的持久性是個保證，在系統(tǒng)崩潰的時候只會丟失一定數(shù)量的消息或者一個時間段的消息。

讀操作
讀操作需要兩個參數(shù)：一個64位的offset和一個S字節(jié)的最大讀取量。S通常比單個消息的大小要大，但在一些個別消息比較大的情況下，S會小于單個消息的大小。這種情況下讀操作會不斷重試，每次重試都會將讀取量加倍，直到讀取到一個完整的消息。可以配置單個消息的最大值，這樣服務(wù)器就會拒絕大小超過這個值的消息。也可以給客戶端指定一個嘗試讀取的最大上限，避免為了讀到一個完整的消息而無限次的重試。
在實(shí)際執(zhí)行讀取操縱時，首先需要定位數(shù)據(jù)所在的日志文件，然后根據(jù)offset計算出在這個日志中的offset(前面的的offset是整個分區(qū)的offset),然后在這個offset的位置進(jìn)行讀取。定位操作是由二分查找法完成的，Kafka在內(nèi)存中為每個文件維護(hù)了offset的范圍。

下面是發(fā)送給consumer的結(jié)果的格式：

MessageSetSend (fetch result)

total length? ???: 4 bytes

error code? ?? ? : 2 bytes

message 1? ?? ???: x bytes

...

message n? ?? ???: x bytes

MultiMessageSetSend (multiFetch result)

total length? ?? ? : 4 bytes

error code? ?? ?? ?: 2 bytes

messageSetSend 1

...

messageSetSend n

復(fù)制代碼

刪除
日志管理器允許定制刪除策略。目前的策略是刪除修改時間在N天之前的日志（按時間刪除），也可以使用另外一個策略：保留最后的N GB數(shù)據(jù)的策略(按大小刪除)。為了避免在刪除時阻塞讀操作，采用了copy-on-write形式的實(shí)現(xiàn)，刪除操作進(jìn)行時，讀取操作的二分查找功能實(shí)際是在一個靜態(tài)的快照副本上進(jìn)行的，這類似于Java的CopyOnWriteArrayList。

可靠性保證
日志文件有一個可配置的參數(shù)M，緩存超過這個數(shù)量的消息將被強(qiáng)行刷新到硬盤。一個日志矯正線程將循環(huán)檢查最新的日志文件中的消息確認(rèn)每個消息都是合法的。合法的標(biāo)準(zhǔn)為：所有文件的大小的和最大的offset小于日志文件的大小，并且消息的CRC32校驗碼與存儲在消息實(shí)體中的校驗碼一致。如果在某個offset發(fā)現(xiàn)不合法的消息，從這個offset到下一個合法的offset之間的內(nèi)容將被移除。
有兩種情況必須考慮：
1，當(dāng)發(fā)生崩潰時有些數(shù)據(jù)塊未能寫入。
2，寫入了一些空白數(shù)據(jù)塊。第二種情況的原因是，對于每個文件，操作系統(tǒng)都有一個inode（inode是指在許多“類Unix文件系統(tǒng)”中的一種數(shù)據(jù)結(jié)構(gòu)。每個inode保存了文件系統(tǒng)中的一個文件系統(tǒng)對象,包括文件、目錄、大小、設(shè)備文件、socket、管道, 等等），但無法保證更新inode和寫入數(shù)據(jù)的順序，當(dāng)inode保存的大小信息被更新了，但寫入數(shù)據(jù)時發(fā)生了崩潰，就產(chǎn)生了空白數(shù)據(jù)塊。CRC校驗碼可以檢查這些塊并移除，當(dāng)然因為崩潰而未寫入的數(shù)據(jù)塊也就丟失了。

轉(zhuǎn)自：http://www.aboutyun.com/thread-12882-1-1.html

http://chengjianxiaoxue.iteye.com/blog/2190324

超強(qiáng)干貨來襲 云風(fēng)專訪：近40年碼齡，通宵達(dá)旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的Kafka入门经典教程【转】的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。