Kafka 之 入門

摘要: 最近研究採集層，對Kafka作了一個研究。分爲入門，中級，高級步步進階。本篇主要介紹基本概念，適用場景。

            

                    

1、入門

1.    簡介

Kafka is a distributed, partitioned, replicated commit log service。它提供了相似於JMS的特性，可是在設計實現上徹底不一樣，此外它並非JMS規範的實現。kafka對消息保存時根據Topic進行歸類，發送消息者成爲Producer,消息接受者成爲Consumer,此外kafka集羣有多個kafka實例組成，每一個實例(server)成爲broker。不管是kafka集羣，仍是producer和consumer都依賴於zookeeper來保證系統可用性集羣保存一些meta信息。

下面這張圖描述更準確。

主要特性：

 1）消息持久化 要從大數據中獲取真正的價值，那麼不能丟失任何信息。Apache Kafka設計上是時間複雜度O(1)的磁盤結構，它提供了常量時間的性能，即便是存儲海量的信息（TB級）。 2）高吞吐 記住大數據，Kafka的設計是工做在標準硬件之上，支持每秒數百萬的消息。 3）分佈式 Kafka明確支持在Kafka服務器上的消息分區，以及在消費機器集羣上的分發消費，維護每一個分區的排序語義。 4）多客戶端支持 Kafka系統支持與來自不一樣平臺（如java、.NET、PHP、Ruby或Python等）的客戶端相集成。 5）實時 生產者線程產生的消息對消費者線程應該當即可見，此特性對基於事件的系統（好比CEP系統）是相當重要的。

 

2.    概念

Topics/logs

一個Topic能夠認爲是一類消息，每一個topic將被分紅多個partition(區),每一個partition在存儲層面是append log文件。任何發佈到此partition的消息都會被直接追加到log文件的尾部，每條消息在文件中的位置稱爲offset（偏移量），offset爲一個long型數字，它是惟一標記一條消息。它惟一的標記一條消息。kafka並無提供其餘額外的索引機制來存儲offset，由於在kafka中幾乎不容許對消息進行「隨機讀寫」。

    kafka和JMS實現(activeMQ)不一樣的是:即便消息被消費,消息仍然不會被當即刪除.日誌文件將會根據broker中的配置要求,保留必定的時間以後刪除;好比log文件保留2天,那麼兩天後,文件會被清除,不管其中的消息是否被消費.kafka經過這種簡單的手段,來釋放磁盤空間,以及減小消息消費以後對文件內容改動的磁盤IO開支.

 

    對於consumer而言,它須要保存消費消息的offset,對於offset的保存和使用,有consumer來控制;當consumer正常消費消息時,offset將會"線性"的向前驅動,即消息將依次順序被消費.事實上consumer可使用任意順序消費消息,它只須要將offset重置爲任意值..(offset將會保存在zookeeper中,參見下文)

    kafka集羣幾乎不須要維護任何consumer和producer狀態信息,這些信息有zookeeper保存;所以producer和consumer的客戶端實現很是輕量級,它們能夠隨意離開,而不會對集羣形成額外的影響.

    partitions的設計目的有多個.最根本緣由是kafka基於文件存儲.經過分區,能夠將日誌內容分散到多個server上,來避免文件尺寸達到單機磁盤的上限,每一個partiton都會被當前server(kafka實例)保存;能夠將一個topic切分多任意多個partitions,來消息保存/消費的效率.此外越多的partitions意味着能夠容納更多的consumer,有效提高併發消費的能力.(具體原理參見下文).

 

Distribution

一個Topic的多個partitions,被分佈在kafka集羣中的多個server上;每一個server(kafka實例)負責partitions中消息的讀寫操做;此外kafka還能夠配置partitions須要備份的個數(replicas),每一個partition將會被備份到多臺機器上,以提升可用性.

 

    基於replicated方案,那麼就意味着須要對多個備份進行調度;每一個partition都有一個server爲"leader";leader負責全部的讀寫操做,若是leader失效,那麼將會有其餘follower來接管(成爲新的leader);follower只是單調的和leader跟進,同步消息便可..因而可知做爲leader的server承載了所有的請求壓力,所以從集羣的總體考慮,有多少個partitions就意味着有多少個"leader",kafka會將"leader"均衡的分散在每一個實例上,來確保總體的性能穩定.

 

