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版本。

發佈了97 篇原創文章 · 獲贊 16 · 訪問量 14萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章