轉載自：http://blog.csdn.net/gongxinju/article/details/72622204

1.1、什麼是kafka？

Kafka是由linkedin開發的一個分散式的(釋出-訂閱)訊息系統，使用Scala編寫，它以可水平擴充套件和高吞吐率而被廣泛使用。 

1.2、Kafka建立背景

當今社會各種應用系統諸如商業、社交、搜尋、瀏覽等像資訊工廠一樣不斷的生產出各種資訊，在大資料時代，我們面臨如下幾個挑戰：

• 如何收集這些巨大的資訊

• 如何分析它

如何及時做到如上兩點 
以上幾個挑戰形成了一個業務需求模型，即生產者生產（produce）各種資訊，消費者消費（consume）（處理分析）這些資訊，而在生產者與消費者之間，需要一個溝通兩者的橋樑-訊息系統。從一個微觀層面來說，這種需求也可理解為不同的系統之間如何傳遞訊息。 

1.3、使用場景

一、Message 
對於一些常規的訊息系統，kafka是個不錯的選擇；partions/replication和容錯，可以是kafka具有良好的擴充套件性和效能優勢。不過和JMS比，沒有“事務性”“訊息確認機制”，”訊息分組”等企業級特性。

二、Websit 
kafka可以作為”網站活性跟蹤”的最佳工具；可以將網頁/使用者操作資訊傳送到kafka中。

三、Log Aggregation 
kafka的特性決定它非常適合作為”日誌收集”，app可以將操作日誌傳送到kafka叢集中，而不是儲存在本地或者DB中。consumer端可以儲存和分析日誌。

1.4、kafka主要設計目標

以時間複雜度為O(1)的方式提供訊息持久化能力，即使對TB級以上資料也能保證常數時間的訪問效能高吞吐率。即使在非常廉價的商用機器上也能做到單機支援每秒100K條訊息的傳輸支援Kafka Server間的訊息分割槽，及分散式消費，同時保證每個partition內的訊息順序傳輸同時支援離線資料處理和實時資料處理。

1.5、為何要用訊息佇列 (kafka)

冗餘 
有些情況下，處理資料的過程會失敗。除非資料被持久化，否則將造成丟失。訊息佇列把資料進行持久化直到它們已經被完全處理，通過這一方式規避了資料丟失風險。在被許多訊息佇列所採用的”插入-獲取-刪除”正規化中，在把一個訊息從佇列中刪除之前，需要你的處理過程明確的指出該訊息已經被處理完畢，確保你的資料被安全的儲存直到你使用完畢。

靈活性 & 峰值處理能力 
在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量並不常見；如果為以能處理這類峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用訊息佇列能夠使關鍵元件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全崩潰。

可恢復性 
當體系的一部分元件失效，不會影響到整個系統。訊息佇列降低了程序間的耦合度，所以即使一個處理訊息的程序掛掉，加入佇列中的訊息仍然可以在系統恢復後被處理。而這種允許重試或者延後處理請求的能力通常是造就一個略感不便的使用者和一個沮喪透頂的使用者之間的區別。

送達保證 
訊息佇列提供的冗餘機制保證了訊息能被實際的處理，只要一個程序讀取了該佇列即可。在此基礎上，IronMQ提供了一個”只送達一次”保證。無論有多少程序在從佇列中領取資料，每一個訊息只能被處理一次。這之所以成為可能，是因為獲取一個訊息只是”預定”了這個訊息，暫時把它移出了佇列。除非客戶端明確的表示已經處理完了這個訊息，否則這個訊息會被放回佇列中去，在一段可配置的時間之後可再次被處理。

順序保證 
在大多使用場景下，資料處理的順序都很重要。訊息佇列本來就是排序的，並且能保證資料會按照特定的順序來處理。IronMO保證訊息通過FIFO（先進先出）的順序來處理，因此訊息在佇列中的位置就是從佇列中檢索他們的位置

非同步通訊 
很多時候，你不想也不需要立即處理訊息。訊息佇列提供了非同步處理機制，允許你把一個訊息放入佇列，但並不立即處理它。你想向佇列中放入多少訊息就放多少，然後在你樂意的時候再去處理它們。

1.6、訊息佇列對比-ActiveMQ、RabbitMQ、Kafka

ActiveMQ 
重量級的老牌兒MQ，誕生自Java生態，功能完備，相關的介紹很多，這裡不再贅述。

RabbitMQ 
同樣是老牌兒MQ，基於erlang實現，語言無關，功能完備，誕生自金融領域。

Kafka 
MQ中的後起之秀，在很多場景下都超越了前輩，誕生自Hadoop生態，在大資料的支援方面，目前無人能出其右。

