Kafka入門經(jīng)典教程-Kafka-about云開(kāi)發(fā) http://www.aboutyun.com/thread-12882-1-1.html

1.Kafka獨(dú)特設(shè)計(jì)在什么地方喷兼？
2.Kafka如何搭建及創(chuàng)建topic捅儒、發(fā)送消息、消費(fèi)消息？
3.如何書(shū)寫(xiě)Kafka程序？
4.數(shù)據(jù)傳輸?shù)氖聞?wù)定義有哪三種？
5.Kafka判斷一個(gè)節(jié)點(diǎn)是否活著有哪兩個(gè)條件？
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存儲(chǔ)在硬盤上的消息格式是什么惕味？

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ā)布的消息，不管這些消息有沒(méi)有被消費(fèi)怕轿。比如偷崩，如果消息的保存策略被設(shè)置為2天，那么在一個(gè)消息被發(fā)布的兩天時(shí)間內(nèi)撞羽，它都是可以被消費(fèi)的阐斜。之后它將被丟棄以釋放空間。Kafka的性能是和數(shù)據(jù)量無(wú)關(guān)的常量級(jí)的诀紊，所以保留太多的數(shù)據(jù)并不是問(wèn)題谒出。實(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é)處理消息的讀和寫(xiě)哥捕，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中戈二。更常見(jiàn)的是，每個(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)境搭建

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)后離開(kāi)控制臺(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)consumerKafka 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)編寫(xiě)配置文件：> 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é)處理消息的讀和寫(xiě)誉结，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ù)制代碼
測(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ù)寫(xiě)消息的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開(kāi)發(fā)環(huán)境
我們搭建了kafka的服務(wù)器，并可以使用Kafka的命令行工具創(chuàng)建topic蔓钟，發(fā)送和接收消息永票。下面我們來(lái)搭建kafka的開(kāi)發(fā)環(huán)境。添加依賴搭建開(kāi)發(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中添加以下依賴：<dependency>
<groupId> org.apache.kafka</groupId >
<artifactId> kafka_2.10</artifactId >
<version> 0.8.0</ version>
</dependency>

復(fù)制代碼
添加依賴后你會(huì)發(fā)現(xiàn)有兩個(gè)jar包的依賴找不到。沒(méi)關(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)是這樣的：

復(fù)制代碼
producerpackage 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ù)制代碼
consumerpackage 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ù)制代碼
簡(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<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)去存儲(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磁盤陣列的線性寫(xiě)速度差不多是600MB/s，但是隨即寫(xiě)的速度卻是100k/s痹束，差了差不多6000倍〖煲撸現(xiàn)代的操作系統(tǒng)都對(duì)次做了大量的優(yōu)化，使用了 read-ahead 和 write-behind的技巧祷嘶，讀取的時(shí)候成塊的預(yù)讀取數(shù)據(jù)屎媳，寫(xiě)的時(shí)候?qū)⒏鞣N微小瑣碎的邏輯寫(xiě)入組織合并成一次較大的物理寫(xiě)入。對(duì)此的深入討論可以查看這里论巍，它們發(fā)現(xiàn)線性的訪問(wèn)磁盤烛谊，很多時(shí)候比隨機(jī)的內(nèi)存訪問(wèn)快得多。為了提高性能环壤，現(xiàn)代操作系統(tǒng)往往使用內(nèi)存作為磁盤的緩存晒来，現(xiàn)代操作系統(tǒng)樂(lè)于把所有空閑內(nèi)存用作磁盤緩存，雖然這可能在緩存回收和重新分配時(shí)犧牲一些性能郑现。所有的磁盤讀寫(xiě)操作都會(huì)經(jīng)過(guò)這個(gè)緩存，這不太可能被繞開(kāi)除非直接使用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í)候沒(méi)有就刷到內(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ù)寫(xiě)到了文件系統(tǒng)的日志中级乐。常量時(shí)間的操作效率在大多數(shù)的消息系統(tǒng)中，數(shù)據(jù)持久化的機(jī)制往往是為每個(gè)cosumer提供一個(gè)B樹(shù)或者其他的隨機(jī)讀寫(xiě)的數(shù)據(jù)結(jié)構(gòu)县匠。B樹(shù)當(dāng)然是很棒的风科，但是也帶了一些代價(jià)：比如B樹(shù)的復(fù)雜度是O(log N)，O(log N)通常被認(rèn)為就是常量復(fù)雜度了乞旦，但對(duì)于硬盤操作來(lái)說(shuō)并非如此贼穆。磁盤進(jìn)行一次搜索需要10ms，每個(gè)硬盤在同一時(shí)間只能進(jìn)行一次搜索兰粉，這樣并發(fā)處理就成了問(wèn)題故痊。雖然存儲(chǔ)系統(tǒng)使用緩存進(jìn)行了大量?jī)?yōu)化，但是對(duì)于樹(shù)結(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í)候從文件中讀就好了甜孤。這樣做的好處是讀和寫(xiě)都是 O(1) 的，并且讀操作不會(huì)阻塞寫(xiě)操作和其他操作畏腕。這樣帶來(lái)的性能優(yōu)勢(shì)是很明顯的缴川，因?yàn)樾阅芎蛿?shù)據(jù)的大小沒(méi)有關(guān)系了。既然可以使用幾乎沒(méi)有容量限制（相對(duì)于內(nèi)存來(lái)說(shuō)）的硬盤空間建立消息系統(tǒng)描馅，就可以在沒(méi)有性能損失的情況下提供一些一般消息系統(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)规哲，比如沒(méi)有說(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”的概念袄简，一旦消息被提交了，只要消息被寫(xiě)入的分區(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ā)生的宗雇，這種情況雖然不常見(jiàn)昂芜，但是必須考慮進(jìn)去，現(xiàn)在Kafka版本還沒(méi)有解決這個(gè)問(wèn)題赔蒲，將來(lái)的版本正在努力嘗試解決。并不是所有的情況都需要“精確的一次”這樣高的級(jí)別良漱，Kafka允許producer靈活的指定級(jí)別舞虱。比如producer可以指定必須等待消息被提交的通知，或者完全的異步發(fā)送消息而不等待任何通知母市，或者僅僅等待leader聲明它拿到了消息（followers沒(méi)有必要）》担現(xiàn)在從consumer的方面考慮這個(gè)問(wèn)題，所有的副本都有相同的日志文件和相同的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寫(xiě)入日志文件中镊靴，然后再處理消息。這存在一種可能就是在存儲(chǔ)offset后還沒(méi)處理消息就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í)被處理了缨伊。

