kafka各個版本特性預覽介紹
kafka-0.8.2 新特性
producer不再區分同步（sync）和異步方式（async），所有的請求以異步方式發送，這樣提升了客戶端效率。producer請求會返回一個應答對象，包括偏移量或者錯誤信。這種異步方地批量的發送消息到kafka broker節點，因而可以減少server端資源的開銷。新的producer和所有的服務器網絡通信都是異步地，在ack=-1模式下需要等待所有的replica副本完成複製時，可以大幅減少等待時間。
在0.8.2之前，kafka刪除topic的功能存在bug。
在0.8.2之前，comsumer定期提交已經消費的kafka消息的offset位置到zookeeper中保存。對zookeeper而言，每次寫操作代價是很昂貴的，而且zookeeper集羣是不能擴展寫能力的。在0.8.2開始，可以把comsumer提交的offset記錄在compacted topic（__comsumer_offsets）中，該topic設置最高級別的持久化保證，即ack=-1。__consumer_offsets由一個三元組< comsumer group, topic, partiotion> 組成的key和offset值組成，在內存也維持一個最新的視圖view，所以讀取很快。
kafka可以頻繁的對offset做檢查點checkpoint，即使每消費一條消息提交一次offset。
在0.8.1中，已經實驗性的加入這個功能，0.8.2中可以廣泛使用。auto rebalancing的功能主要解決broker節點重啓後，leader partition在broker節點上分佈不均勻，比如會導致部分節點網卡流量過高，負載比其他節點高出很多。auto rebalancing主要配置如下，
controlled.shutdown.enable ，是否在在關閉broker時主動遷移leader partition。基本思想是每次kafka接收到關閉broker進程請求時，主動把leader partition遷移到其存活節點上，即follow replica提升爲新的leader partition。如果沒有開啓這個參數，集羣等到replica會話超時，controller節點纔會重現選擇新的leader partition，這些leader partition在這段時間內也不可讀寫。如果集羣非常大或者partition 很多，partition不可用的時間將會比較長。
1）可以關閉unclean leader election，也就是不在ISR（IN-Sync Replica）列表中的replica，不會被提升爲新的leader partition。unclean.leader.election=false時，kafka集羣的持久化力大於可用性，如果ISR中沒有其它的replica，會導致這個partition不能讀寫。
2）設置min.isr（默認值1）和 producer使用ack=-1，提高數據寫入的持久性。當producer設置了ack=-1，如果broker發現ISR中的replica個數小於min.isr的值，broker將會拒絕producer的寫入請求。max.connections.per.ip限制每個客戶端ip發起的連接數，避免broker節點文件句柄被耗光。
kafka-0.9 新特性
一、安全特性
在0.9之前，Kafka安全方面的考慮幾乎爲0，在進行外網傳輸時，只好通過Linux的防火牆、或其他網絡安全方面進行配置。相信這一點，讓很多用戶在考慮使用Kafka進行外網消息交互時有些擔心。
客戶端連接borker使用SSL或SASL進行驗證
borker連接ZooKeeper進行權限管理
數據傳輸進行加密（需要考慮性能方面的影響）
客戶端讀、寫操作可以進行授權管理
可以對外部的可插拔模塊的進行授權管理
當然，安全配置方面是可選的，可以混合使用。如：做過安全配置的的borkers和沒有進行安全配置的borkers放在同一集羣，授權的客戶端和沒有授權的客戶端，也可以在同一個集羣等等。具體配置詳見官方文檔。
二、Kafka Connect
這個功能模塊，也是之前版本沒有的。可以從名稱看出，它可以和外部系統、數據集建立一個數據流的連接，實現數據的輸入、輸出。有以下特性：
使用了一個通用的框架，可以在這個框架上非常方面的開發、管理Kafka Connect接口
支持分佈式模式或單機模式進行運行
支持REST接口，可以通過REST API提交、管理 Kafka Connect集羣
offset自動管理
同時，官方文檔中，也給出了例子。通過配置，往一個文本文件中輸入數據，數據可以實時的傳輸到Topic中。在進行數據流或者批量傳輸時，是一個可選的解決方案。
三、新的Comsumer API
新的Comsumer API不再有high-level、low-level之分了，而是自己維護offset。這樣做的好處是避免應用出現異常時，數據未消費成功，但Position已經提交，導致消息未消費的情況發生。通過查看API，新的Comsumer API有以下功能：
Kafka可以自行維護Offset、消費者的Position。也可以開發者自己來維護Offset，實現相關的業務需求。
消費時，可以只消費指定的Partitions
可以使用外部存儲記錄Offset，如數據庫之類的。
自行控制Consumer消費消息的位置。
可以使用多線程進行消費
kafka-0.10 新特性
Kafka已經內置了機架感知以便隔離副本，這使得Kafka保證副本可以跨越到多個機架或者是可用區域，顯著提高了Kafka的彈性和可用性。這個功能是由Netflix提供的
所有Kafka中的消息都包含了時間戳字段，這個時間就是這條消息產生的時間。這使得Kafka Streams能夠處理基於事件時間的流處理；而且那些通過時間尋找消息以及那些基於事件時間戳的垃圾回收特性能爲可能。
Apache Kafka 0.9.0.0版本引入了新的安全特性，包括通過SASL支持Kerberos。Apache Kafka 0.10.0.0現在支持更多的SASL特性，包括外部授權服務器，在一臺服務器上支持多種類型的SASL認證以及其他的改進。
Kafka Connect得到了持續提升。在此之前，用戶需要監控日誌以便看到各個connectors以及他們task的狀態，現在Kafka已經支持了獲取的狀態API這樣使得監控變得更簡單。同時也添加了控制相關的API，這使得用戶可以在進行維護的時候停止一個connector；或者手動地重啓那些失敗的task。這些能夠直觀的在用戶界面展示和管理connector目前可以在控制中心(Control Center)看到。
Kafka Consumer Max Records，在Kafka 0.9.0.0，開發者們在新consumer上使用poll()函數的時候是幾乎無法控制返回消息的條數。不過值得高興的是，此版本的Kafka引入了max.poll.records參數，允許開發者控制返回消息的條數。
協議版本改進，Kafka brokers現在支持返回所有支持的協議版本的請求API，這個特點的好處就是以後將允許一個客戶端支持多個broker版本。
kafka-0.11 新特性
Apache Kafka推出0.11版本。這是一個里程碑式的大版本，特別是Kafka從這個版本開始支持“exactly-once”語義(下稱EOS， exactly-once semantics)。本文簡要介紹一下0.11版本主要的功能變更，下面中的每一項都值得專門寫篇文章好好聊聊。
一、修改unclean.leader.election.enabled默認值
Kafka社區終於下定決心要把這個參數的默認值改成false，即不再允許出現unclean leader選舉的情況，在正確性和高可用性之間選擇了前者。如果依然要啓用它，用戶需要顯式地在server.properties中設置這個參數=true
二、確保offsets.topic.replication.factor參數被正確應用
__consumer_offsets這個topic是Kafka自動創建的，在創建的時候如果集羣broker數<offsets.topic.replication.factor，原先的版本取其小者，但這會違背用戶設置該參數的初衷。因此在0.11版本中這個參數會被強制遵守，如果不滿足該參數設定的值，會拋出GROUP_COORDINATOR_NOT_AVAILABLE。
三、優化了對Snappy壓縮的支持
之前由於源代碼中硬編碼了block size，使得producer使用Snappy時的表現比LZ4相差很多，但其實Snappy和LZ4兩者之差距不應該很大。故此0.11版本中對Snappy的默認block size做了調整。不過這一點需要詳盡的性能測試報告來證明此改動是有效的。
四、消息增加頭部信息(Header)
Record增加了Header，每個header是一個KV存儲。具體的header設計參見KIP-82
五、空消費者組延時rebalance
爲了縮短多consumer首次rebalance的時間，增加了“group.initial.rebalance.delay.ms”用於設置group開啓rebalance的延時時間。這段延時期間允許更多的consumer加入組，避免不必要的JoinGroup與SyncGroup之間的切換。當然凡事都是trade-off，引入這個必然帶來消費延時。
六、消息格式變更
增加最新的magic值：2。增加了header信息。同時爲了支持冪等producer和EOS，增加一些與事務相關的字段，使得單個record數據結構體積增加。但因爲優化了RecordBatch使得整個batch所佔體積反而減少，進一步降低了網絡IO開銷。
七、新的分配算法：StickyAssignor
比range和round-robin更加平衡的分配算法。指定partition.assignment.strategy = org.apache.kafka.clients.consumer.StickyAssignor可以嚐嚐鮮。不過根據我的經驗，分配不均勻的情況通常發生在每個consumer訂閱topic差別很大的時候。比如consumer1訂閱topic1, topic2, topic4, consumer2訂閱topic3, topic4這種情況
八、controller重設計
Controller原來的設計非常複雜，使得社區裏面的人幾乎不敢改動controller代碼。老版本controller的主要問題在我看來有2個：1. controller需要執行1，2，3，4，5，6步操作，倘若第3步出錯了，無法回滾前兩步的操作；2. 多線程訪問，多個線程同時訪問Controller上下文信息。0.11版本部分重構了controller，採用了單線程+基於事件隊列的方式。具體效果咱們拭目以待吧~~
九、支持EOS
0.11最重要的功能，沒有之一！EOS是流式處理實現正確性的基石。主流的流式處理框架基本都支持EOS（如Storm Trident, Spark Streaming, Flink），Kafka streams肯定也要支持的。0.11版本通過3個大的改動支持EOS：1.冪等的producer（這也是千呼萬喚始出來的功能）；2. 支持事務；3. 支持EOS的流式處理(保證讀-處理-寫全鏈路的EOS)