橫向對比 

1.7、Kafka元件、術語

一、Topics/logs 
一個Topic可以認為是一類訊息，每個topic將被分成多個partition(區)，每個partition在儲存層面是append log檔案。任何釋出到此partition的訊息都會被直接追加到log檔案的尾部，每條訊息在檔案中的位置稱為offset(偏移量)，offset為一個long整型數字，它是唯一標記一條訊息。Kafka並沒有提供其他額外的索引機制來儲存offset，因為在kafka中幾乎不允許對訊息進行“隨機讀寫”。

在kafka中，即使訊息被消費，訊息仍然不會被立即刪除。日誌檔案將會根據broker中的配置要求，保留一定的時間之後刪除；比如log檔案保留2天，那麼兩天後，檔案會被清除，無論其中的訊息是否被消費。Kafka通過這種簡單的手段，來釋放磁碟空間，以及減少訊息消費之後對檔案內容改動的磁碟IO開支。

對於consumer而言，它需要儲存消費訊息的offset，對於offset的儲存和使用，由consumer來控制；當consumer正常消費訊息時，offset將會“線性”的向前驅動，即訊息將依次順序被消費。事實上consumer可以使用任意順序消費訊息，它只需要將offset重置為任意值，Offset儲存在zookeeper中。

Kafka叢集幾乎不需要維護任何consumer和producer狀態訊息，這些資訊由zookeeper儲存；因此producer和consumer的客戶端實現非常輕量級，它們可以隨意離開，而不會對叢集造成額外的影響。 
Partitions的設計目的有多個。最根本原因是kafka基於檔案儲存。通過分割槽，可以將日誌內容分散到多個server上，來避免檔案尺寸達到單機磁碟的上限， 
每個partitions都會被當前server儲存；可以將一個topic切分多任意多個partitions來儲存訊息。此外越多的partitions意味著可以容納更多的consumer，有效提升併發消費的能力。

二、Distribution–partitions 
一個topic的多個partitions，被分佈在kafka叢集中的多個server上，每個server負責partitions中訊息的 讀寫操作；此外kafka還可以配置partitions需要備份的個數(replicas)，每個partition將會被備份到多臺機器上，以提高可用性。

基於replicated方案，那麼就意味著需要對多個備份進行排程，每個partition都有一個server為“leader”；leader負責所有的讀寫操作，如果leader失效，那麼將會有其他follower來接管(成為新的leader)；follower只是單調的和leader跟進，同步訊息即可。由此可見作為leader的server承載了全部的請求壓力，因此從叢集的整體考慮，有多少個partitions就意味著有多少個“leader”，kafka會將“leader”均衡的分散在每個例項上，來確保整體的效能穩定。

• 傳送到partitions中的訊息將會按照它接收的順序追加到日誌中。
• 對於消費者而言，它們消費訊息的順序和日誌順序一致。
• 如果topic的“replication factor”為n，那麼允許n-1個kafka例項失效。

三、Producers 
Producer將訊息釋出到指定的topic中，同時producer也能決定將此訊息歸屬哪個partition；比如基於“round-robin”方式或者通過其他的一些演算法等。

四、consumers 
每個consumser屬於一個consumer group;反過來說，每個group中可以有多個consumer。傳送到Topic的訊息，只會被訂閱此Topic的每個group中的一個consumer消費。 
如果所有的consumer都有不同的group，那這就是“釋出-訂閱”，訊息將會廣播給所有的消費者。 
在kafka中，一個partition中的訊息只會被group中的一個consumer消費；每個group中的consumer訊息消費相互獨立；我們可以認為一個group是一個“訂閱”者，一個Topic中的每個partions，只會被一個“訂閱者”中的一個consumer消費，不過一個consumer可以消費多個partitions中的訊息。kafka只能保證一個partition中的訊息被某個consumer消費時，訊息是順序的。事實上，從Topic角度來說，訊息仍不是有序的。 
kafka的設計原理決定，對於一個topic，同一個group中不能有多於partitions個數的consumer同時消費，否則將意味著某些consumer將無法得到消費。 

五、Leader 
Partition中負責訊息讀寫的節點;Leader是從Partition的節點中隨機選取的。每個Partition都會在集中的其中一臺伺服器存在Leader。一個Topic如果有多個Partition，則會有多個Leader。

六、ReplicationFactor 
一個Partition中複製資料的所有節點,包括已經掛了的；數量不會超過叢集中broker的數量

七、isr 
ReplicationFactor的子集,存活的且和Leader保持同步的節點;