############################################################六、性能優(yōu)化
Kafka在提高效率方面做了很大努力进宝。Kafka的一個(gè)主要使用場(chǎng)景是處理網(wǎng)站活動(dòng)日志刻坊，吞吐量是非常大的，每個(gè)頁(yè)面都會(huì)產(chǎn)生好多次寫(xiě)操作党晋。讀方面谭胚，假設(shè)每個(gè)消息只被消費(fèi)一次，讀的量的也是很大的未玻，Kafka也盡量使讀的操作更輕量化灾而。我們之前討論了磁盤的性能問(wèn)題，線性讀寫(xiě)的情況下影響磁盤性能問(wèn)題大約有兩個(gè)方面：太多的瑣碎的I/O操作和太多的字節(jié)拷貝扳剿。I/O問(wèn)題發(fā)生在客戶端和服務(wù)端之間旁趟，也發(fā)生在服務(wù)端內(nèi)部的持久化的操作中。消息集（message set）為了避免這些問(wèn)題庇绽，Kafka建立了“消息集（message set）”的概念锡搜，將消息組織到一起橙困，作為處理的單位。以消息集為單位處理消息耕餐，比以單個(gè)的消息為單位處理凡傅，會(huì)提升不少性能。Producer把消息集一塊發(fā)送給服務(wù)端蛾方，而不是一條條的發(fā)送像捶；服務(wù)端把消息集一次性的追加到日志文件中，這樣減少了瑣碎的I/O操作桩砰。consumer也可以一次性的請(qǐng)求一個(gè)消息集拓春。另外一個(gè)性能優(yōu)化是在字節(jié)拷貝方面。在低負(fù)載的情況下這不是問(wèn)題亚隅，但是在高負(fù)載的情況下它的影響還是很大的硼莽。為了避免這個(gè)問(wèn)題，Kafka使用了標(biāo)準(zhǔn)的二進(jìn)制消息格式煮纵，這個(gè)格式可以在producer,broker和producer之間共享而無(wú)需做任何改動(dòng)懂鸵。zero copyBroker維護(hù)的消息日志僅僅是一些目錄文件，消息集以固定隊(duì)的格式寫(xiě)入到日志文件中行疏，這個(gè)格式producer和consumer是共享的匆光，這使得Kafka可以一個(gè)很重要的點(diǎn)進(jìn)行優(yōu)化：消息在網(wǎng)絡(luò)上的傳遞。現(xiàn)代的unix操作系統(tǒng)提供了高性能的將數(shù)據(jù)從頁(yè)面緩存發(fā)送到socket的系統(tǒng)函數(shù)酿联，在linux中终息，這個(gè)函數(shù)是sendfile.為了更好的理解sendfile的好處，我們先來(lái)看下一般將數(shù)據(jù)從文件發(fā)送到socket的數(shù)據(jù)流向：操作系統(tǒng)把數(shù)據(jù)從文件拷貝內(nèi)核中的頁(yè)緩存中
應(yīng)用程序從頁(yè)緩存從把數(shù)據(jù)拷貝自己的內(nèi)存緩存中
應(yīng)用程序?qū)?shù)據(jù)寫(xiě)入到內(nèi)核中socket緩存中
操作系統(tǒng)把數(shù)據(jù)從socket緩存中拷貝到網(wǎng)卡接口緩存贞让，從這里發(fā)送到網(wǎng)絡(luò)上周崭。

