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)