六個核心角色

product 生產者(資料提供者)

    topic 訊息類別(每條由product釋出到kafka的訊息都有一個**topic**,不同的topic訊息分開儲存)
    **partition **分割槽 物理概念(每個topic都至少有一個或很多個partition)
    **broker **伺服器(kafka叢集的一個節點)
    **consumer **group 消費者組別
    **consumer **消費者

角色理解

topic&partition
可以吧topic理解陳一個先進先出的傳送帶(queue佇列),你需要在釋出訊息到卡夫卡的時候確定你需要吧你的訊息釋出的哪個佇列中
partition是為了提高卡夫卡的吞吐率,每個topic都會有若干個portion,每個partition 代表著一個物理環境下的資料夾,資料夾裡面儲存著改partition的所有訊息和對應的索引

product
訊息生產者吧訊息push到卡夫卡的時候,會根據制定好的partition規則吧訊息儲存到對應的partition 中,這樣就實現了負載均衡,同時也提高了IO效能

consumer group
消費者小組要和訊息的消費方式結合理解:
同一個topic的同一條訊息只能被同一個consumer group 的一個consumer消費
多個consumer group 能夠同是消費同一條訊息
這樣就可以實現一個廣播模式或者獨播模式
獨播: 把所有的consumer放入到同一個consumer group裡面,那me該條訊息只能被一個consumer消費

              **廣播**: 把每一個consumer都建立一個獨立的consumer group,那麼所有的consumer都可以消費到這條訊息

交易保證(訊息傳輸和接收方案)

方案
At most once 訊息可能會丟，但絕不會重複傳輸
At least one 訊息絕不會丟，但可能會重複傳輸
Exactly once 每條訊息肯定會被傳輸一次且僅傳輸一次，很多時候這是使用者所想要的。
上游(product->broker)
當Producer向broker傳送訊息時，一旦這條訊息被commit，因數replication的存在，它就不會丟。但是如果Producer傳送資料給broker後，遇到網路問題而造成通訊中斷，那Producer就無法判斷該條訊息是否已經commit。雖然Kafka無法確定網路故障期間發生了什麼，但是Producer可以生成一種類似於主鍵的東西，發生故障時冪等性的重試多次，這樣就做到了Exactly once。截止到目前(Kafka 0.8.2版本，2015-03-04)，這一Feature還並未實現，有希望在Kafka未來的版本中實現。（所以目前預設情況下一條訊息從Producer到broker是確保了At least once，可通過設定Producer非同步傳送實現At most once）。
下游(broker->consumer)
consumer讀取到broker的訊息的時候可以有兩種選擇
直接commit,通知卡夫卡處理完成,然後繼續業務邏輯,這樣的好處是不會多次傳輸,但是資料會丟失,因為有可能在邏輯處理的時候出現crash,那麼這條訊息就會miss
處理完業務邏輯後再commit,這樣資料不會丟失,但是有可能會出現多次重複,因為,如果在業務處理完成,commit之前出現crash,那麼下一次去讀取的時候還是會去讀取該條訊息,再次消費,就會出現重複消費的情況

如果一定要做到Exactly once，就需要協調offset和實際操作的輸出。精典的做法是引入兩階段提交。如果能讓offset和操作輸入存在同一個地方，會更簡潔和通用。這種方式可能更好，因為許多輸出系統可能不支援兩階段提交。比如，Consumer拿到資料後可能把資料放到HDFS，如果把最新的offset和資料本身一起寫到HDFS，那就可以保證資料的輸出和offset的更新要麼都完成，要麼都不完成，間接實現Exactly once。（目前就high level API而言，offset是存於Zookeeper中的，無法存於HDFS(分散式檔案系統)，而low level API的offset是由自己去維護的，可以將之存於HDFS中）

訊息地址問題

釋出訊息和消費訊息都需要知道訊息需要放到哪裡,需要知道訊息在哪
釋出訊息的時候,需要把訊息放入到partition中,這個partition有一個地址引數offset(set->不可重複)

          卡夫卡的訊息無論是否已經消費,是不會進行刪除的

consumer消費訊息是根據offset去消費的,理論是每次消費過後都會遞增該consumer持有的offset,也就是可以消費下一條訊息
故此我們可以把consumer持有的offset值改小來再次消費某些訊息,如果你需要的話

更多關於卡夫卡是如何儲存訊息的,檢視該博文