Producers釋出記錄到叢集，叢集維護這些記錄並且將記錄分發給Consumers。
在Kafka中，最關鍵的抽象是topic。Producers釋出記錄到一個topic，Consumers訂閱一個或多個topic。Topic是一個分片的寫優先的log。Producers追加記錄到這些logs，Consumers訂閱logs的改變。每條記錄都是一個key/value對。根據key來指定記錄到哪個日誌分割槽（除非釋出者直接指定分割槽）。
下面是一個簡單的例子，在這個例子中，有一個生產者和一個消費者，它們讀寫一個有兩個分割槽的topic：
這張圖顯示了一個生產者程式追加記錄到兩個分割槽日誌。日誌中的每條記錄有有一個offset。Consumer用這個offset來描述它在每個日誌中的位置。
Partitions是分佈在叢集的機器之上的。（PS：一堆機器組成一個叢集，叢集之上是topic，而topic是由多個partitions組成）
不想其它的訊息系統那樣，Kafka的log總是持久化的。訊息在到達kafka的時候立刻被寫到檔案系統。訊息被消費以後不會被刪除，至於保留多長時間取決於配置。這使得kafka能夠支援高效的釋出訂閱，因為不管有多少消費者它們都共享一個log。
為了容錯，kafka也複製logs到多個伺服器。
當Producers釋出一個訊息的時候，它會得到一個確認，這個確認中包含了這條記錄的offset。第一個被髮布到分割槽的記錄的offset是0，第二條記錄是1，以此遞增。Consumers從指定offset處開始消費，並且定期儲存它們的位置在log中：儲存這個offset是為了以防萬一消費者例項崩潰了，另一個例項可以繼續從這個位置開始消費。
Replication
Kafka根據配置的伺服器數量來複制每個分割槽的日誌。預設情況下，kafka是開啟複製的，事實上，未複製的主題和複製的主題是一樣的，只不過它們的複製因子是1。
複製是以分割槽為單位的（The unit of replication is the topic partition）。Kafka中，每個分割槽都有一個leader和0個或多個followers。副本的總數量包括leader。所有的讀和寫都指向分割槽的leader。通常，分割槽的數量比broker要多，而且分割槽分佈在broker中。
Followers就像正常的kafka消費者那樣從leader那裡消費訊息，並且把它們應用到自己的log中。
想大多數分散式系統自動處理失敗那樣，關於一個節點"alive"需要有一個明確的定義，kafka中結點存活有兩個條件：
1、一個節點必須能夠在Zookeeper上維護它自己的會話（通過Zookeeper的心跳機制）
2、如果這個節點是一個slave，那麼它必須複製leader上傳送的寫操作，而且不能落後太多
為了避免同"alive"和"fail"混淆，我們把滿足這兩個條件的結點狀態稱之為"in sync"。leader維持對"in sync"結點的跟蹤。如果一個follower死了，或者卡了，或者失敗了，leader會將其從同步副本列表中刪除。
我們現在可以更明確的定義，當這個分割槽的所有in sync副本都應用了這個log時一個訊息才能算是提交完成。只有提交完成的訊息才能分發給消費者。這就意味著消費者不需要擔心會看到一個可能丟失的訊息。另一方面，生產者有一些選項可以控制到底是等待這個訊息提交完成還是不等待，當然這取決於它們在持久化和延遲之間的這種的效能。這個效能有生產者的acks設定來控制。注意，topic關於in-sync副本有一個設定叫"minimum number"，當生產者請求一個已經被寫到所有in-sync副本上的訊息的確認的時候會檢查這個設定。如果生產者確認請求不那麼嚴格，那麼這個訊息仍然可以被提交，被消費，即使in-sync副本的數量比minimum小。
Kafka保證在任何時候，只有有一個in sync副本還活著，已經提交的訊息就不會丟失。
We can now more precisely define that a message is considered committed when all in sync replicas for that partition have applied it to their log. Only committed messages are ever given out to the consumer. This means that the consumer need not worry about potentially seeing a message that could be lost if the leader fails. Producers, on the other hand, have the option of either waiting for the message to be committed or not, depending on their preference for tradeoff between latency and durability. This preference is controlled by the acks setting that the producer uses. Note that topics have a setting for the "minimum number" of in-sync replicas that is checked when the producer requests acknowledgment that a message has been written to the full set of in-sync replicas. If a less stringent acknowledgement is requested by the producer, then the message can be committed, and consumed, even if the number of in-sync replicas is lower than the minimum (e.g. it can be as low as just the leader).
The guarantee that Kafka offers is that a committed message will not be lost, as long as there is at least one in sync replica alive, at all times.
參考
http://kafka.apache.org/documentation/#design
https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines