Kafka快速入門（一）——Kafka簡介

Kafka快速入門（一）——Kafka簡介

1、Apache Kafka簡介

一、Apache Kafka簡介

Apache Kafka是一款開源的消息引擎系統，同時也是分佈式流處理平臺。
消息引擎系統是一組在不一樣系統之間傳遞語義準確的消息，實現鬆耦合的異步式數據傳遞的規範。

二、Kafka設計目標

Kafka的設計目標以下：
（1）以時間複雜度爲O(1)的方式提供消息持久化能力，即便對TB級以上數據也能保證常數時間的訪問性能。
（2）高吞吐率。即便在很是廉價的商用機器上也能作到單機支持每秒100K條消息的傳輸。
（3）支持Kafka Server間的消息分區及分佈式消費，同時保證每一個Partition內的消息順序傳輸。
（4）同時支持離線數據處理和實時數據處理。
（5）支持在線水平擴展。

三、Kafka高吞吐率實現

爲了增長存儲能力，Kafka將全部的消息都寫入到了低速大容量的硬盤。Kafka主要採用如下方式實現高吞吐率：
（1）順序讀寫：Kafka將消息順序追加到Partition中，順序讀寫要快於隨機讀寫。
（2）Zero Copy：Kafka的生產者、消費者API對於Kafka消息採用零拷貝實現。Java類庫經過java.nio.channels.FileChannel中的transferTo()方法(底層sendfile系統調用)在Linux和UNIX系統上支持Zero Copy，內核直接將數據從磁盤文件拷貝到Socket套接字，而無需經過應用程序。
（3）批量發送：Kafka容許批量發送模式。
（4）消息壓縮：Kafka容許對消息集合進行壓縮。
（5）操做系統頁緩存：不直接寫IO，直接寫入頁緩存；消費時大多命中緩存。

四、Kafka消息傳遞模式

（1）點對點模型
點對點模式是一個基於拉取或輪詢的消息傳送模型，由消費者主動拉取數據，客戶端須要實時開啓一個線程監控隊列中是否有數據。
在點對點的消息系統中，消息保留在隊列中，一個或者多個消費者能夠消費隊列中的消息，但消息最多隻能被一個消費者消費，一旦有一個消費者將其消費掉，消息就從隊列中消失。多個消費者能夠同時工做，但最終只有一個消費者能夠消費消息。典型實例如訂單處理系統，多個訂單處理器能夠同時工做，但對於一個特定的訂單，只有其中一個訂單處理器能夠拿到並進行處理。
（2）發佈/訂閱模型
發佈/訂閱模式是一個基於推送的消息傳送模型，由MQ主動推送消息給全部訂閱者，即便當前訂閱者不可用。
在發佈-訂閱系統中，消息被保留在主題中。消費者能夠訂閱一個或多個主題並使用主題中的全部消息。在發佈-訂閱系統中，消息生產者稱爲發佈者，消息消費者稱爲訂閱者。

五、流處理平臺特性

流處理平臺有三種特性:
（1）能夠發佈和訂閱流式消息。
（2）能夠儲存流式消息，而且有較好的容錯性。
（3）能夠在流式消息產生時就進行處理。

六、Kafka優勢

（1）解耦
Kafka消息引擎系統能夠將業務處理過程進行解耦，消息引擎兩端的業務處理過程只須要實現接口便可。
（2）冗餘
消息隊列把消息進行持久化，直到消息被徹底處理，進而規避數據丟失風險。
（3）擴展性
消息隊列解耦了業務處理過程，因此很容易增大消息入隊和處理的頻率，只要另外增長處理過程便可，不須要改變代碼、不須要調節參數。
（4）削峯填谷
削峯填谷是流量整形的形象表達，是爲了應對上游瞬時大流量的衝擊，避免出現流量毛刺，保護下游應用和數據庫不被瞬時大流量打垮。
（5）可恢復性
系統的一部分組件失效時，不會影響到整個系統。消息隊列下降了進程間的耦合度，即便一個處理消息的進程掛掉，加入隊列中的消息仍然能夠在系統恢復後被處理。
（6）順序保證
Kafka保證一個Partition內的消息的有序性。
（7）緩衝
消息隊列經過一個緩衝層來幫助任務最高效率的執行——寫入隊列的處理會盡量的快速。緩衝有助於控制和優化數據流通過系統的速度。
（8）異步通訊
消息隊列提供了異步處理機制，容許用戶把一個消息放入隊列，但並不當即處理，在須要時再處理。

