背景:

1. kafka是一個分布式、高吞吐率的消息系統

---- 早期版本

---- 重點在日志處理

2. kafka是一個分布式、流式平臺

---- 0.10

---- 天然支持stream處理

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

名詞解釋 

1. producer
2. broker(中間人)，依賴ZK，存儲一些元信息 + 領導選舉之類的
3. consumer
4. 細分
   1. Record（每一條數據）
      1. key-value
      2. timestmap
   2. Topic（一個消息類別）
      1. 邏輯概念
      2. 發布-訂閱基于topic
   3. Partition（分布在不同的broker中）
      1. 物理概念
      2. 一個Topic包含多個partition
      3. 每個partition物理上對應一個文件夾
   4. Segment
      1. 是文件，一個partition下的多個文件
   5. Consumer group
      1. 就是指定N:M，N個consumer消費M個partition

關鍵點

1. consumer使用pull機制而不用push機制（GO語言的NS-queue采用push），原因可以防止producer產生數據太快，但是consumer消費不過來一直積壓
   1. broker里面的數據是持久化的，consumer處理慢不會影響數據丟失
   2. pull方式會比push方式慢一點，因為不會一直pull數據，中間有一個時間間隔，或者使用long pulling也行但是還是沒push高
2. producer需要使用SDK發送數據，SDK有內部數據隊列，會有丟棄數據風險(可以用立馬flush，變成同步模型)
3. 寫數據（append only），順序寫
4. 什么時候刪數據？只需要刪除最老的segment即可
5. 默認SDK發送會有多條TCP鏈接，這樣會導致發送順序亂掉，解決方法是設置TCP連接數為1
6. consumer group是如何reblance的？（集中式rebalance）
   1. coordinator決定
7. ISR復制模式 (In Sync Replace，每次都是一批一批數據過來的)
   1. 發送數據去partition的leader
   2. follower有兩個容忍
      1. 接受K條消息落后，超過踢掉（舊版本）
      2. 接受K秒消息落后，超過踢掉
   3. 假如leader掛了，就會在ISR里面宿便選一個
8. 如何實現exactly once
   1. 兩階段提交
   2. 冪等接口
   3. offset和數據庫放在同一個事務