這顯然是低效率的，有4次拷貝和2次系統(tǒng)調(diào)用喳张。Sendfile通過(guò)直接將數(shù)據(jù)從頁(yè)面緩存發(fā)送網(wǎng)卡接口緩存续镇，避免了重復(fù)拷貝，大大的優(yōu)化了性能销部。在一個(gè)多consumers的場(chǎng)景里摸航，數(shù)據(jù)僅僅被拷貝到頁(yè)面緩存一次而不是每次消費(fèi)消息的時(shí)候都重復(fù)的進(jìn)行拷貝。這使得消息以近乎網(wǎng)絡(luò)帶寬的速率發(fā)送出去舅桩。這樣在磁盤層面你幾乎看不到任何的讀操作忙厌，因?yàn)閿?shù)據(jù)都是從頁(yè)面緩存中直接發(fā)送到網(wǎng)絡(luò)上去了。這篇文章詳細(xì)介紹了sendfile和zero-copy技術(shù)在Java方面的應(yīng)用江咳。數(shù)據(jù)壓縮很多時(shí)候，性能的瓶頸并非CPU或者硬盤而是網(wǎng)絡(luò)帶寬哥放，對(duì)于需要在數(shù)據(jù)中心之間傳送大量數(shù)據(jù)的應(yīng)用更是如此歼指。當(dāng)然用戶可以在沒(méi)有Kafka支持的情況下各自壓縮自己的消息爹土，但是這將導(dǎo)致較低的壓縮率，因?yàn)橄啾扔趯⑾为?dú)壓縮踩身，將大量文件壓縮在一起才能起到最好的壓縮效果胀茵。Kafka采用了端到端的壓縮：因?yàn)橛小跋⒓钡母拍睿蛻舳说南⒖梢砸黄鸨粔嚎s后送到服務(wù)端挟阻，并以壓縮后的格式寫(xiě)入日志文件琼娘，以壓縮的格式發(fā)送到consumer，消息從producer發(fā)出到consumer拿到都被是壓縮的附鸽，只有在consumer使用的時(shí)候才被解壓縮脱拼，所以叫做“端到端的壓縮”。Kafka支持GZIP和Snappy壓縮協(xié)議坷备。更詳細(xì)的內(nèi)容可以查看這里熄浓。##########################################################七、Producer和Consumer
Kafka Producer
****消息發(fā)送
producer直接將數(shù)據(jù)發(fā)送到broker的leader(主節(jié)點(diǎn))省撑，不需要在多個(gè)節(jié)點(diǎn)進(jìn)行分發(fā)赌蔑。為了幫助producer做到這點(diǎn)，所有的Kafka節(jié)點(diǎn)都可以及時(shí)的告知:哪些節(jié)點(diǎn)是活動(dòng)的竟秫，目標(biāo)topic目標(biāo)分區(qū)的leader在哪娃惯。這樣producer就可以直接將消息發(fā)送到目的地了》拾埽客戶端控制消息將被分發(fā)到哪個(gè)分區(qū)趾浅。可以通過(guò)負(fù)載均衡隨機(jī)的選擇拙吉，或者使用分區(qū)函數(shù)潮孽。Kafka允許用戶實(shí)現(xiàn)分區(qū)函數(shù)，指定分區(qū)的key筷黔，將消息hash到不同的分區(qū)上(當(dāng)然有需要的話往史，也可以覆蓋這個(gè)分區(qū)函數(shù)自己實(shí)現(xiàn)邏輯).比如如果你指定的key是user id，那么同一個(gè)用戶發(fā)送的消息都被發(fā)送到同一個(gè)分區(qū)上佛舱。經(jīng)過(guò)分區(qū)之后椎例，consumer就可以有目的的消費(fèi)某個(gè)分區(qū)的消息。異步發(fā)送批量發(fā)送可以很有效的提高發(fā)送效率请祖。Kafka producer的異步發(fā)送模式允許進(jìn)行批量發(fā)送订歪，先將消息緩存在內(nèi)存中，然后一次請(qǐng)求批量發(fā)送出去肆捕。這個(gè)策略可以配置的刷晋，比如可以指定緩存的消息達(dá)到某個(gè)量的時(shí)候就發(fā)出去，或者緩存了固定的時(shí)間后就發(fā)送出去（比如100條消息就發(fā)送，或者每5秒發(fā)送一次）眼虱。這種策略將大大減少服務(wù)端的I/O次數(shù)喻奥。既然緩存是在producer端進(jìn)行的，那么當(dāng)producer崩潰時(shí)捏悬，這些消息就會(huì)丟失撞蚕。Kafka0.8.1的異步發(fā)送模式還不支持回調(diào)，就不能在發(fā)送出錯(cuò)時(shí)進(jìn)行處理过牙。Kafka 0.9可能會(huì)增加這樣的回調(diào)函數(shù)甥厦。見(jiàn)Proposed Producer API.Kafka Consumer
Kafa consumer消費(fèi)消息時(shí)，向broker發(fā)出"fetch"請(qǐng)求去消費(fèi)特定分區(qū)的消息寇钉。consumer指定消息在日志中的偏移量（offset）刀疙，就可以消費(fèi)從這個(gè)位置開(kāi)始的消息。customer擁有了offset的控制權(quán)摧莽，可以向后回滾去重新消費(fèi)之前的消息庙洼，這是很有意義的。推還是拉镊辕？Kafka最初考慮的問(wèn)題是油够，customer應(yīng)該從brokes拉取消息還是brokers將消息推送到consumer，也就是pull還push征懈。在這方面石咬，Kafka遵循了一種大部分消息系統(tǒng)共同的傳統(tǒng)的設(shè)計(jì)：producer將消息推送到broker，consumer從broker拉取消息卖哎。一些消息系統(tǒng)比如Scribe和Apache Flume采用了push模式鬼悠，將消息推送到下游的consumer。這樣做有好處也有壞處：由broker決定消息推送的速率亏娜，對(duì)于不同消費(fèi)速率的consumer就不太好處理了焕窝。消息系統(tǒng)都致力于讓consumer以最大的速率最快速的消費(fèi)消息，但不幸的是维贺，push模式下它掂，當(dāng)broker推送的速率遠(yuǎn)大于consumer消費(fèi)的速率時(shí)，consumer恐怕就要崩潰了溯泣。最終Kafka還是選取了傳統(tǒng)的pull模式虐秋。Pull模式的另外一個(gè)好處是consumer可以自主決定是否批量的從broker拉取數(shù)據(jù)。Push模式必須在不知道下游consumer消費(fèi)能力和消費(fèi)策略的情況下決定是立即推送每條消息還是緩存之后批量推送垃沦。如果為了避免consumer崩潰而采用較低的推送速率客给，將可能導(dǎo)致一次只推送較少的消息而造成浪費(fèi)。Pull模式下肢簿，consumer就可以根據(jù)自己的消費(fèi)能力去決定這些策略靶剑。Pull有個(gè)缺點(diǎn)是蜻拨，如果broker沒(méi)有可供消費(fèi)的消息，將導(dǎo)致consumer不斷在循環(huán)中輪詢抬虽，直到新消息到t達(dá)官觅。為了避免這點(diǎn)，Kafka有個(gè)參數(shù)可以讓consumer阻塞知道新消息到達(dá)(當(dāng)然也可以阻塞知道消息的數(shù)量達(dá)到某個(gè)特定的量這樣就可以批量發(fā)送)阐污。消費(fèi)狀態(tài)跟蹤對(duì)消費(fèi)消息狀態(tài)的記錄也是很重要的。大部分消息系統(tǒng)在broker端的維護(hù)消息被消費(fèi)的記錄：一個(gè)消息被分發(fā)到consumer后broker就馬上進(jìn)行標(biāo)記或者等待customer的通知后進(jìn)行標(biāo)記咱圆。這樣也可以在消息在消費(fèi)后立馬就刪除以減少空間占用笛辟。但是這樣會(huì)不會(huì)有什么問(wèn)題呢？
如果一條消息發(fā)送出去之后就立即被標(biāo)記為消費(fèi)過(guò)的序苏，一旦consumer處理消息時(shí)失敗了（比如程序崩潰）消息就丟失了手幢。為了解決這個(gè)問(wèn)題，很多消息系統(tǒng)提供了另外一個(gè)個(gè)功能：當(dāng)消息被發(fā)送出去之后僅僅被標(biāo)記為已發(fā)送狀態(tài)忱详，當(dāng)接到consumer已經(jīng)消費(fèi)成功的通知后才標(biāo)記為已被消費(fèi)的狀態(tài)围来。這雖然解決了消息丟失的問(wèn)題，但產(chǎn)生了新問(wèn)題匈睁，首先如果consumer處理消息成功了但是向broker發(fā)送響應(yīng)時(shí)失敗了监透，這條消息將被消費(fèi)兩次。第二個(gè)問(wèn)題時(shí)航唆，broker必須維護(hù)每條消息的狀態(tài)胀蛮，并且每次都要先鎖住消息然后更改狀態(tài)然后釋放鎖。這樣麻煩又來(lái)了糯钙，且不說(shuō)要維護(hù)大量的狀態(tài)數(shù)據(jù)粪狼，比如如果消息發(fā)送出去但沒(méi)有收到消費(fèi)成功的通知，這條消息將一直處于被鎖定的狀態(tài)任岸，Kafka采用了不同的策略再榄。Topic被分成了若干分區(qū)，每個(gè)分區(qū)在同一時(shí)間只被一個(gè)consumer消費(fèi)享潜。這意味著每個(gè)分區(qū)被消費(fèi)的消息在日志中的位置僅僅是一個(gè)簡(jiǎn)單的整數(shù)：offset困鸥。這樣就很容易標(biāo)記每個(gè)分區(qū)消費(fèi)狀態(tài)就很容易了，僅僅需要一個(gè)整數(shù)而已米碰。這樣消費(fèi)狀態(tài)的跟蹤就很簡(jiǎn)單了窝革。這帶來(lái)了另外一個(gè)好處：consumer可以把offset調(diào)成一個(gè)較老的值，去重新消費(fèi)老的消息吕座。這對(duì)傳統(tǒng)的消息系統(tǒng)來(lái)說(shuō)看起來(lái)有些不可思議虐译，但確實(shí)是非常有用的，誰(shuí)規(guī)定了一條消息只能被消費(fèi)一次呢吴趴？consumer發(fā)現(xiàn)解析數(shù)據(jù)的程序有bug漆诽，在修改bug后再來(lái)解析一次消息，看起來(lái)是很合理的額呀！離線處理消息高級(jí)的數(shù)據(jù)持久化允許consumer每個(gè)隔一段時(shí)間批量的將數(shù)據(jù)加載到線下系統(tǒng)中比如Hadoop或者數(shù)據(jù)倉(cāng)庫(kù)厢拭。這種情況下兰英，Hadoop可以將加載任務(wù)分拆，拆成每個(gè)broker或每個(gè)topic或每個(gè)分區(qū)一個(gè)加載任務(wù)供鸠。Hadoop具有任務(wù)管理功能畦贸，當(dāng)一個(gè)任務(wù)失敗了就可以重啟而不用擔(dān)心數(shù)據(jù)被重新加載，只要從上次加載的位置繼續(xù)加載消息就可以了楞捂。#########################################################八薄坏、主從同步
Kafka允許topic的分區(qū)擁有若干副本，這個(gè)數(shù)量是可以配置的寨闹，你可以為每個(gè)topci配置副本的數(shù)量胶坠。Kafka會(huì)自動(dòng)在每個(gè)個(gè)副本上備份數(shù)據(jù)，所以當(dāng)一個(gè)節(jié)點(diǎn)down掉時(shí)數(shù)據(jù)依然是可用的繁堡。Kafka的副本功能不是必須的沈善，你可以配置只有一個(gè)副本，這樣其實(shí)就相當(dāng)于只有一份數(shù)據(jù)椭蹄。創(chuàng)建副本的單位是topic的分區(qū)闻牡，每個(gè)分區(qū)都有一個(gè)leader和零或多個(gè)followers.所有的讀寫(xiě)操作都由leader處理，一般分區(qū)的數(shù)量都比broker的數(shù)量多的多塑娇，各分區(qū)的leader均勻的分布在brokers中澈侠。所有的followers都復(fù)制leader的日志，日志中的消息和順序都和leader中的一致埋酬。flowers向普通的consumer那樣從leader那里拉取消息并保存在自己的日志文件中哨啃。許多分布式的消息系統(tǒng)自動(dòng)的處理失敗的請(qǐng)求，它們對(duì)一個(gè)節(jié)點(diǎn)是否著（alive）”有著清晰的定義写妥。Kafka判斷一個(gè)節(jié)點(diǎn)是否活著有兩個(gè)條件：
節(jié)點(diǎn)必須可以維護(hù)和ZooKeeper的連接拳球，Zookeeper通過(guò)心跳機(jī)制檢查每個(gè)節(jié)點(diǎn)的連接。
如果節(jié)點(diǎn)是個(gè)follower,他必須能及時(shí)的同步leader的寫(xiě)操作珍特，延時(shí)不能太久祝峻。