七、其它消息隊列

（1）RabbitMQ
RabbitMQ是使用Erlang編寫的一個開源的重量級企業級消息隊列，自己支持不少的協議：AMQP、XMPP、SMTP、STOMP。RabbitMQ實現了Broker構架，消息在發送給客戶端時先在中心隊列排隊，對路由、負載均衡或者數據持久化支持很好。
（2）Redis
Redis是一個基於Key-Value對的NoSQL數據庫，但支持MQ功能，能夠做爲輕量級的MQ使用。入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而若是數據大小超過10K，Redis較慢；出隊時，不管數據大小，Redis都表現出很是好的性能，而RabbitMQ的出隊性能則遠低於Redis。
（3）ZeroMQ
ZeroMQ可以實現RabbitMQ不擅長的高級/複雜的隊列，但開發人員須要本身組合多種技術框架，技術上的複雜度是對ZeroMQ可以應用成功的挑戰。ZeroMQ具備一個獨特的非中間件的模式，不須要安裝和運行消息服務器或中間件，應用程序會扮個服務器角色，但ZeroMQ僅提供非持久性的隊列。
（4）ActiveMQ
ActiveMQ可以以代理人和點對點的技術實現隊列，少許代碼就能夠高效地實現高級應用場景。
（5）Kafka/Jafka
Apache Kafka是一個高性能跨語言分佈式發佈/訂閱消息隊列系統，而Jafka是基於Kafka的升級版。特性以下：
A、快速持久化，能夠在O(1)的系統開銷下進行消息持久化；
B、高吞吐，在一臺普通的服務器上既能夠達到10W/s的吞吐速率；
C、徹底的分佈式系統，Broker、Producer、Consumer都原生自動支持分佈式，自動實現負載均衡；
D、支持Hadoop數據並行加載，Kafka經過Hadoop並行加載機制統一了在線和離線的消息處理。
（6）RocketMQ
Apache RocketMQ是阿里開源的純Java實現的分佈式消息中間件，支持事務消息、順序消息、批量消息、定時消息、消息回溯等。

2、Kafka生態

一、Apache Kafka

Kafka最初由LinkedIn使用Scala進行開發，於2011年初加入Apache開源項目，2012年10月從Apache Incubator畢業，成爲Apache頂級項目，即Apache Kafka。Apache Kafka的目標是爲處理實時數據提供一個統1、高吞吐量、低延時的平臺。
官方地址：http://kafka.apache.org

二、Confluent Kafka

2014年，Kafka的創始人Jay Kreps、NahaNarkhede和饒軍離開LinkedIn創立Confluent公司，專一於提供基於Kafka的企業級流處理解決方案，併發布了Confluent Kafka。Confluent Kafka分爲開源版和企業版，企業版收費。
Confluent開源版特性以下：
（1）Confluent Kafka Connectors：支持Kafka Connect JDBC Connector、Kafka Connect HDFS Connector、Kafka Connect Elasticsearch Connector、Kafka Connect S3 Connector。
（2）多客戶端支持：支持C/C++、Python、Go、.Net客戶端。
（3）Confluent Schema Registry
（4）Confluent Kafka REST Proxy
Confluent企業版特性以下：
（1）Automatic Data Balancing
（2）Multi-DataCenter Replication
（3）Confluent Control Center
（4）JMS Client

3、Apache Kafka版本

一、0.7

