一、基本概念
介紹
Kafka是一個(gè)分布式的、可分區(qū)的、可復(fù)制的消息系統(tǒng)。它提供了普通消息系統(tǒng)的功能，但具有自己獨(dú)特的設(shè)計(jì)。
這個(gè)獨(dú)特的設(shè)計(jì)是什么樣的呢？
首先讓我們看幾個(gè)基本的消息系統(tǒng)術(shù)語(yǔ)：
Kafka將消息以topic為單位進(jìn)行歸納。
將向Kafka topic發(fā)布消息的程序成為producers.
將預(yù)訂topics并消費(fèi)消息的程序成為consumer.
Kafka以集群的方式運(yùn)行，可以由一個(gè)或多個(gè)服務(wù)組成，每個(gè)服務(wù)叫做一個(gè)broker.
producers通過(guò)網(wǎng)絡(luò)將消息發(fā)送到Kafka集群，集群向消費(fèi)者提供消息，如下圖所示：
客戶端和服務(wù)端通過(guò)TCP協(xié)議通信。Kafka提供了Java客戶端，并且對(duì)多種語(yǔ)言都提供了支持。
Topics 和Logs
先來(lái)看一下Kafka提供的一個(gè)抽象概念:topic.
一個(gè)topic是對(duì)一組消息的歸納。對(duì)每個(gè)topic，Kafka 對(duì)它的日志進(jìn)行了分區(qū)，如下圖所示：
每個(gè)分區(qū)都由一系列有序的、不可變的消息組成，這些消息被連續(xù)的追加到分區(qū)中。分區(qū)中的每個(gè)消息都有一個(gè)連續(xù)的序列號(hào)叫做offset,用來(lái)在分區(qū)中唯一的標(biāo)識(shí)這個(gè)消息。
在一個(gè)可配置的時(shí)間段內(nèi)，Kafka集群保留所有發(fā)布的消息，不管這些消息有沒有被消費(fèi)。比如，如果消息的保存策略被設(shè)置為2天，那么在一個(gè)消息被發(fā)布的兩天時(shí)間內(nèi)，它都是可以被消費(fèi)的。之后它將被丟棄以釋放空間。Kafka的性能是和數(shù)據(jù)量無(wú)關(guān)的常量級(jí)的，所以保留太多的數(shù)據(jù)并不是問題。
實(shí)際上每個(gè)consumer唯一需要維護(hù)的數(shù)據(jù)是消息在日志中的位置，也就是offset.這個(gè)offset有consumer來(lái)維護(hù)：一般情況下隨著consumer不斷的讀取消息，這offset的值不斷增加，但其實(shí)consumer可以以任意的順序讀取消息，比如它可以將offset設(shè)置成為一個(gè)舊的值來(lái)重讀之前的消息。
以上特點(diǎn)的結(jié)合，使Kafka consumers非常的輕量級(jí)：它們可以在不對(duì)集群和其他consumer造成影響的情況下讀取消息。你可以使用命令行來(lái)"tail"消息而不會(huì)對(duì)其他正在消費(fèi)消息的consumer造成影響。
將日志分區(qū)可以達(dá)到以下目的：首先這使得每個(gè)日志的數(shù)量不會(huì)太大，可以在單個(gè)服務(wù)上保存。另外每個(gè)分區(qū)可以單獨(dú)發(fā)布和消費(fèi)，為并發(fā)操作topic提供了一種可能。
分布式
每個(gè)分區(qū)在Kafka集群的若干服務(wù)中都有副本，這樣這些持有副本的服務(wù)可以共同處理數(shù)據(jù)和請(qǐng)求，副本數(shù)量是可以配置的。副本使Kafka具備了容錯(cuò)能力。
每個(gè)分區(qū)都由一個(gè)服務(wù)器作為“l(fā)eader”，零或若干服務(wù)器作為“followers”,leader負(fù)責(zé)處理消息的讀和寫，followers則去復(fù)制leader.如果leader down了，followers中的一臺(tái)則會(huì)自動(dòng)成為leader。集群中的每個(gè)服務(wù)都會(huì)同時(shí)扮演兩個(gè)角色：作為它所持有的一部分分區(qū)的leader，同時(shí)作為其他分區(qū)的followers，這樣集群就會(huì)據(jù)有較好的負(fù)載均衡。
Producers
Producer將消息發(fā)布到它指定的topic中,并負(fù)責(zé)決定發(fā)布到哪個(gè)分區(qū)。通常簡(jiǎn)單的由負(fù)載均衡機(jī)制隨機(jī)選擇分區(qū)，但也可以通過(guò)特定的分區(qū)函數(shù)選擇分區(qū)。使用的更多的是第二種。
Consumers
發(fā)布消息通常有兩種模式：隊(duì)列模式（queuing）和發(fā)布-訂閱模式(publish-subscribe)。隊(duì)列模式中，consumers可以同時(shí)從服務(wù)端讀取消息，每個(gè)消息只被其中一個(gè)consumer讀到；發(fā)布-訂閱模式中消息被廣播到所有的consumer中。Consumers可以加入一個(gè)consumer 組，共同競(jìng)爭(zhēng)一個(gè)topic，topic中的消息將被分發(fā)到組中的一個(gè)成員中。同一組中的consumer可以在不同的程序中，也可以在不同的機(jī)器上。如果所有的consumer都在一個(gè)組中，這就成為了傳統(tǒng)的隊(duì)列模式，在各consumer中實(shí)現(xiàn)負(fù)載均衡。如果所有的consumer都不在不同的組中，這就成為了發(fā)布-訂閱模式，所有的消息都被分發(fā)到所有的consumer中。更常見的是，每個(gè)topic都有若干數(shù)量的consumer組，每個(gè)組都是一個(gè)邏輯上的“訂閱者”，為了容錯(cuò)和更好的穩(wěn)定性，每個(gè)組由若干consumer組成。這其實(shí)就是一個(gè)發(fā)布-訂閱模式，只不過(guò)訂閱者是個(gè)組而不是單個(gè)consumer。
由兩個(gè)機(jī)器組成的集群擁有4個(gè)分區(qū) (P0-P3) 2個(gè)consumer組. A組有兩個(gè)consumerB組有4個(gè)
相比傳統(tǒng)的消息系統(tǒng)，Kafka可以很好的保證有序性。
傳統(tǒng)的隊(duì)列在服務(wù)器上保存有序的消息，如果多個(gè)consumers同時(shí)從這個(gè)服務(wù)器消費(fèi)消息，服務(wù)器就會(huì)以消息存儲(chǔ)的順序向consumer分發(fā)消息。雖然服務(wù)器按順序發(fā)布消息，但是消息是被異步的分發(fā)到各consumer上，所以當(dāng)消息到達(dá)時(shí)可能已經(jīng)失去了原來(lái)的順序，這意味著并發(fā)消費(fèi)將導(dǎo)致順序錯(cuò)亂。為了避免故障，這樣的消息系統(tǒng)通常使用“專用consumer”的概念，其實(shí)就是只允許一個(gè)消費(fèi)者消費(fèi)消息，當(dāng)然這就意味著失去了并發(fā)性。
在這方面Kafka做的更好，通過(guò)分區(qū)的概念，Kafka可以在多個(gè)consumer組并發(fā)的情況下提供較好的有序性和負(fù)載均衡。將每個(gè)分區(qū)分只分發(fā)給一個(gè)consumer組，這樣一個(gè)分區(qū)就只被這個(gè)組的一個(gè)consumer消費(fèi)，就可以順序的消費(fèi)這個(gè)分區(qū)的消息。因?yàn)橛卸鄠€(gè)分區(qū)，依然可以在多個(gè)consumer組之間進(jìn)行負(fù)載均衡。注意consumer組的數(shù)量不能多于分區(qū)的數(shù)量，也就是有多少分區(qū)就允許多少并發(fā)消費(fèi)。
Kafka只能保證一個(gè)分區(qū)之內(nèi)消息的有序性，在不同的分區(qū)之間是不可以的，這已經(jīng)可以滿足大部分應(yīng)用的需求。如果需要topic中所有消息的有序性，那就只能讓這個(gè)topic只有一個(gè)分區(qū)，當(dāng)然也就只有一個(gè)consumer組消費(fèi)它。
二、環(huán)境搭建
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: 啟動(dòng)服務(wù)
Kafka用到了Zookeeper，所有首先啟動(dòng)Zookper，下面簡(jiǎn)單的啟用一個(gè)單實(shí)例的Zookkeeper服務(wù)。可以在命令的結(jié)尾加個(gè)&符號(hào)，這樣就可以啟動(dòng)后離開控制臺(tái)。
> 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)在啟動(dòng)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)建一個(gè)叫做“test”的topic，它只有一個(gè)分區(qū)，一個(gè)副本。
> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
復(fù)制代碼
可以通過(guò)list命令查看創(chuàng)建的topic:
> bin/kafka-topics.sh --list --zookeeper localhost:2181
test
復(fù)制代碼
除了手動(dòng)創(chuàng)建topic，還可以配置broker讓它自動(dòng)創(chuàng)建topic.
Step 4:發(fā)送消息.
Kafka 使用一個(gè)簡(jiǎn)單的命令行producer，從文件中或者從標(biāo)準(zhǔn)輸入中讀取消息并發(fā)送到服務(wù)端。默認(rèn)的每條命令將發(fā)送一條消息。
運(yùn)行producer并在控制臺(tái)中輸一些消息，這些消息將被發(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: 啟動(dòng)consumer
Kafka also has a command line consumer that will dump out messages to standard output.
Kafka也有一個(gè)命令行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ù)制代碼
你在一個(gè)終端中運(yùn)行consumer命令行，另一個(gè)終端中運(yùn)行producer命令行，就可以在一個(gè)終端輸入消息，另一個(gè)終端讀取消息。
這兩個(gè)命令都有自己的可選參數(shù)，可以在運(yùn)行的時(shí)候不加任何參數(shù)可以看到幫助信息。
Step 6: 搭建一個(gè)多個(gè)broker的集群
剛才只是啟動(dòng)了單個(gè)broker，現(xiàn)在啟動(dòng)有3個(gè)broker組成的集群，這些broker節(jié)點(diǎn)也都是在本機(jī)上的：
首先為每個(gè)節(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)注一個(gè)節(jié)點(diǎn)，因?yàn)樵谕粋€(gè)機(jī)器上，所以必須制定不同的端口和日志文件，避免數(shù)據(jù)被覆蓋。
We already have Zookeeper and our single node started, so we just need to start the two new nodes:
剛才已經(jīng)啟動(dòng)可Zookeeper和一個(gè)節(jié)點(diǎn)，現(xiàn)在啟動(dòng)另外兩個(gè)節(jié)點(diǎn)：
> bin/kafka-server-start.sh config/server-1.properties &
...
> bin/kafka-server-start.sh config/server-2.properties &
...
復(fù)制代碼
創(chuàng)建一個(gè)擁有3個(gè)副本的topic:
> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 1 --topic my-replicated-topic
復(fù)制代碼
現(xiàn)在我們搭建了一個(gè)集群，怎么知道每個(gè)節(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ù)制代碼
下面解釋一下這些輸出。第一行是對(duì)所有分區(qū)的一個(gè)描述，然后每個(gè)分區(qū)都會(huì)對(duì)應(yīng)一行，因?yàn)槲覀冎挥幸粋€(gè)分區(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
...
my test message 1
my test message 2
^C
測(cè)試一下容錯(cuò)能力.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ù)制代碼
另外一個(gè)節(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ù)制代碼
看來(lái)Kafka的容錯(cuò)機(jī)制還是不錯(cuò)的。
三、搭建Kafka開發(fā)環(huán)境
我們搭建了kafka的服務(wù)器，并可以使用Kafka的命令行工具創(chuàng)建topic，發(fā)送和接收消息。下面我們來(lái)搭建kafka的開發(fā)環(huán)境。
添加依賴
搭建開發(fā)環(huán)境需要引入kafka的jar包，一種方式是將Kafka安裝包中l(wèi)ib下的jar包加入到項(xiàng)目的classpath中，這種比較簡(jiǎn)單了。不過(guò)我們使用另一種更加流行的方式：使用maven管理jar包依賴。
創(chuàng)建好maven項(xiàng)目后，在pom.xml中添加以下依賴：
org.apache.kafka
kafka_2.10
0.8.0
復(fù)制代碼
添加依賴后你會(huì)發(fā)現(xiàn)有兩個(gè)jar包的依賴找不到。沒關(guān)系我都幫你想好了，點(diǎn)擊這里下載這兩個(gè)jar包，解壓后你有兩種選擇，第一種是使用mvn的install命令將jar包安裝到本地倉(cāng)庫(kù)，另一種是直接將解壓后的文件夾拷貝到mvn本地倉(cāng)庫(kù)的com文件夾下，比如我的本地倉(cāng)庫(kù)是d:\mvn,完成后我的目錄結(jié)構(gòu)是這樣的：
配置程序
首先是一個(gè)充當(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 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();
}
}
}
}
復(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 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();
}
}
}
}
復(fù)制代碼
簡(jiǎn)單的發(fā)送接收
運(yùn)行下面這個(gè)程序，就可以進(jìn)行簡(jiǎ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ù)制代碼
高級(jí)別的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 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();
}
}
}
}
四、數(shù)據(jù)持久化
不要畏懼文件系統(tǒng)!
Kafka大量依賴文件系統(tǒng)去存儲(chǔ)和緩存消息。對(duì)于硬盤有個(gè)傳統(tǒng)的觀念是硬盤總是很慢，這使很多人懷疑基于文件系統(tǒng)的架構(gòu)能否提供優(yōu)異的性能。實(shí)際上硬盤的快慢完全取決于使用它的方式。設(shè)計(jì)良好的硬盤架構(gòu)可以和內(nèi)存一樣快。
在6塊7200轉(zhuǎn)的SATA RAID-5磁盤陣列的線性寫速度差不多是600MB/s，但是隨即寫的速度卻是100k/s，差了差不多6000倍。現(xiàn)代的操作系統(tǒng)都對(duì)次做了大量的優(yōu)化，使用了 read-ahead 和 write-behind的技巧，讀取的時(shí)候成塊的預(yù)讀取數(shù)據(jù)，寫的時(shí)候?qū)⒏鞣N微小瑣碎的邏輯寫入組織合并成一次較大的物理寫入。對(duì)此的深入討論可以查看這里，它們發(fā)現(xiàn)線性的訪問磁盤，很多時(shí)候比隨機(jī)的內(nèi)存訪問快得多。
為了提高性能，現(xiàn)代操作系統(tǒng)往往使用內(nèi)存作為磁盤的緩存，現(xiàn)代操作系統(tǒng)樂于把所有空閑內(nèi)存用作磁盤緩存，雖然這可能在緩存回收和重新分配時(shí)犧牲一些性能。所有的磁盤讀寫操作都會(huì)經(jīng)過(guò)這個(gè)緩存，這不太可能被繞開除非直接使用I/O。所以雖然每個(gè)程序都在自己的線程里只緩存了一份數(shù)據(jù)，但在操作系統(tǒng)的緩存里還有一份，這等于存了兩份數(shù)據(jù)。
另外再來(lái)討論一下JVM,以下兩個(gè)事實(shí)是眾所周知的：
?Java對(duì)象占用空間是非常大的，差不多是要存儲(chǔ)的數(shù)據(jù)的兩倍甚至更高。
?隨著堆中數(shù)據(jù)量的增加，垃圾回收回變的越來(lái)越困難。
基于以上分析，如果把數(shù)據(jù)緩存在內(nèi)存里，因?yàn)樾枰鎯?chǔ)兩份，不得不使用兩倍的內(nèi)存空間，Kafka基于JVM，又不得不將空間再次加倍,再加上要避免GC帶來(lái)的性能影響，在一個(gè)32G內(nèi)存的機(jī)器上，不得不使用到28-30G的內(nèi)存空間。并且當(dāng)系統(tǒng)重啟的時(shí)候，又必須要將數(shù)據(jù)刷到內(nèi)存中（ 10GB 內(nèi)存差不多要用10分鐘），就算使用冷刷新（不是一次性刷進(jìn)內(nèi)存，而是在使用數(shù)據(jù)的時(shí)候沒有就刷到內(nèi)存）也會(huì)導(dǎo)致最初的時(shí)候新能非常慢。但是使用文件系統(tǒng)，即使系統(tǒng)重啟了，也不需要刷新數(shù)據(jù)。使用文件系統(tǒng)也簡(jiǎn)化了維護(hù)數(shù)據(jù)一致性的邏輯。
所以與傳統(tǒng)的將數(shù)據(jù)緩存在內(nèi)存中然后刷到硬盤的設(shè)計(jì)不同，Kafka直接將數(shù)據(jù)寫到了文件系統(tǒng)的日志中。
常量時(shí)間的操作效率
在大多數(shù)的消息系統(tǒng)中，數(shù)據(jù)持久化的機(jī)制往往是為每個(gè)cosumer提供一個(gè)B樹或者其他的隨機(jī)讀寫的數(shù)據(jù)結(jié)構(gòu)。B樹當(dāng)然是很棒的，但是也帶了一些代價(jià)：比如B樹的復(fù)雜度是O(log N)，O(log N)通常被認(rèn)為就是常量復(fù)雜度了，但對(duì)于硬盤操作來(lái)說(shuō)并非如此。磁盤進(jìn)行一次搜索需要10ms，每個(gè)硬盤在同一時(shí)間只能進(jìn)行一次搜索，這樣并發(fā)處理就成了問題。雖然存儲(chǔ)系統(tǒng)使用緩存進(jìn)行了大量?jī)?yōu)化，但是對(duì)于樹結(jié)構(gòu)的性能的觀察結(jié)果卻表明，它的性能往往隨著數(shù)據(jù)的增長(zhǎng)而線性下降，數(shù)據(jù)增長(zhǎng)一倍，速度就會(huì)降低一倍。
直觀的講，對(duì)于主要用于日志處理的消息系統(tǒng)，數(shù)據(jù)的持久化可以簡(jiǎn)單的通過(guò)將數(shù)據(jù)追加到文件中實(shí)現(xiàn)，讀的時(shí)候從文件中讀就好了。這樣做的好處是讀和寫都是 O(1) 的，并且讀操作不會(huì)阻塞寫操作和其他操作。這樣帶來(lái)的性能優(yōu)勢(shì)是很明顯的，因?yàn)樾阅芎蛿?shù)據(jù)的大小沒有關(guān)系了。
既然可以使用幾乎沒有容量限制（相對(duì)于內(nèi)存來(lái)說(shuō)）的硬盤空間建立消息系統(tǒng)，就可以在沒有性能損失的情況下提供一些一般消息系統(tǒng)不具備的特性。比如，一般的消息系統(tǒng)都是在消息被消費(fèi)后立即刪除，Kafka卻可以將消息保存一段時(shí)間（比如一星期），這給consumer提供了很好的機(jī)動(dòng)性和靈活性，這點(diǎn)在今后的文章中會(huì)有詳述。
五、消息傳輸?shù)氖聞?wù)定義
之前討論了consumer和producer是怎么工作的，現(xiàn)在來(lái)討論一下數(shù)據(jù)傳輸方面。數(shù)據(jù)傳輸?shù)氖聞?wù)定義通常有以下三種級(jí)別：
最多一次: 消息不會(huì)被重復(fù)發(fā)送，最多被傳輸一次，但也有可能一次不傳輸。
最少一次: 消息不會(huì)被漏發(fā)送，最少被傳輸一次，但也有可能被重復(fù)傳輸.
精確的一次（Exactly once）: 不會(huì)漏傳輸也不會(huì)重復(fù)傳輸,每個(gè)消息都傳輸被一次而且僅僅被傳輸一次，這是大家所期望的。
大多數(shù)消息系統(tǒng)聲稱可以做到“精確的一次”，但是仔細(xì)閱讀它們的的文檔可以看到里面存在誤導(dǎo)，比如沒有說(shuō)明當(dāng)consumer或producer失敗時(shí)怎么樣，或者當(dāng)有多個(gè)consumer并行時(shí)怎么樣，或?qū)懭胗脖P的數(shù)據(jù)丟失時(shí)又會(huì)怎么樣。kafka的做法要更先進(jìn)一些。當(dāng)發(fā)布消息時(shí)，Kafka有一個(gè)“committed”的概念，一旦消息被提交了，只要消息被寫入的分區(qū)的所在的副本broker是活動(dòng)的，數(shù)據(jù)就不會(huì)丟失。關(guān)于副本的活動(dòng)的概念，下節(jié)文檔會(huì)討論。現(xiàn)在假設(shè)broker是不會(huì)down的。
如果producer發(fā)布消息時(shí)發(fā)生了網(wǎng)絡(luò)錯(cuò)誤，但又不確定實(shí)在提交之前發(fā)生的還是提交之后發(fā)生的，這種情況雖然不常見，但是必須考慮進(jìn)去，現(xiàn)在Kafka版本還沒有解決這個(gè)問題，將來(lái)的版本正在努力嘗試解決。
并不是所有的情況都需要“精確的一次”這樣高的級(jí)別，Kafka允許producer靈活的指定級(jí)別。比如producer可以指定必須等待消息被提交的通知，或者完全的異步發(fā)送消息而不等待任何通知，或者僅僅等待leader聲明它拿到了消息（followers沒有必要）。
現(xiàn)在從consumer的方面考慮這個(gè)問題，所有的副本都有相同的日志文件和相同的offset，consumer維護(hù)自己消費(fèi)的消息的offset，如果consumer不會(huì)崩潰當(dāng)然可以在內(nèi)存中保存這個(gè)值，當(dāng)然誰(shuí)也不能保證這點(diǎn)。如果consumer崩潰了，會(huì)有另外一個(gè)consumer接著消費(fèi)消息，它需要從一個(gè)合適的offset繼續(xù)處理。這種情況下可以有以下選擇：
consumer可以先讀取消息，然后將offset寫入日志文件中，然后再處理消息。這存在一種可能就是在存儲(chǔ)offset后還沒處理消息就crash了，新的consumer繼續(xù)從這個(gè)offset處理，那么就會(huì)有些消息永遠(yuǎn)不會(huì)被處理，這就是上面說(shuō)的“最多一次”。
consumer可以先讀取消息，處理消息，最后記錄offset，當(dāng)然如果在記錄offset之前就crash了，新的consumer會(huì)重復(fù)的消費(fèi)一些消息，這就是上面說(shuō)的“最少一次”。
“精確一次”可以通過(guò)將提交分為兩個(gè)階段來(lái)解決：保存了offset后提交一次，消息處理成功之后再提交一次。但是還有個(gè)更簡(jiǎn)單的做法：將消息的offset和消息被處理后的結(jié)果保存在一起。比如用Hadoop ETL處理消息時(shí)，將處理后的結(jié)果和offset同時(shí)保存在HDFS中，這樣就能保證消息和offser同時(shí)被處理了。
更多詳細(xì)源碼參考來(lái)源：技術(shù)網(wǎng)站請(qǐng)查看這里歡迎大家一起學(xué)習(xí)研究相關(guān)技術(shù)，源碼獲取請(qǐng)加求求（企鵝）: 2042849237
