Producers發佈記錄到集群，集群維護這些記錄並且將記錄分發給Consumers。 在Kafka中，最關鍵的抽象是topic。Producers發佈記錄到一個topic，Consumers訂閱一個或多個topic。Topic是一個分片的寫優先的log。Producers追加記錄到這些logs，C ...
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
