kafka各個版本特色介紹和總結

kafka各個版本特色介紹和總結

1.1 kafka的功能特色:

  • 分佈式消息隊列linux

    消息隊列的數據模型, 造成流式數據。
     提供Pub/Sub方式的海量消息處理。以高容錯的方式存儲海量數據流。保證數據流的順序。
     消費者:一份消息可多個消費者都處理,也能夠只由一個消費者處理
  • 線性擴展,高可用
    分佈式系統,易於向外擴展。全部的producer、broker和consumer都會有多個,均爲分佈式的。無需停機便可擴展機器。 動態的增長一個topic的partition文件數量,就能夠線性擴展一個topic的處理能力。編程

  • 以高容錯的方式存儲海量數據流。
    每一個topic包含多個partition,partiton又有多個副本,均勻的分佈在多個機器上。api

  • 高吞吐量:生成和消費速度很是快
    1. kafka server 生成日誌的速度能夠接近磁盤的只寫速度(幾十兆 ~ 百兆)。 kafka的實現思想是文件直寫(直接使用linux 文件系統的cache)的commit log. 速度很是的快. 若是消息大小爲百字節級別的話,那麼也就是說單機寫入能夠達到幾十W/S。 2. 磁盤順序讀寫 3. 採用linux Zero-Copy提升消息發送到consumer的性能。減小IO操做步驟;能夠提升60%的數據發送性能。安全

1.2 kafka的使用場景:

kafka的使用場景,即kafka的用途。網絡

  • 數據總線(數據管道)

    Kafka主要用途是數據集成,或者說是流數據集成,以Pub/Sub形式的消息總線形式提供。Kafka可讓合適的數據以合適的形式出如今合適的地方。
1. 下降系統組網複雜度。
    2. 下降編程複雜度,各個子系統不在是相互協商接口,各個子系統相似插口插在插座上,Kafka承擔高速數據總線的做用。

日誌收集,用戶行爲數據,運維監控數據收集,均可以適合該場景。運維

  • 海量數據 發佈/訂閱的消息隊列分佈式

  • 實時計算的流式數據源(storm,spark-streaming)工具

  • 離線計算的數據源性能

    1. kafka的數據文件做爲離線計算的數據源。 
    2. 消費kafka的數據,存儲到離線平臺HDFS等。

1.3 kafka的大的版本升級

kafka 從0.7 ,0.8.x, 0.9.x 0.10.0.X ,1.0.0 的主要演進:測試

  • 1.0.0 ~1.1.0 的重大升級 (2017.11.1)

    1. 更好地支持磁盤容錯,更優雅地處理磁盤錯誤.
    2. Streams API 在 1.0.0 版本里繼續演進.
    3. 支持 Java 9
    4. 提高了生產者的吞吐量。
    5. kafka 第一個正式版。
  • 在0.11.x的重大變化(2017.6.28)

    1. kafka Streams 支持 Exactly-Once Semantics
  • 在0.10.x的重大變化(2016.5.22)
1. 從0.10.0.0開始,增長一個新的客戶端Kafka Streams客戶端API。
       用於流式處理存儲在kafka topic的數據。這個新客戶端僅支持0.10.x或更高的版本。
    2. 舊的的Scala的生產者已經棄用。使用者儘快使用最新的Java客戶端,新的消費者API已標記爲穩定。
    3. 消息包含了一個時間戳字段和壓縮後消息的關係offset。
    5. 新的Java消費者如今容許用戶經過分區上的時間戳來搜索offset。
    6. 啓用了kafka的權限。
    7. kafka集羣的broker id 支持自動生成了(cluster_id)。
    8. kafka broker 的服務協議有增長。
    9. 日誌保留時間再也不基於日誌段的最後修改時間。相反,它將基於日誌段中消息的最大時間戳。
    10.日誌滾動時間再也不取決於日誌段的建立時間。而是基於消息中的時間戳.
    影響:
    1. 客戶端須要升級到0.10.0.0,避免形成,消息格式轉換,形成系統負載升高。
    2. 因爲kafka功能的擴充,消息格式更改,kafka的吞吐性能有稍微的降低。
       (若是集羣的能力與網絡接近,可能會超過網卡,並看到因爲過載的故障和性能問題。)
    3. 整體上將kafka 0.10.x變的更加穩健,功能也更加完善。
  • 0.9.x的重大變化(2015.11.23)
1. Java 1.6再也不支持。
    2. Scala 2.9再也不支持。
    3. 變動topic配置管理開始單獨處理。
    4. 啓用新的kafka性能測試工具。
    5. broker協議版本升級,升級須要重啓服務。
    6. 分區的leader和副本的同步機制發生了變化。
    7. kafka client的源碼包結構有所變化。
    8. 日誌清理和壓縮的機制發生了變化。 
    9. Kafka Connect這個功能模塊
    10. 安全特性的第一次加入:客戶端鏈接borker使用SSL或SASL進行驗證。
    11. Comsumer API再也不有high-level、low-level之分。

0.9版本的kafka 因爲變化和改動較多,很不穩定,在生產環境中不多使用。
  • 從0.8.0升級到0.8.2( 2013,7 ~ 2015.2 )
服務端 最穩定的版本,性能最好;但客戶端還不是很完善。
客戶端api不兼容之前的版本。
  • 從0.7版本( 2012年之前 )
比較老的版本。
相關文章
相關標籤/搜索