Apache Kafka 0.11版本新功能簡介

Apache Kafka近日推出0.11版本。這是一個里程碑式的大版本，特別是Kafka從這個版本開始支持「exactly-once」語義(下稱EOS， exactly-once semantics)。本文簡要介紹一下0.11版本主要的功能變動，下面中的每一項都值得專門寫篇文章好好聊聊。

1、修改unclean.leader.election.enabled默認值

Kafka社區終於下定決心要把這個參數的默認值改爲false，即再也不容許出現unclean leader選舉的狀況，在正確性和高可用性之間選擇了前者。若是依然要啓用它，用戶須要顯式地在server.properties中設置這個參數=true

2、確保offsets.topic.replication.factor參數被正確應用

__consumer_offsets這個topic是Kafka自動建立的，在建立的時候若是集羣broker數<offsets.topic.replication.factor，原先的版本取其小者，但這會違背用戶設置該參數的初衷。所以在0.11版本中這個參數會被強制遵照，若是不知足該參數設定的值，會拋出GROUP_COORDINATOR_NOT_AVAILABLE。

3、優化了對Snappy壓縮的支持

以前因爲源代碼中硬編碼了block size，使得producer使用Snappy時的表現比LZ4相差不少，但其實Snappy和LZ4二者之差距不該該很大。故此0.11版本中對Snappy的默認block size作了調整。不過這一點須要詳盡的性能測試報告來證實此改動是有效的。

4、消息增長頭部信息(Header)

Record增長了Header，每一個header是一個KV存儲。具體的header設計參見KIP-82

5、空消費者組延時rebalance

爲了縮短多consumer首次rebalance的時間，增長了「group.initial.rebalance.delay.ms」用於設置group開啓rebalance的延時時間。這段延時期間容許更多的consumer加入組，避免沒必要要的JoinGroup與SyncGroup之間的切換。固然凡事都是trade-off，引入這個必然帶來消費延時。

6、消息格式變動

增長最新的magic值：2。增長了header信息。同時爲了支持冪等producer和EOS，增長一些與事務相關的字段，使得單個record數據結構體積增長。但由於優化了RecordBatch使得整個batch所佔體積反而減小，進一步下降了網絡IO開銷。

7、新的分配算法：StickyAssignor

比range和round-robin更加平衡的分配算法。指定partition.assignment.strategy = org.apache.kafka.clients.consumer.StickyAssignor能夠嚐嚐鮮。不過根據個人經驗，分配不均勻的狀況一般發生在每一個consumer訂閱topic差異很大的時候。好比consumer1訂閱topic1, topic2, topic4, consumer2訂閱topic3, topic4這種狀況

8、controller重設計

Controller原來的設計很是複雜，使得社區裏面的人幾乎不敢改動controller代碼。老版本controller的主要問題在我看來有2個：1.  controller須要執行1，2，3，4，5，6步操做，假若第3步出錯了，沒法回滾前兩步的操做；2. 多線程訪問，多個線程同時訪問Controller上下文信息。0.11版本部分重構了controller，採用了單線程+基於事件隊列的方式。具體效果我們拭目以待吧~~

9、支持EOS

0.11最重要的功能，沒有之一！EOS是流式處理實現正確性的基石。主流的流式處理框架基本都支持EOS（如Storm Trident, Spark Streaming, Flink），Kafka streams確定也要支持的。0.11版本經過3個大的改動支持EOS：1.冪等的producer（這也是千呼萬喚始出來的功能）；2. 支持事務；3. 支持EOS的流式處理(保證讀-處理-寫全鏈路的EOS)