符合以上條件的節(jié)點(diǎn)準(zhǔn)確的說(shuō)應(yīng)該是“同步中的（in sync）”，而不是模糊的說(shuō)是“活著的”或是“失敗的”扎筒。Leader會(huì)追蹤所有“同步中”的節(jié)點(diǎn)莱找，一旦一個(gè)down掉了，或是卡住了嗜桌，或是延時(shí)太久奥溺，leader就會(huì)把它移除。至于延時(shí)多久算是“太久”骨宠，是由參數(shù)replica.lag.max.messages決定的浮定，怎樣算是卡住了相满，怎是由參數(shù)replica.lag.time.max.ms決定的。 只有當(dāng)消息被所有的副本加入到日志中時(shí)桦卒，才算是“committed”立美，只有committed的消息才會(huì)發(fā)送給consumer，這樣就不用擔(dān)心一旦leader down掉了消息會(huì)丟失方灾。Producer也可以選擇是否等待消息被提交的通知建蹄，這個(gè)是由參數(shù)request.required.acks決定的。Kafka保證只要有一個(gè)“同步中”的節(jié)點(diǎn)迎吵，“committed”的消息就不會(huì)丟失躲撰。Leader的選擇Kafka的核心是日志文件，日志文件在集群中的同步是分布式數(shù)據(jù)系統(tǒng)最基礎(chǔ)的要素击费。如果leaders永遠(yuǎn)不會(huì)down的話我們就不需要followers了！一旦leader down掉了桦他，需要在followers中選擇一個(gè)新的leader.但是followers本身有可能延時(shí)太久或者crash蔫巩，所以必須選擇高質(zhì)量的follower作為leader.必須保證，一旦一個(gè)消息被提交了快压，但是leader down掉了圆仔，新選出的leader必須可以提供這條消息。大部分的分布式系統(tǒng)采用了多數(shù)投票法則選擇新的leader,對(duì)于多數(shù)投票法則蔫劣，就是根據(jù)所有副本節(jié)點(diǎn)的狀況動(dòng)態(tài)的選擇最適合的作為leader.Kafka并不是使用這種方法坪郭。Kafaka動(dòng)態(tài)維護(hù)了一個(gè)同步狀態(tài)的副本的集合（a set of in-sync replicas），簡(jiǎn)稱ISR脉幢，在這個(gè)集合中的節(jié)點(diǎn)都是和leader保持高度一致的歪沃，任何一條消息必須被這個(gè)集合中的每個(gè)節(jié)點(diǎn)讀取并追加到日志中了，才回通知外部這個(gè)消息已經(jīng)被提交了嫌松。因此這個(gè)集合中的任何一個(gè)節(jié)點(diǎn)隨時(shí)都可以被選為leader.ISR在ZooKeeper中維護(hù)沪曙。ISR中有f+1個(gè)節(jié)點(diǎn)，就可以允許在f個(gè)節(jié)點(diǎn)down掉的情況下不會(huì)丟失消息并正常提供服萎羔。ISR的成員是動(dòng)態(tài)的液走，如果一個(gè)節(jié)點(diǎn)被淘汰了过咬，當(dāng)它重新達(dá)到“同步中”的狀態(tài)時(shí)茄菊，他可以重新加入ISR.這種leader的選擇方式是非常快速的束莫，適合kafka的應(yīng)用場(chǎng)景髓废。一個(gè)邪惡的想法：如果所有節(jié)點(diǎn)都down掉了怎么辦巷懈？Kafka對(duì)于數(shù)據(jù)不會(huì)丟失的保證，是基于至少一個(gè)節(jié)點(diǎn)是存活的瓦哎，一旦所有節(jié)點(diǎn)都down了砸喻，這個(gè)就不能保證了柔逼。實(shí)際應(yīng)用中，當(dāng)所有的副本都down掉時(shí)割岛，必須及時(shí)作出反應(yīng)愉适。可以有以下兩種選擇:等待ISR中的任何一個(gè)節(jié)點(diǎn)恢復(fù)并擔(dān)任leader癣漆。
選擇所有節(jié)點(diǎn)中（不只是ISR）第一個(gè)恢復(fù)的節(jié)點(diǎn)作為leader.

