簡介
kafka架構
它的架構包括以下元件：
話題（topic）：是特定類型的消息流。消息是位元組的有效負載（payload），話題是消息的分類名或種子（feed）名。
生産者（producer）：是能夠釋出消息到話題的任何對象。
服務代理（broker）：已釋出的消息儲存在一組伺服器中，它們被稱為代理（broker）或kafka叢集。
消費者（consumer）：可以訂閱一個或多個話題，并從broker拉資料，進而消費這些已釋出的消息。
kafka存儲政策
1）kafka以topic來進行消息管理，每個topic包含多個partition，每個partition對應一個邏輯log，有多個segment組成。
2）每個segment中存儲多條消息（見下圖），消息id由其邏輯位置決定，即從消息id可直接定位到消息的存儲位置，避免id到位置的額外映射。
3）每個part在記憶體中對應一個index，記錄每個segment中的第一條消息偏移。
4）釋出者發到某個topic的消息會被均勻的分布到多個partition上（或根據使用者指定的路由規則進行分布），broker收到釋出消息往對應partition的最後一個segment上添加該消息，當某個segment上的消息條數達到配置值或消息釋出時間超過門檻值時，segment上的消息會被flush到磁盤，隻有flush到磁盤上的消息訂閱者才能訂閱到，segment達到一定的大小後将不會再往該segment寫資料，broker會建立新的segment。
kafka删除政策
1）n天前的删除。
2）保留最近的mgb資料。
kafka broker
與其它消息系統不同，kafka broker是無狀态的。這意味着消費者必須維護已消費的狀态資訊。這些資訊由消費者自己維護，broker完全不管（有offset managerbroker管理）。
從代理删除消息變得很棘手，因為代理并不知道消費者是否已經使用了該消息。kafka創新性地解決了這個問題，它将一個簡單的基于時間的sla應用于保留政策。當消息在代理中超過一定時間後，将會被自動删除。
這種創新設計有很大的好處，消費者可以故意倒回到老的偏移量再次消費資料。這違反了隊列的常見約定，但被證明是許多消費者的基本特征。
以下摘抄自kafka官方文檔：
kafka design
目标
1) 高吞吐量來支援高容量的事件流處理
2) 支援從離線系統加載資料
3) 低延遲的消息系統
持久化
1) 依賴檔案系統，持久化到本地
2) 資料持久化到log
效率
1) 解決”small io problem“：
使用”message set“組合消息。
server使用”chunks of messages“寫到log。
consumer一次擷取大的消息塊。
2）解決”byte copying“：
在producer、broker和consumer之間使用統一的binary message format。
使用系統的pagecache。
使用sendfile傳輸log，避免拷貝。
kafka支援gzip和snappy壓縮協定。
the producer
負載均衡
1）producer可以自定義發送到哪個partition的路由規則。預設路由規則：hash(key)%numpartitions，如果key為null則随機選擇一個partition。
2）自定義路由：如果key是一個user id，可以把同一個user的消息發送到同一個partition，這時consumer就可以從同一個partition讀取同一個user的消息。
異步批量發送
批量發送：配置不多于固定消息數目一起發送并且等待時間小于一個固定延遲的資料。
the consumer
consumer控制消息的讀取。
push vs pull
1)producer push data to broker，consumer pull data from broker
2)consumer pull的優點：consumer自己控制消息的讀取速度和數量。
3)consumer pull的缺點：如果broker沒有資料，則可能要pull多次忙等待，kafka可以配置consumer long pull一直等到有資料。
consumer position
1)大部分消息系統由broker記錄哪些消息被消費了，但kafka不是。
2)kafka由consumer控制消息的消費，consumer甚至可以回到一個old offset的位置再次消費消息。
message delivery semantics
三種：
at most once—messages may be lost but are never redelivered.
at least once—messages are never lost but may be redelivered.
exactly once—this is what people actually want, each message is delivered once and only once.
producer：有個”acks“配置可以控制接收的leader的在什麼情況下就回應producer消息寫入成功。
consumer：
* 讀取消息，寫log，處理消息。如果處理消息失敗，log已經寫入，則無法再次處理失敗的消息，對應”at most once“。
* 讀取消息，處理消息，寫log。如果消息處理成功，寫log失敗，則消息會被處理兩次，對應”at least once“。
* 讀取消息，同時處理消息并把result和log同時寫入。這樣保證result和log同時更新或同時失敗，對應”exactly once“。
kafka預設保證at-least-once delivery，容許使用者實作at-most-once語義，exactly-once的實作取決于目的存儲系統，kafka提供了讀取offset，實作也沒有問題。
複制（replication）
1）一個partition的複制個數（replication factor）包括這個partition的leader本身。
2）所有對partition的讀和寫都通過leader。
3）followers通過pull擷取leader上log（message和offset）
4）如果一個follower挂掉、卡住或者同步太慢，leader會把這個follower從”in sync replicas“（isr）清單中删除。
5）當所有的”in sync replicas“的follower把一個消息寫入到自己的log中時，這個消息才被認為是”committed“的。
6）如果針對某個partition的所有複制節點都挂了，kafka選擇最先複活的那個節點作為leader（這個節點不一定在isr裡）。
日志壓縮（log compaction）
1）針對一個topic的partition，壓縮使得kafka至少知道每個key對應的最後一個值。
2）壓縮不會重排序消息。
3）消息的offset是不會變的。
4）消息的offset是順序的。
distribution
consumer offset tracking
1）high-level consumer記錄每個partition所消費的maximum offset，并定期commit到offset manager（broker）。
2）simple consumer需要手動管理offset。現在的simple consumer java api隻支援commit offset到zookeeper。
consumers and consumer groups
1）consumer注冊到zookeeper
2）屬于同一個group的consumer（group id一樣）平均配置設定partition，每個partition隻會被一個consumer消費。
3）當broker或同一個group的其他consumer的狀态發生變化的時候，consumer rebalance就會發生。
zookeeper協調控制
1）管理broker與consumer的動态加入與離開。
2）觸發負載均衡，當broker或consumer加入或離開時會觸發負載均衡算法，使得一個consumer group内的多個consumer的訂閱負載平衡。
3）維護消費關系及每個partition的消費資訊。
生産者代碼示例：
partitioning code:
消費者代碼示例：
開發環境搭建：
<a href="https://cwiki.apache.org/confluence/display/kafka/developer+setup">https://cwiki.apache.org/confluence/display/kafka/developer+setup</a>
一些example：
<a href="https://cwiki.apache.org/confluence/display/kafka/0.8.0+producer+example">https://cwiki.apache.org/confluence/display/kafka/0.8.0+producer+example</a>
參考：
https://kafka.apache.org/documentation.html
https://cwiki.apache.org/confluence/display/kafka/index
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。
http://www.cnblogs.com/luxiaoxun/p/5492646.html