2011年7月，Apache Kafka發佈第一個開源版本0.7.0，提供最基礎的消息引擎服務，主要特性是壓縮以及MirrorMaker（跨集羣之間的數據拷貝）。Apache Kafka 0.7是按純字節組織數據的，其偏移量是基於字節的。

二、0.8

2012年10月，Apache Kafka正式成爲Apache頂級項目併發布0.8版本，引入了集羣間的備份機制，使得Apache Kafka成爲完備的分佈式消息引擎解決方案。
Apache Kafka 0.8版本更新了消息數據結構，把數據偏移量改爲按邏輯的，每條信息的數據偏移量是1。
0.8.2.x：使用Java重寫Producer API，替代Scala的Producer API。

三、0.9

2014年11月，Apache Kafka 0.9.0發佈，主要特性以下：
（1）增長基礎的安全認證/權限功能。
Apache Kafka 0.9.0首次增長了安全認證功能，安全特性以下：
A、客戶端鏈接Broker使用SSL或SASL進行驗證。
B、Broker鏈接ZooKeeper進行權限管理。
C、數據傳輸進行加密。
D、客戶端讀、寫操做能夠進行受權管理。
E、能夠對外部的可插拔模塊的進行受權管理。
（2）使用Java重寫Consumer API。
新的Comsumer API不分high-level、low-level， Kafka能夠自行維護Offset、Consumer的Position，也能夠由開發者本身來維護Offset，實現相關的業務需求；消費時，能夠只消費指定的Partitions；可使用外部存儲記錄Offset；自行控制Consumer消費消息的Position；可使用多線程進行消費。
（3）引入Kafka Connect組件用於實現高性能的數據抽取。
0.9版本中Producer API已經比較穩定，但Consumer API的Bug較多。

四、0.10

2016年5月，Apache Kafka 0.10發佈，引入Kafka Streams，Apache Kafka正式升級成分佈式流處理平臺，其主要特性以下：
（1）Kafka Streams
Kafka Streams由Confluent Platform首先在其平臺的技術預覽中行提出，目前已經引入Apache Kafka 0.10.0.0。Kafka Streams是一套類庫，使得Apache Kafka能夠擁有流處理的能力。Kafka Streams包含了一整套描述常見流操做的高級語言API（好比 joining, filtering以及aggregating records），使得開發者能夠快速開發強大的流處理應用程序。Kafka Streams提供了狀態和無狀態的處理能力，而且能夠部署在不少系統上：Kafka Streams應用程序能夠運行在YARN、Mesos、Docker containers上，甚至直接嵌入到現有的Java應用程序中。
（2）機架感知(Rack Awareness)
Apache Kafka 0.10已經內置了機架感知以便隔離副本，使得Kafka保證副本能夠跨越到多個機架或者是可用區域，顯著提升了Kafka的彈性和可用性，功能由Netflix提供。
（3）消息時間戳
Apache Kafka 0.10引入了消息時間戳，全部Kafka中的消息都包含時間戳字段，即消息產生的時間。消息時間戳使得Kafka Streams可以處理基於事件時間的流處理，並且能夠經過時間尋找消息以及基於事件時間戳的進行垃圾回收。
（4）SASL改進
Apache Kafka 0.9.0.0版本引入了新的安全特性，包括經過SASL支持Kerberos。Apache Kafka 0.10.0.0支持更多的SASL特性，包括外部受權服務器，在一臺服務器上支持多種類型的SASL認證以及其它改進。
（5）顯示全部支持的Connectors和鏈接狀態/控制的REST API
在Kafka 0.10.0.0中，Kafka Connect獲得了持續提高。在Kafka 0.10版本前，用戶須要監控日誌以便看到各個Connectors以及Task的狀態，Kafka 0.10.0增長了獲取狀態的API，同時也添加了控制相關的API，使得用戶能夠在進行維護的時候中止一個Connector或者手動地重啓失敗的Task。
（6）Kafka Consumer Max Records
在Apache Kafka 0.9.0.0，開發者在新consumer上使用poll()函數時幾乎沒法控制返回消息的條數。Apache Kafka 0.10.0.0引入了max.poll.records參數，容許開發者控制返回消息的條數。
（7）協議版本改進(Protocol Version Improvements)
Apache Kafka 0.10.0.0中，Kafka Brokers支持返回全部支持的協議版本的請求API，優勢是之後將容許一個客戶端支持多個Broker版本。
0.10.2.2版本修復了一個可能致使Producer性能下降的Bug，而且Consumer API已經比較穩定。

