一、About 0.10.0.0

Apache Kafka 0.10.0.0於美國時間2016年5月24日正式釋出。Apache Kafka 0.10.0.0是Apache Kafka的主要版本。以下是新特性：

1、Kafka Streams

Kafka Streams由Confluent Platform首先在其平臺的技術預覽中行提出，目前已經在Apache Kafka 0.10.0.0上可用了。Kafka Streams其實是一套類庫，它使得Apache Kafka可以擁有流處理的能力。Kafka Streams包含了一整套描述常見流操作的高階語言API（比如 joining, filtering以及aggregating records），這使得開發者可以快速開發強大的流處理應用程式。Kafka Streams提供了狀態和無狀態的處理能力，並且可以部署在很多系統之上： Kafka Streams應用程式可以執行在YARN、Mesos、Docker containers上，甚至直接嵌入到現有的Java應用程式中。

2、機架感知(Rack Awareness)

現在Kafka已經內建了機架感知以便隔離副本，這使得Kafka保證副本可以跨越到多個機架或者是可用區域，顯著提高了Kafka的彈性和可用性。這個功能是由Netflix提供的。

3、訊息的時間戳

現在所有Kafka中的訊息都包含了時間戳欄位，這個時間就是這條訊息產生的時間。這使得Kafka Streams能夠處理基於事件時間的流處理；而且那些通過時間尋找訊息以及那些基於事件時間戳的垃圾回收特效能為可能。

4、SASL改進

　　Apache Kafka 0.9.0.0版本引入了新的安全特性，包括通過SASL支援Kerberos。Apache Kafka 0.10.0.0現在支援更多的SASL特性，包括外部授權伺服器，在一臺伺服器上支援多種型別的SASL認證以及其他的改進。

5、顯示所有支援的Connectors和連線狀態/控制的REST API

　　在Kafka 0.10.0.0中，Kafka Connect得到了持續提升。在此之前，使用者需要監控日誌以便看到各個connectors以及他們task的狀態，現在Kafka已經支援了獲取的狀態API這樣使得監控變得更簡單。同時也添加了控制相關的API，這使得使用者可以在進行維護的時候停止一個connector；或者手動地重啟那些失敗的task。這些能夠直觀的在使用者介面展示和管理connector目前可以在控制中心(Control Center)看到。

6、Kafka Consumer Max Records

　　在Kafka 0.9.0.0，開發者們在新consumer上使用poll()函式的時候是幾乎無法控制返回訊息的條數。不過值得高興的是，此版本的Kafka引入了max.poll.records引數，允許開發者控制返回訊息的條數。

7、協議版本改進(Protocol Version Improvements)

　　Kafka brokers現在支援返回所有支援的協議版本的請求API，這個特點的好處就是以後將允許一個客戶端支援多個broker版本。

二、About 0.11.0.0

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儲存。

五、空消費者組延時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)