1.png

Apache Kafka 基礎(chǔ)介紹

介紹完RocketMQ，就不得不介紹一下kafka，RocketMQ就是照著kafka寫的java版本，在消息中間件中，kafka性能名列前茅。

官方文檔：

http://kafka.apache.org/intro.html

Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，使用Scala編寫。

對于熟悉JMS（Java Message Service）規(guī)范的同學(xué)來說，消息系統(tǒng)已經(jīng)不是什么新概念了(例如ActiveMQ，RabbitMQ等)。

Kafka擁有作為一個消息系統(tǒng)應(yīng)該具備的功能，但是確有著獨特的設(shè)計。
可以這樣來說，Kafka借鑒了JMS規(guī)范的思想，但是確并沒有完全遵循JMS規(guī)范。

kafka是一個分布式的，分區(qū)的消息(官方稱之為commit log)服務(wù)。它提供一個消息系統(tǒng)應(yīng)該具備的功能，但是確有著獨特的設(shè)計。
首先，讓我們來看一下基礎(chǔ)的消息(Message)相關(guān)術(shù)語：

因此，從一個較高的層面上來看，producers通過網(wǎng)絡(luò)發(fā)送消息到Kafka集群，然后consumers來進(jìn)行消費，如下圖：

2.png

服務(wù)端(brokers)和客戶端(producer、consumer)之間通信通過TCP協(xié)議來完成。官方為Kafka提供了一個Java客戶端，但是也可以使用其他語言編寫的客戶端。

Topic和Log

讓我們首先深入理解Kafka提出一個高層次的抽象概念-Topic。
可以理解Topic是一個類別的名稱，所有的message發(fā)送到Topic下面。對于每一個Topic，kafka集群按照如下方式維護(hù)一個分區(qū)(Partition,可以就理解為一個隊列Queue)日志文件:

3.png

partition是一個有序的message序列，這些message按順序添加到一個叫做commit log的文件中。每個partition中的消息都有一個唯一的編號，稱之為offset，用來唯一標(biāo)示某個分區(qū)中的message。

提示：每個partition，都對應(yīng)一個commit-log。一個partition中的message的offset都是唯一的，但是不同的partition中的message的offset可能是相同的。

kafka集群，在配置的時間范圍內(nèi)，維護(hù)所有的由producer生成的消息，而不管這些消息有沒有被消費。例如日志保留( log retention )時間被設(shè)置為2天。kafka會維護(hù)最近2天生產(chǎn)的所有消息，而2天前的消息會被丟棄。kafka的性能與保留的數(shù)據(jù)量的大小沒有關(guān)系，因此保存大量的數(shù)據(jù)(日志信息)不會有什么影響。

每個consumer是基于自己在commit log中的消費進(jìn)度(offset)來進(jìn)行工作的。

在kafka中，offset由consumer來維護(hù)：一般情況下我們按照順序逐條消費commit log中的消息，當(dāng)然我可以通過指定offset來重復(fù)消費某些消息，或者跳過某些消息。

這意味kafka中的consumer對集群的影響是非常小的，添加一個或者減少一個consumer，對于集群或者其他consumer來說，都是沒有影響的，因此每個consumer維護(hù)各自的offset。
對log進(jìn)行分區(qū)（partitioned），有以下目的：

首先，當(dāng)log文件大小超過系統(tǒng)文件系統(tǒng)的限制時，可以自動拆分。

每個partition對應(yīng)的log都受到所在機(jī)器的文件系統(tǒng)大小的限制，但是一個Topic中是可以有很多分區(qū)的，因此可以處理任意數(shù)量的數(shù)據(jù)。

另一個方面，是為了提高并行度。

Distribution

log的partitions分布在kafka集群中不同的broker上，每個broker可以請求備份其他broker上partition上的數(shù)據(jù)。kafka集群支持配置一個partition備份的數(shù)量。

針對每個partition，都有一個broker起到“l(fā)eader”的作用，0個多個其他的broker作為“follwers”的作用。

leader處理所有的針對這個partition的讀寫請求，而followers被動復(fù)制leader的結(jié)果。

如果這個leader失效了，其中的一個follower將會自動的變成新的leader。

每個broker都是自己所管理的partition的leader，
同時又是其他broker所管理partitions的followers，kafka通過這種方式來達(dá)到負(fù)載均衡。

Producers

生產(chǎn)者將消息發(fā)送到topic中去，同時負(fù)責(zé)選擇將message發(fā)送到topic的哪一個partition中。通過round-robin做簡單的負(fù)載均衡，也可以根據(jù)消息中的某一個關(guān)鍵字來進(jìn)行區(qū)分。通常第二種方式使用的更多。