五、0.11

2017年6月，Apache Kafka 0.11.0發佈，支持exactly-once semantics（EOS)，其主要特性以下：
（1）修改unclean.leader.election.enabled默認值
Apache Kafka將unclean.leader.election.enabled參數的默認值改爲false，即再也不容許出現unclean leader選舉的狀況，在正確性和高可用性之間選擇了正確性。若是依然要啓用，用戶須要顯式地在server.properties中設置參數爲true。
（2）確保offsets.topic.replication.factor參數被正確應用
__consumer_offsets是Kafka自動建立的Topic，在建立的時候若是集羣Broker數小於offsets.topic.replication.factor，原先的版本取其小者，但會違背用戶設置offsets.topic.replication.factor參數的初衷。所以在Kafka 0.11版本中，offsets.topic.replication.factor參數會被強制遵照，若是不知足參數設定的值，會拋出GROUP_COORDINATOR_NOT_AVAILABLE。
（3）優化對Snappy壓縮的支持
Apache Kafka 0.11.0版本對Snappy的默認block size作了調整。
（4）消息增長頭部信息(Header)
Record增長了Header，每一個header是一個KV存儲。
（5）空消費者組延時Rebalance
爲了縮短多Consumer首次Rebalance的時間，增長了「group.initial.rebalance.delay.ms」用於設置Group開啓Rebalance的延時時間。延時期間容許更多的Consumer加入組，避免沒必要要的JoinGroup與SyncGroup之間的切換。
（6）消息格式變動
Apache Kafka 0.11.0版本增長最新的magic值：2，增長header信息。同時爲了支持冪等Producer和EOS，增長一些與事務相關的字段，使得單個record數據結構體積增長。但由於優化了RecordBatch使得整個batch所佔體積反而減小，進一步下降了網絡IO開銷。
（7）新的StickyAssignor分配算法
StickyAssignor是比range和round-robin更加平衡的分配算法。能夠經過partition.assignment.strategy = org.apache.kafka.clients.consumer.StickyAssignor指定。
（8）Controller重設計
Apache Kafka 0.11.0版本採用單線程+基於事件隊列的方式重構了Controller。
（9）支持EOS
exactly-once semantics（EOS）是流式處理實現正確性的基石，主流流式處理框架基本都支持EOS（如Storm Trident、Spark Streaming、Flink）。
Apache Kafka 0.11.0經過三大特性：冪等的Producer、支持事務、支持EOS的流式處理(保證讀-處理-寫全鏈路的EOS)，實現對EOS的支持。

六、1.0

2017年11月，Apache Kafka 1.0發佈，主要優化Kafka Streams API以及完善各類監控指標，主要以下：
（1）改進builder API（KIP-120），新增用於查看運行時活躍任務的API（KIP-130）和用於聚合分區的 cogroup API（KIP-150）。（2）加強print()和writeAsText()方法讓調試變得更容易（KIP-160）。
（3）改進Connect的度量指標（KIP-196），新增大量用於健康監測的度量指標（KIP-188），並提供集羣的GloabalTopicCount 和GlobalPartitionCount度量指標（KIP-168）。
（4）支持 Java 9，實現更快的TLS和CRC32C，加快加密速度，下降計算開銷。
（5）調整了SASL認證模塊的錯誤處理邏輯（KIP-152），認證錯誤信息會被清晰地記錄到日誌當中。
（6）更好地支持磁盤容錯（KIP-112），更優雅地處理磁盤錯誤，單個JBOD上的磁盤錯誤不會致使整個集羣崩潰。
（7）提高吞吐量。0.11.0版本中引入的冪等性生產者須要將max.in.flight.requests.per.connection參數設置爲1，對吞吐量形成必定的限制，在1.0.0版本中，參數最大能夠被設置爲5（KAFKA-5949），極大提高吞吐量範圍。

