介紹
Kafka是一個(gè)分布式的、可分區(qū)的、可復(fù)制的消息系統(tǒng)。它提供了普通消息系統(tǒng)的功能，但具有自己獨(dú)特的設(shè)計(jì)。這個(gè)獨(dú)特的設(shè)計(jì)是什么樣的呢？
首先讓我們看幾個(gè)基本的消息系統(tǒng)術(shù)語：
•Kafka將消息以topic為單位進(jìn)行歸納。
•將向Kafka topic發(fā)布消息的程序成為producers.
•將預(yù)訂topics并消費(fèi)消息的程序成為consumer.
•Kafka以集群的方式運(yùn)行，可以由一個(gè)或多個(gè)服務(wù)組成，每個(gè)服務(wù)叫做一個(gè)broker.
producers通過網(wǎng)絡(luò)將消息發(fā)送到Kafka集群，集群向消費(fèi)者提供消息，如下圖所示：
客戶端和服務(wù)端通過TCP協(xié)議通信。Kafka提供了Java客戶端，并且對(duì)多種語言都提供了支持。
每個(gè)分區(qū)都由一個(gè)服務(wù)器作為“leader”，零或若干服務(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ù)載均衡。
Consumers
接下來一步一步搭建Kafka運(yùn)行環(huán)境。
> tar -xzf kafka_2.9.2-0.8.1.1.tgz > cd kafka_2.9.2-0.8.1.1Step 2: 啟動(dòng)服務(wù)
> 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)...現(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)...Step 3: 創(chuàng)建 topic
> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test可以通過list命令查看創(chuàng)建的topic:
> bin/kafka-topics.sh --list --zookeeper localhost:2181test
> bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test This is a messageThis is another message
ctrl+c可以退出發(fā)送。Step 5: 啟動(dòng)consumerKafka also has a command line consumer that will dump out messages to standard output.
> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test --from-beginningThis is a messageThis is another message
你在一個(gè)終端中運(yùn)行consumer命令行，另一個(gè)終端中運(yùn)行producer命令行，就可以在一個(gè)終端輸入消息，另一個(gè)終端讀取消息。
> cp config/server.properties config/server-2.properties在拷貝出的新文件中添加以下參數(shù)：
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
> bin/kafka-server-start.sh config/server-1.properties &...> bin/kafka-server-start.sh config/server-2.properties &...創(chuàng)建一個(gè)擁有3個(gè)副本的topic:
> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 1 --topic my-replicated-topic
> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topicTopic:my-replicated-topic PartitionCount:1 ReplicationFactor:3 Configs: Topic: my-replicated-topic Partition: 0 Leader: 1 Replicas: 1,2,0 Isr: 1,2,0
下面解釋一下這些輸出。第一行是對(duì)所有分區(qū)的一個(gè)描述，然后每個(gè)分區(qū)都會(huì)對(duì)應(yīng)一行，因?yàn)槲覀冎挥幸粋€(gè)分區(qū)所以下面就只加了一行。
向topic發(fā)送消息：
> bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-replicated-topic...my test message 1my test message 2^C消費(fèi)這些消息：
> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic...my test message 1my test message 2^C
> ps | grep server-1.properties7564 ttys002 0:15.91 /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/java...> kill -9 7564
> bin/kafka-topics.sh --describe --zookeeper localhost:218192 --topic my-replicated-topicTopic:my-replicated-topic PartitionCount:1 ReplicationFactor:3 Configs: Topic: my-replicated-topic Partition: 0 Leader: 2 Replicas: 1,2,0 Isr: 2,0
> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic...my test message 1my test message 2^C
看來Kafka的容錯(cuò)機(jī)制還是不錯(cuò)的。
<dependency>
<groupId> org.apache.kafka</groupId >
<artifactId> kafka_2.10</artifactId >
<version> 0.8.0</ version>
</dependency>
配置程序
首先是一個(gè)充當(dāng)配置文件作用的接口,配置了Kafka的各種連接參數(shù)：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
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
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
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(); } } }} |
consumer
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
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(); } } }} |
運(yùn)行下面這個(gè)程序，就可以進(jìn)行簡(jiǎn)單的發(fā)送接收消息了：簡(jiǎn)單的發(fā)送接收
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
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(); }} |
高級(jí)別的consumer
下面是比較負(fù)載的發(fā)送接收的程序：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
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(); } } }} |
不要畏懼文件系統(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)過這個(gè)緩存，這不太可能被繞開除非直接使用I/O。所以雖然每個(gè)程序都在自己的線程里只緩存了一份數(shù)據(jù)，但在操作系統(tǒng)的緩存里還有一份，這等于存了兩份數(shù)據(jù)。
另外再來討論一下JVM,以下兩個(gè)事實(shí)是眾所周知的：
•Java對(duì)象占用空間是非常大的，差不多是要存儲(chǔ)的數(shù)據(jù)的兩倍甚至更高。
•隨著堆中數(shù)據(jù)量的增加，垃圾回收回變的越來越困難。
基于以上分析，如果把數(shù)據(jù)緩存在內(nèi)存里，因?yàn)樾枰鎯?chǔ)兩份，不得不使用兩倍的內(nèi)存空間，Kafka基于JVM，又不得不將空間再次加倍,再加上要避免GC帶來的性能影響，在一個(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ì)于硬盤操作來說并非如此。磁盤進(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)單的通過將數(shù)據(jù)追加到文件中實(shí)現(xiàn)，讀的時(shí)候從文件中讀就好了。這樣做的好處是讀和寫都是 O(1) 的，并且讀操作不會(huì)阻塞寫操作和其他操作。這樣帶來的性能優(yōu)勢(shì)是很明顯的，因?yàn)樾阅芎蛿?shù)據(jù)的大小沒有關(guān)系了。
既然可以使用幾乎沒有容量限制（相對(duì)于內(nèi)存來說）的硬盤空間建立消息系統(tǒng)，就可以在沒有性能損失的情況下提供一些一般消息系統(tǒng)不具備的特性。比如，一般的消息系統(tǒng)都是在消息被消費(fèi)后立即刪除，Kafka卻可以將消息保存一段時(shí)間（比如一星期），這給consumer提供了很好的機(jī)動(dòng)性和靈活性，這點(diǎn)在今后的文章中會(huì)有詳述。
之前討論了consumer和producer是怎么工作的，現(xiàn)在來討論一下數(shù)據(jù)傳輸方面。數(shù)據(jù)傳輸?shù)氖聞?wù)定義通常有以下三種級(jí)別：
1.最多一次: 消息不會(huì)被重復(fù)發(fā)送，最多被傳輸一次，但也有可能一次不傳輸。
2.最少一次: 消息不會(huì)被漏發(fā)送，最少被傳輸一次，但也有可能被重復(fù)傳輸.
3.精確的一次（Exactly once）: 不會(huì)漏傳輸也不會(huì)重復(fù)傳輸,每個(gè)消息都傳輸被一次而且僅僅被傳輸一次，這是大家所期望的。
大多數(shù)消息系統(tǒng)聲稱可以做到“精確的一次”，但是仔細(xì)閱讀它們的的文檔可以看到里面存在誤導(dǎo)，比如沒有說明當(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è)問題，將來的版本正在努力嘗試解決。
并不是所有的情況都需要“精確的一次”這樣高的級(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)然誰也不能保證這點(diǎn)。如果consumer崩潰了，會(huì)有另外一個(gè)consumer接著消費(fèi)消息，它需要從一個(gè)合適的offset繼續(xù)處理。這種情況下可以有以下選擇：
•consumer可以先讀取消息，然后將offset寫入日志文件中，然后再處理消息。這存在一種可能就是在存儲(chǔ)offset后還沒處理消息就crash了，新的consumer繼續(xù)從這個(gè)offset處理，那么就會(huì)有些消息永遠(yuǎn)不會(huì)被處理，這就是上面說的“最多一次”。
•consumer可以先讀取消息，處理消息，最后記錄offset，當(dāng)然如果在記錄offset之前就crash了，新的consumer會(huì)重復(fù)的消費(fèi)一些消息，這就是上面說的“最少一次”。
•“精確一次”可以通過將提交分為兩個(gè)階段來解決：保存了offset后提交一次，消息處理成功之后再提交一次。但是還有個(gè)更簡(jiǎn)單的做法：將消息的offset和消息被處理后的結(jié)果保存在一起。比如用Hadoop ETL處理消息時(shí)，將處理后的結(jié)果和offset同時(shí)保存在HDFS中，這樣就能保證消息和offser同時(shí)被處理了。
Kafka在提高效率方面做了很大努力。Kafka的一個(gè)主要使用場(chǎng)景是處理網(wǎng)站活動(dòng)日志，吞吐量是非常大的，每個(gè)頁面都會(huì)產(chǎn)生好多次寫操作。讀方面，假設(shè)每個(gè)消息只被消費(fèi)一次，讀的量的也是很大的，Kafka也盡量使讀的操作更輕量化。
我們之前討論了磁盤的性能問題，線性讀寫的情況下影響磁盤性能問題大約有兩個(gè)方面：太多的瑣碎的I/O操作和太多的字節(jié)拷貝。I/O問題發(fā)生在客戶端和服務(wù)端之間，也發(fā)生在服務(wù)端內(nèi)部的持久化的操作中。
消息集（message set）
為了避免這些問題，Kafka建立了“消息集（message set）”的概念，將消息組織到一起，作為處理的單位。以消息集為單位處理消息，比以單個(gè)的消息為單位處理，會(huì)提升不少性能。Producer把消息集一塊發(fā)送給服務(wù)端，而不是一條條的發(fā)送；服務(wù)端把消息集一次性的追加到日志文件中，這樣減少了瑣碎的I/O操作。consumer也可以一次性的請(qǐng)求一個(gè)消息集。
另外一個(gè)性能優(yōu)化是在字節(jié)拷貝方面。在低負(fù)載的情況下這不是問題，但是在高負(fù)載的情況下它的影響還是很大的。為了避免這個(gè)問題，Kafka使用了標(biāo)準(zhǔn)的二進(jìn)制消息格式，這個(gè)格式可以在producer,broker和producer之間共享而無需做任何改動(dòng)。
zero copy
Broker維護(hù)的消息日志僅僅是一些目錄文件，消息集以固定隊(duì)的格式寫入到日志文件中，這個(gè)格式producer和consumer是共享的，這使得Kafka可以一個(gè)很重要的點(diǎn)進(jìn)行優(yōu)化：消息在網(wǎng)絡(luò)上的傳遞。現(xiàn)代的unix操作系統(tǒng)提供了高性能的將數(shù)據(jù)從頁面緩存發(fā)送到socket的系統(tǒng)函數(shù)，在linux中，這個(gè)函數(shù)是sendfile.
為了更好的理解sendfile的好處，我們先來看下一般將數(shù)據(jù)從文件發(fā)送到socket的數(shù)據(jù)流向：
1.操作系統(tǒng)把數(shù)據(jù)從文件拷貝內(nèi)核中的頁緩存中
2.應(yīng)用程序從頁緩存從把數(shù)據(jù)拷貝自己的內(nèi)存緩存中
3.應(yīng)用程序?qū)?shù)據(jù)寫入到內(nèi)核中socket緩存中
4.操作系統(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)化了性能。
在一個(gè)多consumers的場(chǎng)景里，數(shù)據(jù)僅僅被拷貝到頁面緩存一次而不是每次消費(fèi)消息的時(shí)候都重復(fù)的進(jìn)行拷貝。這使得消息以近乎網(wǎng)絡(luò)帶寬的速率發(fā)送出去。這樣在磁盤層面你幾乎看不到任何的讀操作，因?yàn)閿?shù)據(jù)都是從頁面緩存中直接發(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)然用戶可以在沒有Kafka支持的情況下各自壓縮自己的消息，但是這將導(dǎo)致較低的壓縮率，因?yàn)橄啾扔趯⑾为?dú)壓縮，將大量文件壓縮在一起才能起到最好的壓縮效果。
Kafka采用了端到端的壓縮：因?yàn)橛?ldquo;消息集”的概念，客戶端的消息可以一起被壓縮后送到服務(wù)端，并以壓縮后的格式寫入日志文件，以壓縮的格式發(fā)送到consumer，消息從producer發(fā)出到consumer拿到都被是壓縮的，只有在consumer使用的時(shí)候才被解壓縮，所以叫做“端到端的壓縮”。
Kafka支持GZIP和Snappy壓縮協(xié)議。更詳細(xì)的內(nèi)容可以查看這里。
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ū)。可以通過負(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)過分區(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ù)。見Proposed Producer API.
Kafka Consumer
Kafa consumer消費(fèi)消息時(shí)，向broker發(fā)出"fetch"請(qǐng)求去消費(fèi)特定分區(qū)的消息。consumer指定消息在日志中的偏移量（offset），就可以消費(fèi)從這個(gè)位置開始的消息。customer擁有了offset的控制權(quán)，可以向后回滾去重新消費(fèi)之前的消息，這是很有意義的。
推還是拉？
Kafka最初考慮的問題是，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沒有可供消費(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ì)有什么問題呢？如果一條消息發(fā)送出去之后就立即被標(biāo)記為消費(fèi)過的，一旦consumer處理消息時(shí)失敗了（比如程序崩潰）消息就丟失了。為了解決這個(gè)問題，很多消息系統(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)。這雖然解決了消息丟失的問題，但產(chǎn)生了新問題，首先如果consumer處理消息成功了但是向broker發(fā)送響應(yīng)時(shí)失敗了，這條消息將被消費(fèi)兩次。第二個(gè)問題時(shí)，broker必須維護(hù)每條消息的狀態(tài)，并且每次都要先鎖住消息然后更改狀態(tài)然后釋放鎖。這樣麻煩又來了，且不說要維護(hù)大量的狀態(tài)數(shù)據(jù)，比如如果消息發(fā)送出去但沒有收到消費(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)單了。
這帶來了另外一個(gè)好處：consumer可以把offset調(diào)成一個(gè)較老的值，去重新消費(fèi)老的消息。這對(duì)傳統(tǒng)的消息系統(tǒng)來說看起來有些不可思議，但確實(shí)是非常有用的，誰規(guī)定了一條消息只能被消費(fèi)一次呢？consumer發(fā)現(xiàn)解析數(shù)據(jù)的程序有bug，在修改bug后再來解析一次消息，看起來是很合理的額呀！
離線處理消息
高級(jí)的數(shù)據(jù)持久化允許consumer每個(gè)隔一段時(shí)間批量的將數(shù)據(jù)加載到線下系統(tǒng)中比如Hadoop或者數(shù)據(jù)倉庫。這種情況下，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.所有的讀寫操作都由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è)條件：
1.節(jié)點(diǎn)必須可以維護(hù)和ZooKeeper的連接，Zookeeper通過心跳機(jī)制檢查每個(gè)節(jié)點(diǎn)的連接。
2.如果節(jié)點(diǎn)是個(gè)follower,他必須能及時(shí)的同步leader的寫操作，延時(shí)不能太久。
符合以上條件的節(jié)點(diǎn)準(zhǔn)確的說應(yīng)該是“同步中的（in sync）”，而不是模糊的說是“活著的”或是“失敗的”。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)。可以有以下兩種選擇:
1.等待ISR中的任何一個(gè)節(jié)點(diǎn)恢復(fù)并擔(dān)任leader。
2.選擇所有節(jié)點(diǎn)中（不只是ISR）第一個(gè)恢復(fù)的節(jié)點(diǎn)作為leader.
這是一個(gè)在可用性和連續(xù)性之間的權(quán)衡。如果等待ISR中的節(jié)點(diǎn)恢復(fù)，一旦ISR中的節(jié)點(diǎn)起不起來或者數(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ù)它可能還沒同步到。Kafka目前選擇了第二種策略，在未來的版本中將使這個(gè)策略的選擇可配置，可以根據(jù)場(chǎng)景靈活的選擇。
這種窘境不只Kafka會(huì)遇到，幾乎所有的分布式數(shù)據(jù)系統(tǒng)都會(huì)遇到。
副本管理
以上僅僅以一個(gè)topic一個(gè)分區(qū)為例子進(jìn)行了討論，但實(shí)際上一個(gè)Kafka將會(huì)管理成千上萬的topic分區(qū).Kafka盡量的使所有分區(qū)均勻的分布到集群所有的節(jié)點(diǎn)上而不是集中在某些節(jié)點(diǎn)上，另外主從關(guān)系也盡量均衡這樣每個(gè)幾點(diǎn)都會(huì)擔(dān)任一定比例的分區(qū)的leader.
優(yōu)化leader的選擇過程也是很重要的，它決定了系統(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.
Kafka Producer APIs
Procuder API有兩種：kafka.producer.SyncProducer和kafka.producer.async.AsyncProducer.它們都實(shí)現(xiàn)了同一個(gè)接口：
|
1
2
3
4
5
6
7
8
9
10
11
|
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(); } |
Producer API提供了以下功能：
1.可以將多個(gè)消息緩存到本地隊(duì)列里，然后異步的批量發(fā)送到broker，可以通過參數(shù)producer.type=async做到。緩存的大小可以通過一些參數(shù)指定：queue.time和batch.size。一個(gè)后臺(tái)線程（(kafka.producer.async.ProducerSendThread）從隊(duì)列中取出數(shù)據(jù)并讓kafka.producer.EventHandler將消息發(fā)送到broker，也可以通過參數(shù)event.handler定制handler，在producer端處理數(shù)據(jù)的不同的階段注冊(cè)處理器，比如可以對(duì)這一過程進(jìn)行日志追蹤，或進(jìn)行一些監(jiān)控。只需實(shí)現(xiàn)kafka.producer.async.CallbackHandler接口，并在callback.handler中配置。
2.自己編寫Encoder來序列化消息，只需實(shí)現(xiàn)下面這個(gè)接口。默認(rèn)的Encoder是kafka.serializer.DefaultEncoder。
interface Encoder<T> {
public Message toMessage(T data);
}
3.提供了基于Zookeeper的broker自動(dòng)感知能力，可以通過參數(shù)zk.connect實(shí)現(xiàn)。如果不使用Zookeeper，也可以使用broker.list參數(shù)指定一個(gè)靜態(tài)的brokers列表，這樣消息將被隨機(jī)的發(fā)送到一個(gè)broker上，一旦選中的broker失敗了，消息發(fā)送也就失敗了。
4.通過分區(qū)函數(shù)kafka.producer.Partitioner類對(duì)消息分區(qū)。
nterface 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è)。可以通過參數(shù)partitioner.class定制分區(qū)函數(shù)。
KafKa Consumer APIs
Consumer API有兩個(gè)級(jí)別。低級(jí)別的和一個(gè)指定的broker保持連接，并在接收完消息后關(guān)閉連接，這個(gè)級(jí)別是無狀態(tài)的，每次讀取消息都帶著offset。
高級(jí)別的API隱藏了和brokers連接的細(xì)節(jié)，在不必關(guān)心服務(wù)端架構(gòu)的情況下和服務(wù)端通信。還可以自己維護(hù)消費(fèi)狀態(tài)，并可以通過一些條件指定訂閱特定的topic,比如白名單黑名單或者正則表達(dá)式。
低級(jí)別的API
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
class 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); } |
低級(jí)別的API是高級(jí)別API實(shí)現(xiàn)的基礎(chǔ)，也是為了一些對(duì)維持消費(fèi)狀態(tài)有特殊需求的場(chǎng)景，比如Hadoop consumer這樣的離線consumer。
高級(jí)別的API
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
/* 創(chuàng)建連接 */ConsumerConnector connector = Consumer.create(consumerConfig); interface ConsumerConnector { /** * 這個(gè)方法可以得到一個(gè)流的列表，每個(gè)流都是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); /** * 你也可以得到一個(gè)流的列表，它包含了符合TopicFiler的消息的迭代， * 一個(gè)TopicFilter是一個(gè)封裝了白名單或黑名單的正則表達(dá)式。 */public List<KafkaStream> createMessageStreamsByFilter( TopicFilter topicFilter, int numStreams); /* 提交目前消費(fèi)到的offset */public commitOffsets() /* 關(guān)閉連接 */public shutdown() } |
這個(gè)API圍繞著由KafkaStream實(shí)現(xiàn)的迭代器展開，每個(gè)流代表一系列從一個(gè)或多個(gè)分區(qū)多和broker上匯聚來的消息，每個(gè)流由一個(gè)線程處理，所以客戶端可以在創(chuàng)建的時(shí)候通過參數(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)聽可以感知新的符合filter的tipic。
消息格式
消息由一個(gè)固定長(zhǎng)度的頭部和可變長(zhǎng)度的字節(jié)數(shù)組組成。頭部包含了一個(gè)版本號(hào)和CRC32校驗(yàn)碼。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
/** * 具有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é)的具體信息 * */ |
日志
一個(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之間無縫的傳遞。存儲(chǔ)在硬盤上的消息格式如下所示：
1.消息長(zhǎng)度: 4 bytes (value: 1+4+n)
2.版本號(hào): 1 byte
3.CRC校驗(yàn)碼: 4 bytes
4.具體的消息: n bytes
寫操作
消息被不斷的追加到最后一個(gè)日志的末尾，當(dāng)日志的大小達(dá)到一個(gè)指定的值時(shí)就會(huì)產(chǎn)生一個(gè)新的文件。對(duì)于寫操作有兩個(gè)參數(shù)，一個(gè)規(guī)定了消息的數(shù)量達(dá)到這個(gè)值時(shí)必須將數(shù)據(jù)刷新到硬盤上，另外一個(gè)規(guī)定了刷新到硬盤的時(shí)間間隔，這對(duì)數(shù)據(jù)的持久性是個(gè)保證，在系統(tǒng)崩潰的時(shí)候只會(huì)丟失一定數(shù)量的消息或者一個(gè)時(shí)間段的消息。
讀操作
讀操作需要兩個(gè)參數(shù)：一個(gè)64位的offset和一個(gè)S字節(jié)的最大讀取量。S通常比單個(gè)消息的大小要大，但在一些個(gè)別消息比較大的情況下，S會(huì)小于單個(gè)消息的大小。這種情況下讀操作會(huì)不斷重試，每次重試都會(huì)將讀取量加倍，直到讀取到一個(gè)完整的消息。可以配置單個(gè)消息的最大值，這樣服務(wù)器就會(huì)拒絕大小超過這個(gè)值的消息。也可以給客戶端指定一個(gè)嘗試讀取的最大上限，避免為了讀到一個(gè)完整的消息而無限次的重試。
在實(shí)際執(zhí)行讀取操縱時(shí)，首先需要定位數(shù)據(jù)所在的日志文件，然后根據(jù)offset計(jì)算出在這個(gè)日志中的offset(前面的的offset是整個(gè)分區(qū)的offset),然后在這個(gè)offset的位置進(jìn)行讀取。定位操作是由二分查找法完成的，Kafka在內(nèi)存中為每個(gè)文件維護(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
刪除
日志管理器允許定制刪除策略。目前的策略是刪除修改時(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，緩存超過這個(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ù)塊未能寫入。2，寫入了一些空白數(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、管道, 等等），但無法保證更新inode和寫入數(shù)據(jù)的順序，當(dāng)inode保存的大小信息被更新了，但寫入數(shù)據(jù)時(shí)發(fā)生了崩潰，就產(chǎn)生了空白數(shù)據(jù)塊。CRC校驗(yàn)碼可以檢查這些塊并移除，當(dāng)然因?yàn)楸罎⒍磳懭氲臄?shù)據(jù)塊也就丟失了。
