Kafka的基本介紹 Kafka是最初由Linkedin公司開發(fā)，是一個(gè)分布式、分區(qū)的、多副本的、多訂閱者，基于zookeeper協(xié)調(diào)的分布式日志系統(tǒng)（也可以當(dāng)做MQ系統(tǒng)），常見可以用于web/nginx日志、訪問日志，消息服務(wù)等等，Linkedin于2010年貢獻(xiàn)給了Apache基金會并成為頂級開源項(xiàng)目。 主要應(yīng)用場景是：日志收集系統(tǒng)和消息系統(tǒng)。 Kafka主要設(shè)計(jì)目標(biāo)如下： 以時(shí)間復(fù)雜度為O(1)的方式提供消息持久化能力，即使對TB級以上數(shù)據(jù)也能保證常數(shù)時(shí)間的訪問性能。 高吞吐率。即使在非常廉價(jià)的商用機(jī)器上也能做到單機(jī)支持每秒100K條消息的傳輸。 支持Kafka Server間的消息分區(qū)，及分布式消費(fèi)，同時(shí)保證每個(gè)partition內(nèi)的消息順序傳輸。 同時(shí)支持離線數(shù)據(jù)處理和實(shí)時(shí)數(shù)據(jù)處理。 Kafka的設(shè)計(jì)原理分析

一個(gè)典型的kafka集群中包含若干producer，若干broker，若干consumer，以及一個(gè)Zookeeper集群。Kafka通過Zookeeper管理集群配置，選舉leader，以及在consumer group發(fā)生變化時(shí)進(jìn)行rebalance。producer使用push模式將消息發(fā)布到broker，consumer使用pull模式從broker訂閱并消費(fèi)消息。 　 Kafka專用術(shù)語： Broker：消息中間件處理結(jié)點(diǎn)，一個(gè)Kafka節(jié)點(diǎn)就是一個(gè)broker，多個(gè)broker可以組成一個(gè)Kafka集群。 Topic：一類消息，Kafka集群能夠同時(shí)負(fù)責(zé)多個(gè)topic的分發(fā)。 Partition：topic物理上的分組，一個(gè)topic可以分為多個(gè)partition，每個(gè)partition是一個(gè)有序的隊(duì)列。 Segment：partition物理上由多個(gè)segment組成。 offset：每個(gè)partition都由一系列有序的、不可變的消息組成，這些消息被連續(xù)的追加到partition中。partition中的每個(gè)消息都有一個(gè)連續(xù)的序列號叫做offset，用于partition唯一標(biāo)識一條消息。 Producer：負(fù)責(zé)發(fā)布消息到Kafka broker。 Consumer：消息消費(fèi)者，向Kafka broker讀取消息的客戶端。 Consumer Group：每個(gè)Consumer屬于一個(gè)特定的Consumer Group。 Kafka數(shù)據(jù)傳輸?shù)氖聞?wù)特點(diǎn) at most once：最多一次，這個(gè)和JMS中"非持久化"消息類似，發(fā)送一次，無論成敗，將不會重發(fā)。消費(fèi)者fetch消息，然后保存offset，然后處理消息；當(dāng)client保存offset之后，但是在消息處理過程中出現(xiàn)了異常，導(dǎo)致部分消息未能繼續(xù)處理。那么此后"未處理"的消息將不能被fetch到，這就是"at most once"。 at least once：消息至少發(fā)送一次，如果消息未能接受成功，可能會重發(fā)，直到接收成功。消費(fèi)者fetch消息，然后處理消息，然后保存offset。如果消息處理成功之后，但是在保存offset階段zookeeper異常導(dǎo)致保存操作未能執(zhí)行成功，這就導(dǎo)致接下來再次fetch時(shí)可能獲得上次已經(jīng)處理過的消息，這就是"at least once"，原因offset沒有及時(shí)的提交給zookeeper，zookeeper恢復(fù)正常還是之前offset狀態(tài)。 exactly once：消息只會發(fā)送一次。kafka中并沒有嚴(yán)格的去實(shí)現(xiàn)（基于2階段提交），我們認(rèn)為這種策略在kafka中是沒有必要的。 通常情況下"at-least-once"是我們首選。 Kafka消息存儲格式 Topic & Partition 一個(gè)topic可以認(rèn)為一個(gè)一類消息，每個(gè)topic將被分成多個(gè)partition，每個(gè)partition在存儲層面是append log文件。

在Kafka文件存儲中，同一個(gè)topic下有多個(gè)不同partition，每個(gè)partition為一個(gè)目錄，partiton命名規(guī)則為topic名稱+有序序號，第一個(gè)partiton序號從0開始，序號最大值為partitions數(shù)量減1。

