Kafka使用入门教程
轉載自http://www.linuxidc.com/Linux/2014-07/104470.htm
https://www.cnblogs.com/dhl-2013/p/5678704.html
介紹
? ? ?kafka是一款基于發布與訂閱的消息系統。它一般被稱為“分布式提交日志”或者“分布式流平臺”。文件系統或者數據庫提交日志用來提供所有事物的持久化記錄，通過重建這些日志可以重建系統的狀態。同樣地，kafka的數據是按照一定順序持久化保存的，可以按需讀取。
1、kafka拓撲結構
#創建topic ./bin/kafka-topics.sh?--create?--zookeeper?localhost:2181?--replication-factor?1?--partitions?1?--topic?test#展示topic ./bin/kafka-topics.sh?--list?--zookeeper?localhost:2181#描述topic ./bin/kafka-topics.sh?--describe?--zookeeper?localhost:2181?--topic?my-replicated-topic#生產者： ./bin/kafka-console-producer.sh?--broker-list?130.51.23.95:9092?--topic?my-replicated-topic#消費者： ./bin/kafka-console-consumer.sh?--zookeeper?130.51.23.95:2181?--topic?test?--from-beginnin刪除topic ./bin/kafka-topics.sh?--delete?--zookeeper?130.51.23.95:2181?--topic?topicname 刪除topic中存儲的內容在config/server.properties中找到如下的位置? ?刪除log.dirs指定的文件目錄，然后重新啟動就可以了
2、Kafka的特點
? ?同時為分布和訂閱提供高吞吐量。據了解，Kafka每秒可以生產約25萬條消息（50MB），每秒處理55萬條消息（110MB）這里說條數，可能不上特別準確，因為消息的大小可能不一致；
? ?可進行持久化操作，將消息持久化到到磁盤，以日志的形式存儲，因此可用于批量消費，例如ETL，以及實時應用程序。 通過將數據持久化到硬盤以及replication防止數據丟失。
? 分布式系統，易于向外拓展。所有的Producer、broker和consumer都會有多個，均為分布式。無需停機即可拓展機器。
? 消息被處理的狀態是在consumer端維護，而不是由server端維護，當失敗時能自動平衡。
? 支持Online和offline的場景。
3、Kafka的核心概念
名詞解釋
Producer：消息的生成者
Consumer：消息的消費者
ConsumerGroup：消費者組，可以并行消費Topic中的partition的消息
Broker：緩存代理，Kafka集群中的一臺或多臺服務器統稱broker.
TopicKafka：處理資源的消息源(feeds of messages)的不同分類
PartitionTopic：物理上的分組，一個topic可以分為多個partion,每個partion是一個有序的隊列。partion中每條消息都會被分? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 配一個 有序的Id(offset)
Message：消息，是通信的基本單位，每個producer可以向一個topic（主題）發布一些消息
Producers：消息和數據生成者，向Kafka的一個topic發布消息的 過程叫做producers
Consumers：消息和數據的消費者，訂閱topic并處理其發布的消費過程叫做consumers
? 3.1 Producers的概念
?消息和數據生成者，向Kafka的一個topic發布消息的過程叫做producers??
?Producer將消息發布到指定的Topic中，同時Producer也能決定將此消息歸屬于哪個partition；比如基于round-robin方式? ? ? ? ?或者通過其他的一些算法等；
異步發送批量發送可以很有效的提高發送效率。kafka producer的異步發送模式允許進行批量發送，先將消息緩存到內存中，然后一次請求批量發送出去。
? ?3.2? broker的概念:
?Broker沒有副本機制，一旦broker宕機，該broker的消息將都不可用。
?Broker不保存訂閱者的狀態，由訂閱者自己保存。
?無狀態導致消息的刪除成為難題（可能刪除的消息正在被訂閱），Kafka采用基于時間的SLA（服務保證），消息保存一定時間（通常7天）后會刪除。
?消費訂閱者可以rewind back到任意位置重新進行消費，當訂閱者故障時，可以選擇最小的offset(id)進行重新讀取消費消息
? ? 3.3 Message組成
?Message消息：是通信的基本單位，每個producer可以向一個topic發布消息。
?Kafka中的Message是以topic為基本單位組織的，不同的topic之間是相互獨立的，每個topic又可以分成不同的partition每個partition儲存一部分
?partion中的每條Message包含以下三個屬性：? ??
| offset? ?? | long |
| MessageSize | int32 |
| data? | messages的具體內容 |
?? 3.4? Consumers的概念
? ? ? 消息和數據消費者，訂閱topic并處理其發布的消息的過程叫做consumers.
? ? ? 在kafka中，我們可以認為一個group是一個“訂閱者”，一個topic中的每個partions只會被一個“訂閱者”中的一個consumer
? ? ? 消費，不過一個consumer可以消費多個partitions中的消息
? ? ? 注:
? ? ? ?Kafka的設計原理決定，對于一個topic，同一個group不能多于partition個數的consumer同時消費，否則將意味著某些? ? ? ? ? ? ? ? ? ? ? consumer無法得到消息
搭建Kafka運行環境
Step 1: 下載Kafka
點擊下載最新的版本并解壓.
>?tar?-xzf?kafka_2.9.2-0.8.1.1.tgz >?cd?kafka_2.9.2-0.8.1.1Step 2: 啟動服務
Kafka用到了Zookeeper，所有首先啟動Zookper，下面簡單的啟用一個單實例的Zookkeeper服務。可以在命令的結尾加個&符號，這樣就可以啟動后離開控制臺。
>?bin/zookeeper-server-start.sh?config/zookeeper.properties?& [2013-04-22?15:01:37,495]?INFO?Reading?configuration?from:?config/zookeeper.properties?(org.apache.zookeeper.server.quorum.QuorumPeerConfig) ...現在啟動Kafka:
>?bin/kafka-server-start.sh?config/server.properties [2013-04-22?15:01:47,028]?INFO?Verifying?properties?(kafka.utils.VerifiableProperties) [2013-04-22?15:01:47,051]?INFO?Property?socket.send.buffer.bytes?is?overridden?to?1048576?(kafka.utils.VerifiableProperties) ...Step 3: 創建 topic
創建一個叫做“test”的topic，它只有一個分區，一個副本。
>?bin/kafka-topics.sh?--create?--zookeeper?localhost:2181?--replication-factor?1?--partitions?1?--topic?test可以通過list命令查看創建的topic:
除了手動創建topic，還可以配置broker讓它自動創建topic.
Step 4:發送消息.
Kafka 使用一個簡單的命令行producer，從文件中或者從標準輸入中讀取消息并發送到服務端。默認的每條命令將發送一條消息。
運行producer并在控制臺中輸一些消息，這些消息將被發送到服務端：
>?bin/kafka-console-producer.sh?--broker-list?localhost:9092?--topic?test? This?is?a?messageThis?is?another?message ctrl+c可以退出發送。Step 5: 啟動consumer
Kafka also has a command line consumer that will dump out messages to standard output.
Kafka也有一個命令行consumer可以讀取消息并輸出到標準輸出：
>?bin/kafka-console-consumer.sh?--zookeeper?localhost:2181?--topic?test?--from-beginning This?is?a?message This?is?another?message你在一個終端中運行consumer命令行，另一個終端中運行producer命令行，就可以在一個終端輸入消息，另一個終端讀取消息。這兩個命令都有自己的可選參數，可以在運行的時候不加任何參數可以看到幫助信息。
?
Step 6: 搭建一個多個broker的集群
剛才只是啟動了單個broker，現在啟動有3個broker組成的集群，這些broker節點也都是在本機上的：
首先為每個節點編寫配置文件：
>?cp?config/server.properties?config/server-1.properties >?cp?config/server.properties?config/server-2.properties在拷貝出的新文件中添加以下參數：
config/server-1.properties:broker.id=1port=9093log.dir=/tmp/kafka-logs-1config/server-2.properties:broker.id=2port=9094log.dir=/tmp/kafka-logs-2broker.id在集群中唯一的標注一個節點，因為在同一個機器上，所以必須制定不同的端口和日志文件，避免數據被覆蓋。
?
We already have Zookeeper and our single node started, so we just need to start the two new nodes:
剛才已經啟動可Zookeeper和一個節點，現在啟動另外兩個節點：
>?bin/kafka-server-start.sh?config/server-1.properties?&... >?bin/kafka-server-start.sh?config/server-2.properties?&...創建一個擁有3個副本的topic:
現在我們搭建了一個集群，怎么知道每個節點的信息呢？運行“"describe topics”命令就可以了：
>?bin/kafka-topics.sh?--describe?--zookeeper?localhost:2181?--topic?my-replicated-topic Topic:my-replicated-topic???????PartitionCount:1????????ReplicationFactor:3?????Configs: Topic:?my-replicated-topic??????Partition:?0????Leader:?1???????Replicas:?1,2,0?Isr:?1,2,0下面解釋一下這些輸出。第一行是對所有分區的一個描述，然后每個分區都會對應一行，因為我們只有一個分區所以下面就只加了一行。leader：負責處理消息的讀和寫，leader是從所有節點中隨機選擇的.
replicas：列出了所有的副本節點，不管節點是否在服務中.
isr：是正在服務中的節點.
在我們的例子中，節點1是作為leader運行。
向topic發送消息：
>?bin/kafka-console-producer.sh?--broker-list?localhost:9092?--topic?my-replicated-topic ... my?test?message?1my?test?message?2^C消費這些消息：
>?bin/kafka-console-consumer.sh?--zookeeper?localhost:2181?--from-beginning?--topic?my-replicated-topic ... my?test?message?1 my?test?message?2 ^C測試一下容錯能力.Broker 1作為leader運行，現在我們kill掉它：
>?ps?|?grep?server-1.properties7564?ttys002????0:15.91?/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/java... >?kill?-9?7564另外一個節點被選做了leader,node 1 不再出現在 in-sync 副本列表中：
>?bin/kafka-topics.sh?--describe?--zookeeper?localhost:218192?--topic?my-replicated-topic Topic:my-replicated-topic???????PartitionCount:1????????ReplicationFactor:3?????Configs:Topic:?my-replicated-topic??????Partition:?0????Leader:?2???????Replicas:?1,2,0?Isr:?2,0雖然最初負責續寫消息的leader down掉了，但之前的消息還是可以消費的：
下面我們來搭建kafka的開發環境。
添加依賴
搭建開發環境需要引入kafka的jar包，一種方式是將Kafka安裝包中lib下的jar包加入到項目的classpath中，這種比較簡單了。不過我們使用另一種更加流行的方式：使用maven管理jar包依賴。
創建好maven項目后，在pom.xml中添加以下依賴：
<dependency><groupId>?org.apache.kafka</groupId?><artifactId>?kafka_2.10</artifactId?><version>?0.8.0</?version> </dependency>添 加依賴后你會發現有兩個jar包的依賴找不到。沒關系我都幫你想好了，點擊這里下載這兩個jar包，解壓后你有兩種選擇，第一種是使用mvn的 install命令將jar包安裝到本地倉庫，另一種是直接將解壓后的文件夾拷貝到mvn本地倉庫的com文件夾下，比如我的本地倉庫是d:\mvn,完 成后我的目錄結構是這樣的：
?
配置程序
首先是一個充當配置文件作用的接口,配置了Kafka的各種連接參數：
package?com.sohu.kafkademon; public?interface?KafkaProperties {final?static?String?zkConnect?=?"10.22.10.139:2181";final?static?String?groupId?=?"group1";final?static?String?topic?=?"topic1";final?static?String?kafkaServerURL?=?"10.22.10.139";final?static?int?kafkaServerPort?=?9092;final?static?int?kafkaProducerBufferSize?=?64?*?1024;final?static?int?connectionTimeOut?=?20000;final?static?int?reconnectInterval?=?10000;final?static?String?topic2?=?"topic2";final?static?String?topic3?=?"topic3";final?static?String?clientId?=?"SimpleConsumerDemoClient"; }producer
package?com.sohu.kafkademon; import?java.util.Properties; import?kafka.producer.KeyedMessage; import?kafka.producer.ProducerConfig; /***?@author?leicui?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;}@Overridepublic?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?blocke.printStackTrace();}}} }consumer
package?com.sohu.kafkademon; import?java.util.HashMap; import?java.util.List; import?java.util.Map; import?java.util.Properties; import?kafka.consumer.ConsumerConfig; import?kafka.consumer.ConsumerIterator; import?kafka.consumer.KafkaStream; import?kafka.javaapi.consumer.ConsumerConnector; /***?@author?leicui?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);}@Overridepublic?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();}}} }簡單的發送接收
運行下面這個程序，就可以進行簡單的發送接收消息了：
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();} }高級別的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);}@Overridepublic?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();}}} }不要畏懼文件系統!
Kafka大量依賴文件系統去存儲和緩存消息。對于硬盤有個傳統的觀念是硬盤總是很慢，這使很多人懷疑基于文件系統的架構能否提供優異的性能。實際上硬盤的快慢完全取決于使用它的方式。設計良好的硬盤架構可以和內存一樣快。
在6塊7200轉的SATA RAID-5磁盤陣列的線性寫速度差不多是600MB/s，但是隨即寫的速度卻是100k/s，差了差不多6000倍。現代的操作系統都對次做了大量的優 化，使用了 read-ahead 和 write-behind的技巧，讀取的時候成塊的預讀取數據，寫的時候將各種微小瑣碎的邏輯寫入組織合并成一次較大的物理寫入。對此的深入討論可以查看 這里，它們發現線性的訪問磁盤，很多時候比隨機的內存訪問快得多。
為了提高性能，現代操作系統往往使用內存作為磁盤的緩存，現代操作系統樂于把所有空閑內存用作磁盤緩存，雖然這可能在緩存回收和重新分配時犧牲一些 性能。所有的磁盤讀寫操作都會經過這個緩存，這不太可能被繞開除非直接使用I/O。所以雖然每個程序都在自己的線程里只緩存了一份數據，但在操作系統的緩 存里還有一份，這等于存了兩份數據。
另外再來討論一下JVM,以下兩個事實是眾所周知的：
?Java對象占用空間是非常大的，差不多是要存儲的數據的兩倍甚至更高。
?隨著堆中數據量的增加，垃圾回收回變的越來越困難。
基于以上分析，如果把數據緩存在內存里，因為需要存儲兩份，不得不使用兩倍的內存空間，Kafka基于JVM，又不得不將空間再次加倍,再加上要避 免GC帶來的性能影響，在一個32G內存的機器上，不得不使用到28-30G的內存空間。并且當系統重啟的時候，又必須要將數據刷到內存中（ 10GB 內存差不多要用10分鐘），就算使用冷刷新（不是一次性刷進內存，而是在使用數據的時候沒有就刷到內存）也會導致最初的時候新能非常慢。但是使用文件系 統，即使系統重啟了，也不需要刷新數據。使用文件系統也簡化了維護數據一致性的邏輯。
所以與傳統的將數據緩存在內存中然后刷到硬盤的設計不同，Kafka直接將數據寫到了文件系統的日志中。
常量時間的操作效率
在大多數的消息系統中，數據持久化的機制往往是為每個cosumer提供一個B樹或者其他的隨機讀寫的數據結構。B樹當然是很棒的，但是也帶了一些 代價：比如B樹的復雜度是O(log N)，O(log N)通常被認為就是常量復雜度了，但對于硬盤操作來說并非如此。磁盤進行一次搜索需要10ms，每個硬盤在同一時間只能進行一次搜索，這樣并發處理就成了 問題。雖然存儲系統使用緩存進行了大量優化，但是對于樹結構的性能的觀察結果卻表明，它的性能往往隨著數據的增長而線性下降，數據增長一倍，速度就會降低 一倍。
直觀的講，對于主要用于日志處理的消息系統，數據的持久化可以簡單的通過將數據追加到文件中實現，讀的時候從文件中讀就好了。這樣做的好處是讀和寫都是 O(1) 的，并且讀操作不會阻塞寫操作和其他操作。這樣帶來的性能優勢是很明顯的，因為性能和數據的大小沒有關系了。
既然可以使用幾乎沒有容量限制（相對于內存來說）的硬盤空間建立消息系統，就可以在沒有性能損失的情況下提供一些一般消息系統不具備的特性。比如， 一般的消息系統都是在消息被消費后立即刪除，Kafka卻可以將消息保存一段時間（比如一星期），這給consumer提供了很好的機動性和靈活性，這點 在今后的文章中會有詳述。
?
之前討論了consumer和producer是怎么工作的，現在來討論一下數據傳輸方面。數據傳輸的事務定義通常有以下三種級別：
最多一次:?消息不會被重復發送，最多被傳輸一次，但也有可能一次不傳輸。
最少一次:?消息不會被漏發送，最少被傳輸一次，但也有可能被重復傳輸.
精確的一次（Exactly once）:?不會漏傳輸也不會重復傳輸,每個消息都傳輸被一次而且僅僅被傳輸一次，這是大家所期望的。
大多數消息系統聲稱可以做到“精確的一次”，但是仔細閱讀它們的的文檔可以看到里面存在誤導，比如沒有說明當consumer或producer失 敗時怎么樣，或者當有多個consumer并行時怎么樣，或寫入硬盤的數據丟失時又會怎么樣。kafka的做法要更先進一些。當發布消息時，Kafka有 一個“committed”的概念，一旦消息被提交了，只要消息被寫入的分區的所在的副本broker是活動的，數據就不會丟失。關于副本的活動的概念， 下節文檔會討論。現在假設broker是不會down的。
如果producer發布消息時發生了網絡錯誤，但又不確定實在提交之前發生的還是提交之后發生的，這種情況雖然不常見，但是必須考慮進去，現在Kafka版本還沒有解決這個問題，將來的版本正在努力嘗試解決。
并 不是所有的情況都需要“精確的一次”這樣高的級別，Kafka允許producer靈活的指定級別。比如producer可以指定必須等待消息被提交的通 知，或者完全的異步發送消息而不等待任何通知，或者僅僅等待leader聲明它拿到了消息（followers沒有必要）。
現在從consumer的方面考慮這個問題，所有的副本都有相同的日志文件和相同的offset，consumer維護自己消費的消息的 offset，如果consumer不會崩潰當然可以在內存中保存這個值，當然誰也不能保證這點。如果consumer崩潰了，會有另外一個 consumer接著消費消息，它需要從一個合適的offset繼續處理。這種情況下可以有以下選擇：
?
consumer可以先讀取消息，然后將offset寫入日志文件中，然后再處理消息。這存在一種可能就是在存儲offset后還沒處理消息就crash了，新的consumer繼續從這個offset處理，那么就會有些消息永遠不會被處理，這就是上面說的“最多一次”。
consumer可以先讀取消息，處理消息，最后記錄offset，當然如果在記錄offset之前就crash了，新的consumer會重復的消費一些消息，這就是上面說的“最少一次”。
“精確一次”可以通過將提交分為兩個階段來解決：保存了offset后提交一次，消息處理成功之后再提交一次。但是還有個更簡單的做法：將消息的offset和消息被處理后的結果保存在一起。比如用Hadoop?ETL處理消息時，將處理后的結果和offset同時保存在HDFS中，這樣就能保證消息和offser同時被處理了。
Kafka在提高效率方面做了很大努力。Kafka的一個主要使用場景是處理網站活動日志，吞吐量是非常大的，每個頁面都會產生好多次寫操作。讀方面，假設每個消息只被消費一次，讀的量的也是很大的，Kafka也盡量使讀的操作更輕量化。
我們之前討論了磁盤的性能問題，線性讀寫的情況下影響磁盤性能問題大約有兩個方面：太多的瑣碎的I/O操作和太多的字節拷貝。I/O問題發生在客戶端和服務端之間，也發生在服務端內部的持久化的操作中。
消息集（message set）
為 了避免這些問題，Kafka建立了“消息集（message set）”的概念，將消息組織到一起，作為處理的單位。以消息集為單位處理消息，比以單個的消息為單位處理，會提升不少性能。Producer把消息集一 塊發送給服務端，而不是一條條的發送；服務端把消息集一次性的追加到日志文件中，這樣減少了瑣碎的I/O操作。consumer也可以一次性的請求一個消 息集。
另外一個性能優化是在字節拷貝方面。在低負載的情況下這不是問題，但是在高負載的情況下它的影響還是很大的。為了避免這個問題，Kafka使用了標準的二進制消息格式，這個格式可以在producer,broker和producer之間共享而無需做任何改動。
zero copy
Broker 維護的消息日志僅僅是一些目錄文件，消息集以固定隊的格式寫入到日志文件中，這個格式producer和consumer是共享的，這使得Kafka可以 一個很重要的點進行優化：消息在網絡上的傳遞。現代的unix操作系統提供了高性能的將數據從頁面緩存發送到socket的系統函數，在linux中，這 個函數是sendfile.
為了更好的理解sendfile的好處，我們先來看下一般將數據從文件發送到socket的數據流向：
操作系統把數據從文件拷貝內核中的頁緩存中
應用程序從頁緩存從把數據拷貝自己的內存緩存中
應用程序將數據寫入到內核中socket緩存中
操作系統把數據從socket緩存中拷貝到網卡接口緩存，從這里發送到網絡上。
這顯然是低效率的，有4次拷貝和2次系統調用。Sendfile通過直接將數據從頁面緩存發送網卡接口緩存，避免了重復拷貝，大大的優化了性能。
在一個多consumers的場景里，數據僅僅被拷貝到頁面緩存一次而不是每次消費消息的時候都重復的進行拷貝。這使得消息以近乎網絡帶寬的速率發送出去。這樣在磁盤層面你幾乎看不到任何的讀操作，因為數據都是從頁面緩存中直接發送到網絡上去了。
這篇文章詳細介紹了sendfile和zero-copy技術在Java方面的應用。
數據壓縮
很 多時候，性能的瓶頸并非CPU或者硬盤而是網絡帶寬，對于需要在數據中心之間傳送大量數據的應用更是如此。當然用戶可以在沒有Kafka支持的情況下各自 壓縮自己的消息，但是這將導致較低的壓縮率，因為相比于將消息單獨壓縮，將大量文件壓縮在一起才能起到最好的壓縮效果。
Kafka采用了端到端的 壓縮：因為有“消息集”的概念，客戶端的消息可以一起被壓縮后送到服務端，并以壓縮后的格式寫入日志文件，以壓縮的格式發送到consumer，消息從 producer發出到consumer拿到都被是壓縮的，只有在consumer使用的時候才被解壓縮，所以叫做“端到端的壓縮”。
Kafka支持GZIP和Snappy壓縮協議。
?
Kafka Producer
消息發送
producer直接將數據發送到broker的leader(主節點)，不需要在多個節點進行分發。為了幫助producer做到這點，所有的 Kafka節點都可以及時的告知:哪些節點是活動的，目標topic目標分區的leader在哪。這樣producer就可以直接將消息發送到目的地了。
客戶端控制消息將被分發到哪個分區。可以通過負載均衡隨機的選擇，或者使用分區函數。Kafka允許用戶實現分區函數，指定分區的key，將消息 hash到不同的分區上(當然有需要的話，也可以覆蓋這個分區函數自己實現邏輯).比如如果你指定的key是user id，那么同一個用戶發送的消息都被發送到同一個分區上。經過分區之后，consumer就可以有目的的消費某個分區的消息。
異步發送
批量發送可以很有效的提高發送效率。Kafka producer的異步發送模式允許進行批量發送，先將消息緩存在內存中，然后一次請求批量發送出去。這個策略可以配置的，比如可以指定緩存的消息達到某 個量的時候就發出去，或者緩存了固定的時間后就發送出去（比如100條消息就發送，或者每5秒發送一次）。這種策略將大大減少服務端的I/O次數。
既然緩存是在producer端進行的，那么當producer崩潰時，這些消息就會丟失。Kafka0.8.1的異步發送模式還不支持回調，就不能在發送出錯時進行處理。Kafka 0.9可能會增加這樣的回調函數。見Proposed Producer API.
Kafka Consumer
Kafa consumer消費消息時，向broker發出"fetch"請求去消費特定分區的消息。consumer指定消息在日志中的偏移量（offset）， 就可以消費從這個位置開始的消息。customer擁有了offset的控制權，可以向后回滾去重新消費之前的消息，這是很有意義的。
推還是拉？
Kafka最初考慮的問題是，customer應該從brokes拉取消息還是brokers將消息推送到consumer，也就是pull還 push。在這方面，Kafka遵循了一種大部分消息系統共同的傳統的設計：producer將消息推送到broker，consumer從broker 拉取消息。
一些消息系統比如Scribe和Apache Flume采用了push模式，將消息推送到下游的consumer。這樣做有好處也有壞處：由broker決定消息推送的速率，對于不同消費速率的 consumer就不太好處理了。消息系統都致力于讓consumer以最大的速率最快速的消費消息，但不幸的是，push模式下，當broker推送的 速率遠大于consumer消費的速率時，consumer恐怕就要崩潰了。最終Kafka還是選取了傳統的pull模式。
Pull模式的另外一 個好處是consumer可以自主決定是否批量的從broker拉取數據。Push模式必須在不知道下游consumer消費能力和消費策略的情況下決定 是立即推送每條消息還是緩存之后批量推送。如果為了避免consumer崩潰而采用較低的推送速率，將可能導致一次只推送較少的消息而造成浪費。Pull 模式下，consumer就可以根據自己的消費能力去決定這些策略。
Pull有個缺點是，如果broker沒有可供消費的消息，將導致consumer不斷在循環中輪詢，直到新消息到t達。為了避免這點，Kafka有個參數可以讓consumer阻塞知道新消息到達(當然也可以阻塞知道消息的數量達到某個特定的量這樣就可以批量發送)。
消費狀態跟蹤
對消費消息狀態的記錄也是很重要的。
大部分消息系統在broker端的維護消息被消費的記錄：一個消息被分發到consumer后broker就馬上進行標記或者等待customer的通知后進行標記。這樣也可以在消息在消費后立馬就刪除以減少空間占用。
但 是這樣會不會有什么問題呢？如果一條消息發送出去之后就立即被標記為消費過的，一旦consumer處理消息時失敗了（比如程序崩潰）消息就丟失了。為了 解決這個問題，很多消息系統提供了另外一個個功能：當消息被發送出去之后僅僅被標記為已發送狀態，當接到consumer已經消費成功的通知后才標記為已 被消費的狀態。這雖然解決了消息丟失的問題，但產生了新問題，首先如果consumer處理消息成功了但是向broker發送響應時失敗了，這條消息將被 消費兩次。第二個問題時，broker必須維護每條消息的狀態，并且每次都要先鎖住消息然后更改狀態然后釋放鎖。這樣麻煩又來了，且不說要維護大量的狀態 數據，比如如果消息發送出去但沒有收到消費成功的通知，這條消息將一直處于被鎖定的狀態，
Kafka采用了不同的策略。Topic被分成了若干分 區，每個分區在同一時間只被一個consumer消費。這意味著每個分區被消費的消息在日志中的位置僅僅是一個簡單的整數：offset。這樣就很容易標 記每個分區消費狀態就很容易了，僅僅需要一個整數而已。這樣消費狀態的跟蹤就很簡單了。
這帶來了另外一個好處：consumer可以把 offset調成一個較老的值，去重新消費老的消息。這對傳統的消息系統來說看起來有些不可思議，但確實是非常有用的，誰規定了一條消息只能被消費一次 呢？consumer發現解析數據的程序有bug，在修改bug后再來解析一次消息，看起來是很合理的額呀！
離線處理消息
高級的數據持久化允許consumer每個隔一段時間批量的將數據加載到線下系統中比如Hadoop或者數據倉庫。這種情況下，Hadoop可以將加載任務分拆，拆成每個broker或每個topic或每個分區一個加載任務。Hadoop具有任務管理功能，當一個任務失敗了就可以重啟而不用擔心數據被重新加載，只要從上次加載的位置繼續加載消息就可以了。
?
Kafka允許topic的分區擁有若干副本，這個數量是可以配置的，你可以為每個topci配置副本的數量。Kafka會自動在每個個副本上備份數據，所以當一個節點down掉時數據依然是可用的。
Kafka的副本功能不是必須的，你可以配置只有一個副本，這樣其實就相當于只有一份數據。
創建副本的單位是topic的分區，每個分區都有一個leader和零或多個followers.所有的讀寫操作都由leader處理，一般分區的 數量都比broker的數量多的多，各分區的leader均勻的分布在brokers中。所有的followers都復制leader的日志，日志中的消 息和順序都和leader中的一致。flowers向普通的consumer那樣從leader那里拉取消息并保存在自己的日志文件中。
許多分布式的消息系統自動的處理失敗的請求，它們對一個節點是否
著（alive）”有著清晰的定義。Kafka判斷一個節點是否活著有兩個條件：
節點必須可以維護和ZooKeeper的連接，Zookeeper通過心跳機制檢查每個節點的連接。
如果節點是個follower,他必須能及時的同步leader的寫操作，延時不能太久。
符合以上條件的節點準確的說應該是“同步中的（in sync）”，而不是模糊的說是“活著的”或是“失敗的”。Leader會追蹤所有“同步中”的節點，一旦一個down掉了，或是卡住了，或是延時太 久，leader就會把它移除。至于延時多久算是“太久”，是由參數replica.lag.max.messages決定的，怎樣算是卡住了，怎是由參 數replica.lag.time.max.ms決定的。?
只有當消息被所有的副本加入到日志中時，才算是“committed”，只有 committed的消息才會發送給consumer，這樣就不用擔心一旦leader down掉了消息會丟失。Producer也可以選擇是否等待消息被提交的通知，這個是由參數request.required.acks決定的。
Kafka保證只要有一個“同步中”的節點，“committed”的消息就不會丟失。
Leader的選擇
Kafka的核心是日志文件，日志文件在集群中的同步是分布式數據系統最基礎的要素。
如果leaders永遠不會down的話我們就不需要followers了！一旦leader down掉了，需要在followers中選擇一個新的leader.但是followers本身有可能延時太久或者crash，所以必須選擇高質量的 follower作為leader.必須保證，一旦一個消息被提交了，但是leader down掉了，新選出的leader必須可以提供這條消息。大部分的分布式系統采用了多數投票法則選擇新的leader,對于多數投票法則，就是根據所有 副本節點的狀況動態的選擇最適合的作為leader.Kafka并不是使用這種方法。
Kafaka動態維護了一個同步狀態的副本的集合（a set of in-sync replicas），簡稱ISR，在這個集合中的節點都是和leader保持高度一致的，任何一條消息必須被這個集合中的每個節點讀取并追加到日志中了， 才回通知外部這個消息已經被提交了。因此這個集合中的任何一個節點隨時都可以被選為leader.ISR在ZooKeeper中維護。ISR中有f+1個 節點，就可以允許在f個節點down掉的情況下不會丟失消息并正常提供服。ISR的成員是動態的，如果一個節點被淘汰了，當它重新達到“同步中”的狀態 時，他可以重新加入ISR.這種leader的選擇方式是非常快速的，適合kafka的應用場景。
一個邪惡的想法：如果所有節點都down掉了怎么辦？Kafka對于數據不會丟失的保證，是基于至少一個節點是存活的，一旦所有節點都down了，這個就不能保證了。
實際應用中，當所有的副本都down掉時，必須及時作出反應。可以有以下兩種選擇:
等待ISR中的任何一個節點恢復并擔任leader。
選擇所有節點中（不只是ISR）第一個恢復的節點作為leader.
這是一個在可用性和連續性之間的權衡。如果等待ISR中的節點恢復，一旦ISR中的節點起不起來或者數據都是了，那集群就永遠恢復不了了。如果等待 ISR意外的節點恢復，這個節點的數據就會被作為線上數據，有可能和真實的數據有所出入，因為有些數據它可能還沒同步到。Kafka目前選擇了第二種策 略，在未來的版本中將使這個策略的選擇可配置，可以根據場景靈活的選擇。
這種窘境不只Kafka會遇到，幾乎所有的分布式數據系統都會遇到。
副本管理
以上僅僅以一個topic一個分區為例子進行了討論，但實際上一個Kafka將會管理成千上萬的topic分區.Kafka盡量的使所有分區均勻的分布到集群所有的節點上而不是集中在某些節點上，另外主從關系也盡量均衡這樣每個幾點都會擔任一定比例的分區的leader.
優化leader的選擇過程也是很重要的，它決定了系統發生故障時的空窗期有多久。Kafka選擇一個節點作為“controller”,當發現有 節點down掉的時候它負責在游泳分區的所有節點中選擇新的leader,這使得Kafka可以批量的高效的管理所有分區節點的主從關系。如果 controller down掉了，活著的節點中的一個會備切換為新的controller.
?
Kafka Producer APIs
Procuder API有兩種：kafka.producer.SyncProducer和kafka.producer.async.AsyncProducer.它們都實現了同一個接口：
class?Producer?{/*?將消息發送到指定分區?*/ publicvoid?send(kafka.javaapi.producer.ProducerData<K,V>?producerData);/*?批量發送一批消息?*/ publicvoid?send(java.util.List<kafka.javaapi.producer.ProducerData<K,V>>?producerData);/*?關閉producer?*/ publicvoid?close();}?
Producer API提供了以下功能：
可以將多個消息緩存到本地隊列里，然后異步的批量發送到broker，可以通過參數producer.type=async做到。緩存的大小可以通過一些參數指定：queue.time和batch.size。一個后臺線程（(kafka.producer.async.ProducerSendThread）從隊列中取出數據并讓kafka.producer.EventHandler將消息發送到broker，也可以通過參數event.handler定制handler，在producer端處理數據的不同的階段注冊處理器，比如可以對這一過程進行日志追蹤，或進行一些監控。只需實現kafka.producer.async.CallbackHandler接口，并在callback.handler中配置。
自己編寫Encoder來序列化消息，只需實現下面這個接口。默認的Encoder是kafka.serializer.DefaultEncoder。
interface Encoder<T> {
public Message toMessage(T data);
}
提供了基于Zookeeper的broker自動感知能力，可以通過參數zk.connect實現。如果不使用Zookeeper，也可以使用broker.list參數指定一個靜態的brokers列表，這樣消息將被隨機的發送到一個broker上，一旦選中的broker失敗了，消息發送也就失敗了。
通過分區函數kafka.producer.Partitioner類對消息分區。分區函數有兩個參數：key和可用的分區數量，從分區列表中選擇一個分區并返回id。默認的分區策略是hash(key)%numPartitions.如果key是null,就隨機的選擇一個。可以通過參數partitioner.class定制分區函數。
interface Partitioner<T> {
int partition(T key,?int numPartitions);
}
KafKa Consumer APIs
Consumer API有兩個級別。低級別的和一個指定的broker保持連接，并在接收完消息后關閉連接，這個級別是無狀態的，每次讀取消息都帶著offset。
高級別的API隱藏了和brokers連接的細節，在不必關心服務端架構的情況下和服務端通信。還可以自己維護消費狀態，并可以通過一些條件指定訂閱特定的topic,比如白名單黑名單或者正則表達式。
低級別的API
class?SimpleConsumer?{/*向一個broker發送讀取請求并得到消息集?*/ public?ByteBufferMessageSet?fetch(FetchRequest?request);/*向一個broker發送讀取請求并得到一個相應集?*/ 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); }低級別的API是高級別API實現的基礎，也是為了一些對維持消費狀態有特殊需求的場景，比如Hadoop?consumer這樣的離線consumer。
?
高級別的API
/*?創建連接?*/ ConsumerConnector?connector?=?Consumer.create(consumerConfig);interface?ConsumerConnector?{/** *?這個方法可以得到一個流的列表，每個流都是MessageAndMetadata的迭代，通過MessageAndMetadata可以拿到消息和其他的元數據（目前之后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是一個封裝了白名單或黑名單的正則表達式。 */ public?List<KafkaStream>?createMessageStreamsByFilter( TopicFilter?topicFilter,?int?numStreams);/*?提交目前消費到的offset?*/ public?commitOffsets()/*?關閉連接?*/ public?shutdown() }?
這個API圍繞著由KafkaStream實現的迭代器展開，每個流代表一系列從一個或多個分區多和broker上匯聚來的消息，每個流由一個線程 處理，所以客戶端可以在創建的時候通過參數指定想要幾個流。一個流是多個分區多個broker的合并，但是每個分區的消息只會流向一個流。
每調用一次createMessageStreams都會將consumer注冊到topic上，這樣consumer和brokers之間的負載 均衡就會進行調整。API鼓勵每次調用創建更多的topic流以減少這種調整。createMessageStreamsByFilter方法注冊監聽可 以感知新的符合filter的tipic。
?
消息格式
消息由一個固定長度的頭部和可變長度的字節數組組成。頭部包含了一個版本號和CRC32校驗碼。
?[plain]?view plaincopyprint?
/** *?具有N個字節的消息的格式如下 * *?如果版本號是0 * *?1.?1個字節的?"magic"?標記 * *?2.?4個字節的CRC32校驗碼 * *?3.?N?-?5個字節的具體信息 * *?如果版本號是1 * *?1.?1個字節的?"magic"?標記 * *?2.1個字節的參數允許標注一些附加的信息比如是否壓縮了，解碼類型等 * *?3.4個字節的CRC32校驗碼 * *?4.?N?-?6?個字節的具體信息 * */?
日志
一個叫做“my_topic”且有兩個分區的的topic,它的日志有兩個文件夾組成，my_topic_0和my_topic_1,每個文件夾里放著具體的數據文件，每個數據文件都是一系列的日志實體，每個日志實體有一個4個字節的整數N標注消息的長度，后邊跟著N個字節的消息。每 個消息都可以由一個64位的整數offset標注，offset標注了這條消息在發送到這個分區的消息流中的起始位置。每個日志文件的名稱都是這個文件第 一條日志的offset.所以第一個日志文件的名字就是00000000000.kafka.所以每相鄰的兩個文件名字的差就是一個數字S,S差不多就是 配置文件中指定的日志文件的最大容量。
消息的格式都由一個統一的接口維護，所以消息可以在producer,broker和consumer之間無縫的傳遞。存儲在硬盤上的消息格式如下所示：
/** *?具有N個字節的消息的格式如下 * *?如果版本號是0 * *?1.?1個字節的?"magic"?標記 * *?2.?4個字節的CRC32校驗碼 * *?3.?N?-?5個字節的具體信息 * *?如果版本號是1 * *?1.?1個字節的?"magic"?標記 * *?2.1個字節的參數允許標注一些附加的信息比如是否壓縮了，解碼類型等 * *?3.4個字節的CRC32校驗碼 * *?4.?N?-?6?個字節的具體信息 * */?
寫操作
消息被不斷的追加到最后一個日志的末尾，當日志的大小達到一個指定的值時就會產生一個新的文件。對于寫操作有兩個參數，一個規定了消息的數量達到這 個值時必須將數據刷新到硬盤上，另外一個規定了刷新到硬盤的時間間隔，這對數據的持久性是個保證，在系統崩潰的時候只會丟失一定數量的消息或者一個時間段 的消息。
讀操作
?
讀操作需要兩個參數：一個64位的offset和一個S字節的最大讀取量。S通常比單個消息的大小要大，但在一些個別消息比較大的情況下，S會小于 單個消息的大小。這種情況下讀操作會不斷重試，每次重試都會將讀取量加倍，直到讀取到一個完整的消息。可以配置單個消息的最大值，這樣服務器就會拒絕大小 超過這個值的消息。也可以給客戶端指定一個嘗試讀取的最大上限，避免為了讀到一個完整的消息而無限次的重試。
在實際執行讀取操縱時，首先需要定位數據所在的日志文件，然后根據offset計算出在這個日志中的offset(前面的的offset是整個分區 的offset),然后在這個offset的位置進行讀取。定位操作是由二分查找法完成的，Kafka在內存中為每個文件維護了offset的范圍。
?
下面是發送給consumer的結果的格式：
MessageSetSend?(fetch?result)total?length?????:?4?bytes error?code???????:?2?bytes message?1????????:?x?bytes ... message?n????????:?x?bytesMultiMessageSetSend?(multiFetch?result)total?length???????:?4?bytes error?code?????????:?2?bytes messageSetSend?1 ... messageSetSend?n刪除
日志管理器允許定制刪除策略。目前的策略是刪除修改時間在N天之前的日志（按時間刪除），也可以使用另外一個策略：保留最后的N GB數據的策略(按大小刪除)。為了避免在刪除時阻塞讀操作，采用了copy-on-write形式的實現，刪除操作進行時，讀取操作的二分查找功能實際 是在一個靜態的快照副本上進行的，這類似于Java的CopyOnWriteArrayList。
可靠性保證
日志文件有一個可配置的參數M，緩存超過這個數量的消息將被強行刷新到硬盤。一個日志矯正線程將循環檢查最新的日志文件中的消息確認每個消息都是合 法的。合法的標準為：所有文件的大小的和最大的offset小于日志文件的大小，并且消息的CRC32校驗碼與存儲在消息實體中的校驗碼一致。如果在某個 offset發現不合法的消息，從這個offset到下一個合法的offset之間的內容將被移除。
有兩種情況必須考慮：1，當發生崩潰時有些數據塊未能寫入。2，寫入了一些空白數據塊。第二種情況的原因是，對于每個文件，操作系統都有一個 inode（inode是指在許多“類Unix文件系統”中的一種數據結構。每個inode保存了文件系統中的一個文件系統對象,包括文件、目錄、大小、 設備文件、socket、管道, 等等），但無法保證更新inode和寫入數據的順序，當inode保存的大小信息被更新了，但寫入數據時發生了崩潰，就產生了空白數據塊。CRC校驗碼可 以檢查這些塊并移除，當然因為崩潰而未寫入的數據塊也就丟失了。
轉載于:https://blog.51cto.com/qiangsh/1763817
總結
以上是生活随笔為你收集整理的Kafka使用入门教程的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 设置响应格式
- 下一篇： swift如何打印对象的地址