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

##kafka各個版本特色介紹和總結 ###1.1 kafka的功能特色：

• 分佈式消息隊列

  消息隊列的數據模型， 造成流式數據。
  	 提供Pub/Sub方式的海量消息處理。以高容錯的方式存儲海量數據流。保證數據流的順序。
  	 消費者：一份消息可多個消費者都處理，也能夠只由一個消費者處理

• 線性擴展，高可用

  分佈式系統，易於向外擴展。全部的producer、broker和consumer都會有多個，均爲分佈式的。無需停機便可擴展機器。
  	動態的增長一個topic的partition文件數量，就能夠線性擴展一個topic的處理能力。

• 以高容錯的方式存儲海量數據流。

  每一個topic包含多個partition，partiton又有多個副本，均勻的分佈在多個機器上。

• 高吞吐量:生成和消費速度很是快

  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年之前 ）

比較老的版本。