這是一個(gè)在可用性和連續(xù)性之間的權(quán)衡维咸。如果等待ISR中的節(jié)點(diǎn)恢復(fù)，一旦ISR中的節(jié)點(diǎn)起不起來(lái)或者數(shù)據(jù)都是了惠爽，那集群就永遠(yuǎn)恢復(fù)不了了癌蓖。如果等待ISR意外的節(jié)點(diǎn)恢復(fù)，這個(gè)節(jié)點(diǎn)的數(shù)據(jù)就會(huì)被作為線上數(shù)據(jù)婚肆，有可能和真實(shí)的數(shù)據(jù)有所出入租副，因?yàn)橛行?shù)據(jù)它可能還沒(méi)同步到。Kafka目前選擇了第二種策略较性，在未來(lái)的版本中將使這個(gè)策略的選擇可配置用僧，可以根據(jù)場(chǎng)景靈活的選擇。這種窘境不只Kafka會(huì)遇到赞咙，幾乎所有的分布式數(shù)據(jù)系統(tǒng)都會(huì)遇到责循。副本管理以上僅僅以一個(gè)topic一個(gè)分區(qū)為例子進(jìn)行了討論，但實(shí)際上一個(gè)Kafka將會(huì)管理成千上萬(wàn)的topic分區(qū).Kafka盡量的使所有分區(qū)均勻的分布到集群所有的節(jié)點(diǎn)上而不是集中在某些節(jié)點(diǎn)上攀操，另外主從關(guān)系也盡量均衡這樣每個(gè)幾點(diǎn)都會(huì)擔(dān)任一定比例的分區(qū)的leader.優(yōu)化leader的選擇過(guò)程也是很重要的院仿，它決定了系統(tǒng)發(fā)生故障時(shí)的空窗期有多久。Kafka選擇一個(gè)節(jié)點(diǎn)作為“controller”,當(dāng)發(fā)現(xiàn)有節(jié)點(diǎn)down掉的時(shí)候它負(fù)責(zé)在游泳分區(qū)的所有節(jié)點(diǎn)中選擇新的leader,這使得Kafka可以批量的高效的管理所有分區(qū)節(jié)點(diǎn)的主從關(guān)系速和。如果controller down掉了歹垫，活著的節(jié)點(diǎn)中的一個(gè)會(huì)備切換為新的controller.###################################################九、客戶端API
Kafka Producer APIsProcuder API有兩種：kafka.producer.SyncProducer和kafka.producer.async.AsyncProducer.它們都實(shí)現(xiàn)了同一個(gè)接口：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提供了以下功能：
可以將多個(gè)消息緩存到本地隊(duì)列里健芭，然后異步的批量發(fā)送到broker县钥，可以通過(guò)參數(shù)producer.type=async做到。緩存的大小可以通過(guò)一些參數(shù)指定：queue.time和batch.size慈迈。一個(gè)后臺(tái)線程（(kafka.producer.async.ProducerSendThread）從隊(duì)列中取出數(shù)據(jù)并讓kafka.producer.EventHandler將消息發(fā)送到broker若贮，也可以通過(guò)參數(shù)event.handler定制handler，在producer端處理數(shù)據(jù)的不同的階段注冊(cè)處理器痒留，比如可以對(duì)這一過(guò)程進(jìn)行日志追蹤谴麦，或進(jìn)行一些監(jiān)控。只需實(shí)現(xiàn)kafka.producer.async.CallbackHandler接口伸头，并在callback.handler中配置匾效。
自己編寫(xiě)Encoder來(lái)序列化消息，只需實(shí)現(xiàn)下面這個(gè)接口恤磷。默認(rèn)的Encoder是kafka.serializer.DefaultEncoder面哼。interface Encoder<T> {
public Message toMessage(T data);
}

提供了基于Zookeeper的broker自動(dòng)感知能力野宜，可以通過(guò)參數(shù)zk.connect實(shí)現(xiàn)。如果不使用Zookeeper魔策，也可以使用broker.list參數(shù)指定一個(gè)靜態(tài)的brokers列表匈子，這樣消息將被隨機(jī)的發(fā)送到一個(gè)broker上，一旦選中的broker失敗了闯袒，消息發(fā)送也就失敗了虎敦。
通過(guò)分區(qū)函數(shù)kafka.producer.Partitioner類對(duì)消息分區(qū)。interface Partitioner<T> {
int partition(T key, int numPartitions);
}

分區(qū)函數(shù)有兩個(gè)參數(shù)：key和可用的分區(qū)數(shù)量政敢，從分區(qū)列表中選擇一個(gè)分區(qū)并返回id其徙。默認(rèn)的分區(qū)策略是hash(key)%numPartitions.如果key是null,就隨機(jī)的選擇一個(gè)∨缁В可以通過(guò)參數(shù)partitioner.class定制分區(qū)函數(shù)唾那。

KafKa Consumer APIsConsumer API有兩個(gè)級(jí)別。低級(jí)別的和一個(gè)指定的broker保持連接褪尝，并在接收完消息后關(guān)閉連接通贞，這個(gè)級(jí)別是無(wú)狀態(tài)的，每次讀取消息都帶著offset恼五。高級(jí)別的API隱藏了和brokers連接的細(xì)節(jié)，在不必關(guān)心服務(wù)端架構(gòu)的情況下和服務(wù)端通信哭懈。還可以自己維護(hù)消費(fèi)狀態(tài)灾馒，并可以通過(guò)一些條件指定訂閱特定的topic,比如白名單黑名單或者正則表達(dá)式。低級(jí)別的APIclass SimpleConsumer {
/向一個(gè)broker發(fā)送讀取請(qǐng)求并得到消息集 /
public ByteBufferMessageSet fetch(FetchRequest request);
/向一個(gè)broker發(fā)送讀取請(qǐng)求并得到一個(gè)相應(yīng)集 /
public MultiFetchResponse multifetch(List<FetchRequest> fetches);
/

• 得到指定時(shí)間之前的offsets
• 返回值是offsets列表遣总，以倒序排序
• @param time: 時(shí)間睬罗，毫秒,
• 如果指定為OffsetRequest$.MODULE$.LATIEST_TIME(), 得到最新的offset.
• 如果指定為OffsetRequest$.MODULE$.EARLIEST_TIME(),得到最老的offset.
  */
  publiclong[] getOffsetsBefore(String topic, int partition, long time, int maxNumOffsets);
  }

復(fù)制代碼
低級(jí)別的API是高級(jí)別API實(shí)現(xiàn)的基礎(chǔ)，也是為了一些對(duì)維持消費(fèi)狀態(tài)有特殊需求的場(chǎng)景旭斥，比如Hadoop consumer這樣的離線consumer容达。高級(jí)別的API/* 創(chuàng)建連接 /
ConsumerConnector connector = Consumer.create(consumerConfig);
interface ConsumerConnector {
/*

• 這個(gè)方法可以得到一個(gè)流的列表，每個(gè)流都是MessageAndMetadata的迭代垂券，通過(guò)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);
  /*
• 你也可以得到一個(gè)流的列表花盐，它包含了符合TopicFiler的消息的迭代，
• 一個(gè)TopicFilter是一個(gè)封裝了白名單或黑名單的正則表達(dá)式菇爪。
  /
  public List<KafkaStream> createMessageStreamsByFilter(
  TopicFilter topicFilter, int numStreams);
  / 提交目前消費(fèi)到的offset /
  public commitOffsets()
  / 關(guān)閉連接 */
  public shutdown()
  }

