Kafka簡介
Kafka是一種高吞吐量的分佈式發佈訂閱消息系統，使用Scala編寫。
對於熟悉JMS（Java Message Service）規範的同學來說，消息系統已經不是什麼新概念了(例如ActiveMQ，RabbitMQ等)。
Kafka擁有作為一個消息系統應該具備的功能，但是確有著獨特的設計。可以這樣來說，Kafka借鑑了JMS規範的思想，但是卻並沒有完全遵循JMS規範。
kafka是一個分佈式的，分區的消息(官方稱之為commit log)服務。它提供一個消息系統應該具備的功能，但是確有著獨特的設計。
首先，讓我們來看一下基礎的消息(Message)相關術語：
Topic: Kafka按照Topic分類來維護消息
Producer： 我們將發佈(publish)消息到Topic的進程稱之為生產者(producer)
Consumer： 我們將訂閱(subscribe)Topic並且處理Topic中消息的進程稱之為消費者(consumer)
Broker： Kafka以集群的方式運行，集群中的每一臺服務器稱之為一個代理(broker)。
因此，從一個較高的層面上來看，producers通過網絡發送消息到Kafka集群，然後consumers來進行消費，如下圖：
服務端(brokers)和客戶端(producer、consumer)之間通信通過TCP協議來完成。我們為Kafka提供了一個Java客戶端，但是也可以使用其他語言編寫的客戶端。
Topic和Log
讓我們首先深入理解Kafka提出一個高層次的抽象概念-Topic。
可以理解Topic是一個類別的名稱，所有的message發送到Topic下面。對於每一個Topic，kafka集群按照如下方式維護一個分區(Partition,可以就理解為一個隊列Queue)日誌文件:
partition是一個有序的message序列，這些message按順序添加到一個叫做commit log的文件中。每個partition中的消息都有一個唯一的編號，稱之為offset，用來唯一標示某個分區中的message。
提示：每個partition，都對應一個commit-log。一個partition中的message的offset都是唯一的，但是不同的partition中的message的offset可能是相同的。
kafka集群，在配置的時間範圍內，維護所有的由producer生成的消息，而不管這些消息有沒有被消費。例如日誌保留( log retention )時間被設置為2天。kafka會維護最近2天生產的所有消息，而2天前的消息會被丟棄。kafka的性能與保留的數據量的大小沒有關係，因此保存大量的數據(日誌信息)不會有什麼影響。
每個consumer是基於自己在commit log中的消費進度(offset)來進行工作的。在kafka中，offset由consumer來維護：一般情況下我們按照順序逐條消費commit log中的消息，當然我可以通過指定offset來重複消費某些消息，或者跳過某些消息。
這意味kafka中的consumer對集群的影響是非常小的，添加一個或者減少一個consumer，對於集群或者其他consumer來說，都是沒有影響的，因此每個consumer維護各自的offset。
對log進行分區（partitioned），有以下目的。首先，當log文件大小超過系統文件系統的限制時，可以自動拆分。每個partition對應的log都受到所在機器的文件系統大小的限制，但是一個Topic中是可以有很多分區的，因此可以處理任意數量的數據。另一個方面，是為了提高並行度。
Distribution
log的partitions分佈在kafka集群中不同的broker上，每個broker可以請求備份其他broker上partition上的數據。kafka集群支持配置一個partition備份的數量。
針對每個partition，都有一個broker起到“leader”的作用，0個多個其他的broker作為“follwers”的作用。leader處理所有的針對這個partition的讀寫請求，而followers被動複製leader的結果。如果這個leader失效了，其中的一個follower將會自動的變成新的leader。每個broker都是自己所管理的partition的leader，同時又是其他broker所管理partitions的followers，kafka通過這種方式來達到負載均衡。
Producers
生產者將消息發送到topic中去，同時負責選擇將message發送到topic的哪一個partition中。通過round-robin做簡單的負載均衡。也可以根據消息中的某一個關鍵字來進行區分。通常第二種方式使用的更多。
Consumers
傳統的消息傳遞模式有2種：隊列( queuing)和（ publish-subscribe）。
在queuing模式中，多個consumer從服務器中讀取數據，消息只會到達一個consumer。在 publish-subscribe 模型中，消息會被廣播給所有的consumer。Kafka基於這2種模式提供了一種consumer的抽象概念：consumer group。
每個consumer都要標記自己屬於哪一個consumer group。發佈到topic中的message中message會被傳遞到consumer group中的一個consumer 實例。consumer實例可以運行在不同的進程上，也可以在不同的物理機器上。
如果所有的consumer都位於同一個consumer group 下，這就類似於傳統的queue模式，並在眾多的consumer instance之間進行負載均衡。
如果所有的consumer都有著自己唯一的consumer group，這就類似於傳統的publish-subscribe模型。
更一般的情況是，通常一個topic會有幾個consumer group，每個consumer group都是一個邏輯上的訂閱者（ logical subscriber ）。每個consumer group由多個consumer instance組成，從而達到可擴展和容災的功能。這並沒有什麼特殊的地方，僅僅是將publish-subscribe模型中的運行在單個進程上的consumers中的consumer替換成一個consumer group。如下圖所示：
說明：由2個broker組成的kafka集群，總共有4個Parition(P0-P3)。這個集群由2個Consumer Group， A有2個 consumer instances ，而B有四個.
消費順序
Kafka比傳統的消息系統有著更強的順序保證。在傳統的情況下，服務器按照順序保留消息到隊列，如果有多個consumer來消費隊列中的消息，服務器 會接受消息的順序向外提供消息。但是，儘管服務器是按照順序提供消息，但是消息傳遞到每一個consumer是異步的，這可能會導致先消費的 consumer獲取到消息時間可能比後消費的consumer獲取到消息的時間長，導致不能保證順序性。這表明，當進行並行的消費的時候，消息在多個 consumer之間可能會失去順序性。消息系統通常會採取一種“ exclusive consumer”的概念，來確保同一時間內只有一個consumer能夠從隊列中進行消費，但是這實際上意味著在消息處理的過程中是不支持並行的。
Kafka在這方面做的更好。通過Topic中並行度的概念，即partition，Kafka可以同時提供順序性保證和多個consumer同時消費時的負載均衡。實現的原理是通過將一個topic中的partition分配給一個consumer group中的不同consumer instance。通過這種方式，我們可以保證一個partition在同一個時刻只有一個consumer instance在消息，從而保證順序。雖然一個topic中有多個partition，但是一個consumer group中同時也有多個consumer instance，通過合理的分配依然能夠保證負載均衡。需要注意的是，一個consumer group中的consumer instance的數量不能比一個Topic中的partition的數量多。
Kafka只在partition的範圍內保證消息消費的局部順序性，不能在同一個topic中的多個partition中保證總的消費順序性。通常來說，這已經可以滿足大部分應用的需求。但是，如果的確有在總體上保證消費的順序的需求的話，那麼我們可以通過將topic的partition數量設置為1，將consumer group中的consumer instance數量也設置為1.
Guarantees
從較高的層面上來說的話，Kafka提供了以下的保證：
發送到一個Topic中的message會按照發送的順序添加到commit log中。意思是，如果消息 M1，M2由同一個producer發送，M1比M2發送的早的話，那麼在commit log中，M1的offset就會比commit 2的offset小。
一個consumer在commit log中可以按照發送順序來消費message
如果一個topic的備份因子( replication factor )設置為N，那麼Kafka可以容忍N-1個服務器的失敗，而存儲在commit log中的消息不會丟失。
閱讀更多 進擊吧程序猿 的文章