Consumers

傳統(tǒng)的消息傳遞模式有2種：隊列( queuing)和（ publish-subscribe）。

在queuing模式中，多個consumer從服務(wù)器中讀取數(shù)據(jù)，消息只會到達(dá)一個consumer。

在 publish-subscribe 模型中，消息會被廣播給所有的consumer。Kafka基于這2種模式提供了一種consumer的抽象概念：consumer group。

每個consumer都要標(biāo)記自己屬于哪一個consumer group。

發(fā)布到topic中的message中message會被傳遞到consumer group中的一個consumer 實例。

consumer實例可以運行在不同的進(jìn)程上，也可以在不同的物理機(jī)器上。

如果所有的consumer都位于同一個consumer group 下，這就類似于傳統(tǒng)的queue模式，并在眾多的consumer instance之間進(jìn)行負(fù)載均衡。

如果所有的consumer都有著自己唯一的consumer group，這就類似于傳統(tǒng)的publish-subscribe模型。

更一般的情況是，通常一個topic會有幾個consumer group，每個consumer group都是一個邏輯上的訂閱者（ logical subscriber ）。每個consumer group由多個consumer instance組成，從而達(dá)到可擴(kuò)展和容災(zāi)的功能。

這并沒有什么特殊的地方，僅僅是將publish-subscribe模型中的運行在單個進(jìn)程上的consumers中的consumer替換成一個consumer group。如下圖所示：

4.png

說明：由2個broker組成的kafka集群，總共有4個Parition(P0-P3)。這個集群由2個Consumer Group， A有2個 consumer instances ，而B有四個。

消費順序

Kafka比傳統(tǒng)的消息系統(tǒng)有著更強(qiáng)的順序保證。

在傳統(tǒng)的情況下，服務(wù)器按照順序保留消息到隊列，如果有多個consumer來消費隊列中的消息，服務(wù)器 會接受消息的順序向外提供消息。

但是，盡管服務(wù)器是按照順序提供消息，但是消息傳遞到每一個consumer是異步的，這可能會導(dǎo)致先消費的 consumer獲取到消息時間可能比后消費的consumer獲取到消息的時間長，導(dǎo)致不能保證順序性。

這表明，當(dāng)進(jìn)行并行的消費的時候，消息在多個 consumer之間可能會失去順序性。

消息系統(tǒng)通常會采取一種“ exclusive consumer”的概念，來確保同一時間內(nèi)只有一個consumer能夠從隊列中進(jìn)行消費，但是這實際上意味著在消息處理的過程中是不支持并行的。

Kafka在這方面做的更好。通過Topic中并行度的概念，即partition，Kafka可以同時提供順序性保證和多個consumer同時消費時的負(fù)載均衡。

實現(xiàn)的原理是通過將一個topic中的partition分配給一個consumer group中的不同consumer instance。通過這種方式，我們可以保證一個partition在同一個時刻只有一個consumer instance在消息，從而保證順序。

雖然一個topic中有多個partition，但是一個consumer group中同時也有多個consumer instance，通過合理的分配依然能夠保證負(fù)載均衡。

需要注意的是，一個consumer group中的consumer instance的數(shù)量不能比一個Topic中的partition的數(shù)量多。

Kafka只在partition的范圍內(nèi)保證消息消費的局部順序性，不能在同一個topic中的多個partition中保證總的消費順序性。

通常來說，這已經(jīng)可以滿足大部分應(yīng)用的需求。

但是，如果的確有在總體上保證消費的順序的需求的話，那么我們可以通過將topic的partition數(shù)量設(shè)置為1，將consumer group中的consumer instance數(shù)量也設(shè)置為1。

Guarantees

從較高的層面上來說的話，Kafka提供了以下的保證：

發(fā)送到一個Topic中的message會按照發(fā)送的順序添加到commit log中。

意思是，如果消息 M1，M2由同一個producer發(fā)送，M1比M2發(fā)送的早的話，那么在commit log中，M1的offset就會比commit 2的offset小。

一個consumer在commit log中可以按照發(fā)送順序來消費message
如果一個topic的備份因子( replication factor )設(shè)置為N，那么Kafka可以容忍N-1個服務(wù)器的失敗，而存儲在commit log中的消息不會丟失。

更多介紹請查看官網(wǎng)文檔：http://kafka.apache.org/intro.html

kafka基礎(chǔ)介紹完成：）。