復(fù)制代碼
這個(gè)API圍繞著由KafkaStream實(shí)現(xiàn)的迭代器展開(kāi)算芯，每個(gè)流代表一系列從一個(gè)或多個(gè)分區(qū)多和broker上匯聚來(lái)的消息，每個(gè)流由一個(gè)線程處理凳宙，所以客戶端可以在創(chuàng)建的時(shí)候通過(guò)參數(shù)指定想要幾個(gè)流熙揍。一個(gè)流是多個(gè)分區(qū)多個(gè)broker的合并，但是每個(gè)分區(qū)的消息只會(huì)流向一個(gè)流氏涩。每調(diào)用一次createMessageStreams都會(huì)將consumer注冊(cè)到topic上届囚，這樣consumer和brokers之間的負(fù)載均衡就會(huì)進(jìn)行調(diào)整有梆。API鼓勵(lì)每次調(diào)用創(chuàng)建更多的topic流以減少這種調(diào)整。createMessageStreamsByFilter方法注冊(cè)監(jiān)聽(tīng)可以感知新的符合filter的tipic意系。#######################################################十泥耀、消息和日志
消息由一個(gè)固定長(zhǎng)度的頭部和可變長(zhǎng)度的字節(jié)數(shù)組組成。頭部包含了一個(gè)版本號(hào)和CRC32校驗(yàn)碼昔字。/**

• 具有N個(gè)字節(jié)的消息的格式如下
• 如果版本號(hào)是0
• 1. 1個(gè)字節(jié)的 "magic" 標(biāo)記
• 2. 4個(gè)字節(jié)的CRC32校驗(yàn)碼
• 3. N - 5個(gè)字節(jié)的具體信息
• 如果版本號(hào)是1
• 1. 1個(gè)字節(jié)的 "magic" 標(biāo)記
• 2.1個(gè)字節(jié)的參數(shù)允許標(biāo)注一些附加的信息比如是否壓縮了爆袍，解碼類型等
• 3.4個(gè)字節(jié)的CRC32校驗(yàn)碼
• 4. N - 6 個(gè)字節(jié)的具體信息

*/

