官方文件：http://kafka.apache.org/documentation/

簡介

多租戶

保證：

　　同一個partition內的順序性；

　　consumer能夠按序看到日誌檔案中的記錄；

　　對於副本因子為N的topic，即使N-1個伺服器宕機，已經提交到日誌的記錄能夠不被丟失。

用作訊息系統：

　　簡化了傳統訊息系統的兩種概念：queuing publish-subscribe

　　將topic中的每一個partition分配給組裡的一個consumer，能夠保證同一個partition中的訊息被順序消費。

用作儲存系統：

　　只有資料被完全備份並且保證已經持久化了，資料的寫入才被認為成功。

流處理：

用例

Messages

better throughput, built-in partitioning, replication, and fault-tolerance，其他訊息佇列：

Website Activity Tracking

日誌聚合

流處理

其他流處理平臺：Storm，Samza

Metrics

Commit Log

配置

broker

topic

producer

consumer

connect

設計

持久化

pagecache-centric design

常量的時間複雜度

效能

Producer

LB：

　　producer直接將資料傳送給對應的partition；

　　所有的kafka伺服器可以在給定的時間內迴應哪一個伺服器是儲存的並且topic的partition leader在哪裡；

　　客戶端控制將資料寫入到哪一個partition；kafka留了一個指定key的介面，kafka將對該key作hash（hash函式也是可以自定義的）從而確定partition。

非同步傳送：

　　批量傳送可以配置為不超過固定數量的message或者等到不超過一些固定的延遲限制(比如說64k，10ms)；

　　這種緩衝是可以配置的，並且提供了一種來通過少量的延遲來提高吞吐量的機制。

Consumer

push vs pull

　　kafka採用的是傳統的資料由producer推送給broker，然後由consumer從broker拉去的機制；Scribe及flume採用的pushed機制，這樣consumer就比較難處理資訊，因為它無法控制broker向他推送資料的頻率，相反kafka在這方面就顯得更加可控些；

　　拉式系統有一個問題是如果broker沒有資料，consumer會一直空轉忙等待至有資料到達；

consumer position

　　常規的訊息系統是由broker記錄哪些訊息被消費，確定哪些訊息被消費後，將之刪除這能使資料量變小，但會帶來一些其他問題：如果訊息被髮送後沒有被正確消費，一直收不到消費成功的確認等，給每條資料記錄狀態的效能問題等等；

　　kafka將topic分為多個有序的partition，對於每一個partition而言，consumer的position僅僅是一個整數；另外，訊息可以被重複消費。　　

離線資料載入

訊息傳送語義

　　從producer的角度而言：0.11之後，kafka提供了一種冪等的機制，能夠保證重發不會在log中產生重複的項，因為broker給每個producer分配了一個ID並且刪除使用已被髮送訊息的序列碼的訊息；在這個版本後，kafka還支援向多個topic partitions傳送訊息的事務語義。

　　從consumer的角度而言：為了保證"exactly once"，我們可以在一個事務中處理資料並將offset寫入到topic中；事務預設的隔離級別是未提交讀。

　　kafka預設支援at-least-once傳送，並且允許使用者通過關閉重試機制實現at-most-once傳送以及在處理一批資料之前提交offset。

複製

　　所有的讀寫都是由leader partition實現。

　　kafka對節點存活的定義：

　　　　1. 節點維持著與ZK的session（依據ZK的心跳機制）；

　　　　2. 從節點必須複製主節點上發生的寫並且不能落後太多；

　　leader跟蹤從節點的列表，並且發現掛了、出錯或者落後的節點後將至從列表中移除。對於出錯或者落後的節點的配置在replica.lag.time.max.ms中；

　　kafka不處理拜占庭一類的問題：比如惡意或者隨意的回覆。

　　只有已經提交的訊息才能被consumer讀到。

　　producer可以選擇是否等待訊息被提交，這取決於在時延及永續性之間作權衡，這由相關的producer的ack配置控制。

Replicated Logs：Quorums，ISRs，and State Machines

　　kafka的選舉不是多數決，而是為能夠追上leader的副本動態維護一個ISR(In-sync replicas)，只有這裡的成員能夠參與leader選舉。寫入資料至partition時，只有in-sync的副本都接受到了，這些訊息才會確認。ISR集合放在ZK中。

所有ISR都掛了

兩種辦法：

　　等待ISR中的副本出現；（0.11後預設，可設定unclean.leader.election.enable改變）

　　選擇第一個出現的副本；

可用性及永續性保證

　　在多少副本寫入成功才認為訊息已提交：0，1，-1(all），注意：all只是保證所有處於正在in-sync的副本成功。

　　關於可用性及永續性，有兩個更高階的配置：

　　　　Disable unclean leader election；

　　　　指定最小ISR大小：不過只有當ack為all時才能起效。

副本管理

partition的分配：

leader的選擇：

日誌清理

保證

1. min.compaction.lag.ms可以保證訊息寫入後不被清理的最短時間；

2. 不改變順序

3. 不改變offset

4. delete.retention.ms

細節

日誌清理有一個log cleaner後臺執行緒池執行。

配置log cleaner

log.cleanup.policy=compact

log.cleaner.min.compaction.lag.ms 訊息在被清理前的最小保留時間

Quotas

Quotas的配置：

超過配額了怎麼辦：

操作

基本操作

topic相關

由於資料夾名大小限制255個字元，所以topic的名字長度有限制；

kafka可以增加partition的數目，但是不會改變已有資料的partition歸屬，同時也不支援減小partition的數目。

優雅關機

1. 同步日誌到磁碟，避免重啟時作日誌恢復；這一點在非hard kill情況下是預設執行的；

2. 關機前遷移所擁有的leader partition，需設定controlled.shutdown.enable=true。

balanced leadership

執行

bin/kafka-preferred-replica-election.sh --zookeeper zk_host:port/chroot

或者配置 auto.leader.rebalance.enable=true

跨機架平衡副本

broker.rack=my-rack-id可以設定broker所屬的機架，一個partition將分佈於min{racks，replication-factor}個機架中。 

跨叢集映象資料

source以及destination叢集的partition數量及offset都可以不一樣。

kafka-mirror-maker.sh命令，--whitelist指定topic，值需要在引號中，可以是一個正則表示式。

auto.create.topics.enable=true配置可以讓叢集實現自動建立或者備份資料。

擴容--關鍵是如何重分配partition

kafka-reassign-partitions.sh

縮容

提升備份因子

限制資料遷移過程中的網路頻寬

設定Quota

資料中心

橫跨多個數據中心的情形，kakfa更推薦使用映象叢集的方式。

不推薦部署一個跨越多個數據中心的叢集，因為會增加分片之間同步的延時，網路不可用時，要麼kafka要麼ZK不可用。

Kafka配置

producer的關鍵配置包括：

• acks
• compression
• batch size

consumer的關鍵配置是fetch size

依賴的Java版本

硬體及OS 

監測

kafka伺服器使用Yammer Metrics ，Kafka客戶端使用內建的Kafka Metrics。這兩者都拓展自JMX

依賴的ZooKeeper的配置

典型的ZK服務包含5或7個節點

使ZK隔離執行

為ZK分配足夠的Java堆空間

需要思考的問題：

1. subscribe與assign的區別