七、2.0

2018年7月，Apache Kafka 2.0發佈，其主要特性以下：
（1）增長前綴通配符訪問控制(ACL)的支持，能夠更加細粒度的進行訪問控制；
（2）更全面的數據安全支持，可使用OAuth2 bearer tokens對訪問Kafka Brokers 進行權限控制。
（3）SSL鏈接默認啓用主機名驗證（Host name verification），以確保默認SSL配置不受中間人***的影響。
（4）能夠在不重啓Broker的狀況下動態更新SSL信任庫（SSL truststores）；能夠在啓動Broker前在ZooKeeper中爲Broker 偵聽器（broker listeners）配置安全性，包括SSL密鑰庫和信任庫密碼以及SAS的JAAS配置。
（5）複製協議已獲得改進，以免在fast leader failover期間 Leader和Follower之間的日誌分歧（log divergence）。
（6）保證在線升級的方便性，簡化了Kafka Streams升級過程。
（7）進一步增強了Kafka的可監控性，包括添加了不少系統靜態屬性以及動態健康指標。
（8）放棄對Java 7的支持，並移除Scala編寫的Producer API和Consumer API代碼。

4、Kafka適用場景

一、Kafka做爲存儲系統

Kafka是一個很是好的存儲系統，寫入Kafka的數據將寫入磁盤並進行復制以實現容錯功能。Kafka容許生產者等待確認，以便直到徹底複製並確保即便寫入服務器失敗的狀況下寫入也不會完成。
Kafka會認真對待存儲並容許客戶端控制其讀取位置，所以能夠將Kafka視爲一種專用於高性能、低延遲提交日誌存儲、複製和傳播的專用分佈式文件系統。

二、Kafka做爲消息傳遞系統

消息傳遞具備排隊和發佈-訂閱兩種模型。排隊模型中，一組使用者能夠從服務器中讀取內容，而且每條記錄都將轉到其中一個，優勢在於容許將數據處理劃分到多個使用者實例上，從而擴展處理量，缺點在於隊列不是多用戶的。發佈-訂閱模型中，消息會廣播給全部消費者，優勢在於容許將數據廣播到多個進程，缺點在於每條消息都傳遞給每一個訂閱者，所以沒法擴展處理。
Kafka的Consumer Group融合了排隊模型和發佈訂閱模型的優勢，Consumer Group容許將處理劃分爲一組進程（Consumer Group的成員）；Kafka容許將消息廣播到多個Consumer Group。
傳統隊列將消息按順序保留在服務器上，若是多個消費者從隊列中消費，則服務器將按記錄的存儲順序分發記錄。儘管服務器按順序分發消息，但消息是異步傳遞給消費者的，所以消息可能在不一樣的消費者上亂序到達，即在並行使用的狀況下消息會亂序。
Kafka在Topic內具備並行性（即Partition），經過將Topic中的Partition分配給Consumer Group中的消費者，每一個分區都由Consumer Group中的一個消費者徹底消費，Kafka可以在用戶進程池中提供排序保證和負載均衡。Consumer Group中的消費者實例數量不能超過度區數量。

三、Kafka用做流處理

在Kafka中，流處理器是指從輸入主題中獲取連續數據流，對輸入進行一些處理並生成連續數據流以輸出主題的任何東西。Kafka提供了徹底集成的Streams API，容許構建執行非重要處理的應用程序，流處理API創建在Kafka提供的核心原語上，使用生產者和使用者API進行輸入，使用Kafka進行狀態存儲，並使用相同的組機制來實現流處理器實例之間的容錯。