復(fù)制代碼
日志一個(gè)叫做“my_topic”且有兩個(gè)分區(qū)的的topic,它的日志有兩個(gè)文件夾組成，my_topic_0和my_topic_1,每個(gè)文件夾里放著具體的數(shù)據(jù)文件作郭，每個(gè)數(shù)據(jù)文件都是一系列的日志實(shí)體陨囊，每個(gè)日志實(shí)體有一個(gè)4個(gè)字節(jié)的整數(shù)N標(biāo)注消息的長(zhǎng)度，后邊跟著N個(gè)字節(jié)的消息夹攒。每個(gè)消息都可以由一個(gè)64位的整數(shù)offset標(biāo)注蜘醋，offset標(biāo)注了這條消息在發(fā)送到這個(gè)分區(qū)的消息流中的起始位置。每個(gè)日志文件的名稱都是這個(gè)文件第一條日志的offset.所以第一個(gè)日志文件的名字就是00000000000.kafka.所以每相鄰的兩個(gè)文件名字的差就是一個(gè)數(shù)字S,S差不多就是配置文件中指定的日志文件的最大容量咏尝。消息的格式都由一個(gè)統(tǒng)一的接口維護(hù)压语，所以消息可以在producer,broker和consumer之間無(wú)縫的傳遞。存儲(chǔ)在硬盤上的消息格式如下所示：消息長(zhǎng)度: 4 bytes (value: 1+4+n)
版本號(hào): 1 byte
CRC校驗(yàn)碼: 4 bytes
具體的消息: n bytes

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ù)制代碼
刪除日志管理器允許定制刪除策略。目前的策略是刪除修改時(shí)間在N天之前的日志（按時(shí)間刪除）曼追，也可以使用另外一個(gè)策略：保留最后的N GB數(shù)據(jù)的策略(按大小刪除)窍仰。為了避免在刪除時(shí)阻塞讀操作，采用了copy-on-write形式的實(shí)現(xiàn)礼殊，刪除操作進(jìn)行時(shí)驹吮，讀取操作的二分查找功能實(shí)際是在一個(gè)靜態(tài)的快照副本上進(jìn)行的，這類似于Java的CopyOnWriteArrayList晶伦。可靠性保證日志文件有一個(gè)可配置的參數(shù)M碟狞，緩存超過(guò)這個(gè)數(shù)量的消息將被強(qiáng)行刷新到硬盤。一個(gè)日志矯正線程將循環(huán)檢查最新的日志文件中的消息確認(rèn)每個(gè)消息都是合法的婚陪。合法的標(biāo)準(zhǔn)為：所有文件的大小的和最大的offset小于日志文件的大小族沃，并且消息的CRC32校驗(yàn)碼與存儲(chǔ)在消息實(shí)體中的校驗(yàn)碼一致。如果在某個(gè)offset發(fā)現(xiàn)不合法的消息泌参，從這個(gè)offset到下一個(gè)合法的offset之間的內(nèi)容將被移除脆淹。有兩種情況必須考慮：1，當(dāng)發(fā)生崩潰時(shí)有些數(shù)據(jù)塊未能寫(xiě)入沽一。2盖溺，寫(xiě)入了一些空白數(shù)據(jù)塊。第二種情況的原因是铣缠，對(duì)于每個(gè)文件咐柜，操作系統(tǒng)都有一個(gè)inode（inode是指在許多“類Unix文件系統(tǒng)”中的一種數(shù)據(jù)結(jié)構(gòu)。每個(gè)inode保存了文件系統(tǒng)中的一個(gè)文件系統(tǒng)對(duì)象,包括文件攘残、目錄、大小为狸、設(shè)備文件歼郭、socket、管道, 等等）辐棒，但無(wú)法保證更新inode和寫(xiě)入數(shù)據(jù)的順序病曾，當(dāng)inode保存的大小信息被更新了，但寫(xiě)入數(shù)據(jù)時(shí)發(fā)生了崩潰漾根，就產(chǎn)生了空白數(shù)據(jù)塊泰涂。CRC校驗(yàn)碼可以檢查這些塊并移除，當(dāng)然因?yàn)楸罎⒍磳?xiě)入的數(shù)據(jù)塊也就丟失了辐怕。