Producers

    Producer將消息發佈到指定的Topic中,同時Producer也能決定將此消息歸屬於哪一個partition;好比基於"round-robin"方式或者經過其餘的一些算法等.

 

Consumers

    本質上kafka只支持Topic.每一個consumer屬於一個consumer group;反過來講,每一個group中能夠有多個consumer.發送到Topic的消息,只會被訂閱此Topic的每一個group中的一個consumer消費.

    若是全部的consumer都具備相同的group,這種狀況和queue模式很像;消息將會在consumers之間負載均衡.

    若是全部的consumer都具備不一樣的group,那這就是"發佈-訂閱";消息將會廣播給全部的消費者.

    在kafka中,一個partition中的消息只會被group中的一個consumer消費;每一個group中consumer消息消費互相獨立;咱們能夠認爲一個group是一個"訂閱"者,一個Topic中的每一個partions,只會被一個"訂閱者"中的一個consumer消費,不過一個consumer能夠消費多個partitions中的消息.kafka只能保證一個partition中的消息被某個consumer消費時,消息是順序的.事實上,從Topic角度來講,消息仍不是有序的.

 

    kafka的設計原理決定,對於一個topic,同一個group中不能有多於partitions個數的consumer同時消費,不然將意味着某些consumer將沒法獲得消息.

 

Guarantees

    1) 發送到partitions中的消息將會按照它接收的順序追加到日誌中

    2) 對於消費者而言,它們消費消息的順序和日誌中消息順序一致.

    3) 若是Topic的"replication factor"爲N,那麼容許N-1個kafka實例失效.

 

 

 

3.    適用場景

1、Messaging

    對於一些常規的消息系統,kafka是個不錯的選擇;partitons/replication和容錯,可使kafka具備良好的擴展性和性能優點.不過到目前爲止,咱們應該很清楚認識到,kafka並無提供JMS中的"事務性""消息傳輸擔保(消息確認機制)""消息分組"等企業級特性;kafka只能使用做爲"常規"的消息系統,在必定程度上,還沒有確保消息的發送與接收絕對可靠(好比,消息重發,消息發送丟失等)

2、Websit activity tracking

    kafka能夠做爲"網站活性跟蹤"的最佳工具;能夠將網頁/用戶操做等信息發送到kafka中.並實時監控,或者離線統計分析等

3、Metrics

         Kafka一般被用於可操做的監控數據。這包括從分佈式應用程序來的聚合統計用來生產集中的運營數據提要。

4、Log Aggregation

    kafka的特性決定它很是適合做爲"日誌收集中心";application能夠將操做日誌"批量""異步"的發送到kafka集羣中,而不是保存在本地或者DB中;kafka能夠批量提交消息/壓縮消息等,這對producer端而言,幾乎感受不到性能的開支.此時consumer端可使hadoop等其餘系統化的存儲和分析系統.

 

4.    命令

1.  啓動Server

Kafka 依賴 ZK 服務

nohup bin/kafka-server-start.sh config/server.properties &

 

2.  建立Topic

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

 

3.  查看命令

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

4.  發送消息

bin/kafka-console-producer.sh --broker-list localhost:9092 --topic page_visits

5.  消費消息

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

6.  多 Broker 方式

 

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

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

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

bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic visits

bin/kafka-console-producer.sh --broker-list localhost:9092 --topic visits

my message test1

my message test2

 

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

 

7.  中止服務

pkill -9 -f config/server.properties

 

 

8.       刪除無用的topic

bin/kafka-run-class.sh kafka.admin.DeleteTopicCommand --topic visits --zookeeper sjxt-hd02:2181,sjxt-hd03:2181,sjxt-hd04:2181

 

beta in 0.8.1

bin/kafka-topics.sh --zookeeper zk_host:port --delete --topic my_topic_name