每個(gè)partion（目錄）相當(dāng)于一個(gè)巨型文件被平均分配到多個(gè)大小相等segment（段）數(shù)據(jù)文件中。但每個(gè)段segment file消息數(shù)量不一定相等，這種特性方便old segment file快速被刪除。 每個(gè)partiton只需要支持順序讀寫就行了，segment文件生命周期由服務(wù)端配置參數(shù)決定。 這樣做的好處就是能快速刪除無用文件，有效提高磁盤利用率。 segment file組成：由2大部分組成，分別為index file和data file，此2個(gè)文件一一對應(yīng)，成對出現(xiàn)，后綴".index"和“.log”分別表示為segment索引文件、數(shù)據(jù)文件。 segment文件命名規(guī)則：partion全局的第一個(gè)segment從0開始，后續(xù)每個(gè)segment文件名為上一個(gè)segment文件最后一條消息的offset值。數(shù)值最大為64位long大小，19位數(shù)字字符長度，沒有數(shù)字用0填充。?

segment中index與data file對應(yīng)關(guān)系物理結(jié)構(gòu)如下：

上圖中索引文件存儲大量元數(shù)據(jù)，數(shù)據(jù)文件存儲大量消息，索引文件中元數(shù)據(jù)指向?qū)?yīng)數(shù)據(jù)文件中message的物理偏移地址。 其中以索引文件中元數(shù)據(jù)3,497為例，依次在數(shù)據(jù)文件中表示第3個(gè)message（在全局partiton表示第368772個(gè)message），以及該消息的物理偏移地址為497。 了解到segment data file由許多message組成，下面詳細(xì)說明message物理結(jié)構(gòu)如下：

?

參數(shù)說明：

副本（replication）策略 Kafka的高可靠性的保障來源于其健壯的副本（replication）策略。 1) 數(shù)據(jù)同步 kafka在0.8版本前沒有提供Partition的Replication機(jī)制，一旦Broker宕機(jī)，其上的所有Partition就都無法提供服務(wù)，而Partition又沒有備份數(shù)據(jù)，數(shù)據(jù)的可用性就大大降低了。所以0.8后提供了Replication機(jī)制來保證Broker的failover。 引入Replication之后，同一個(gè)Partition可能會有多個(gè)Replica，而這時(shí)需要在這些Replication之間選出一個(gè)Leader，Producer和Consumer只與這個(gè)Leader交互，其它Replica作為Follower從Leader中復(fù)制數(shù)據(jù)。?

2) 副本放置策略 為了更好的做負(fù)載均衡，Kafka盡量將所有的Partition均勻分配到整個(gè)集群上。Kafka分配Replica的算法如下： 將所有存活的N個(gè)Brokers和待分配的Partition排序 將第i個(gè)Partition分配到第(i mod n)個(gè)Broker上，這個(gè)Partition的第一個(gè)Replica存在于這個(gè)分配的Broker上，并且會作為partition的優(yōu)先副本 將第i個(gè)Partition的第j個(gè)Replica分配到第((i + j) mod n)個(gè)Broker上 假設(shè)集群一共有4個(gè)brokers，一個(gè)topic有4個(gè)partition，每個(gè)Partition有3個(gè)副本。下圖是每個(gè)Broker上的副本分配情況。?

3) 同步策略 Producer在發(fā)布消息到某個(gè)Partition時(shí)，先通過ZooKeeper找到該P(yáng)artition的Leader，然后無論該Topic的Replication Factor為多少，Producer只將該消息發(fā)送到該P(yáng)artition的Leader。Leader會將該消息寫入其本地Log。每個(gè)Follower都從Leader pull數(shù)據(jù)。這種方式上，F(xiàn)ollower存儲的數(shù)據(jù)順序與Leader保持一致。Follower在收到該消息并寫入其Log后，向Leader發(fā)送ACK。一旦Leader收到了ISR中的所有Replica的ACK，該消息就被認(rèn)為已經(jīng)commit了，Leader將增加HW并且向Producer發(fā)送ACK。 為了提高性能，每個(gè)Follower在接收到數(shù)據(jù)后就立馬向Leader發(fā)送ACK，而非等到數(shù)據(jù)寫入Log中。因此，對于已經(jīng)commit的消息，Kafka只能保證它被存于多個(gè)Replica的內(nèi)存中，而不能保證它們被持久化到磁盤中，也就不能完全保證異常發(fā)生后該條消息一定能被Consumer消費(fèi)。 Consumer讀消息也是從Leader讀取，只有被commit過的消息才會暴露給Consumer。