kafka（一）：介紹和架構、應用場景和同類型比對

@[toc]

說明

• 當前大數據開發流程，從最初的批處理到流處理再到流批一體，技術方案也從MapReduce到spark在到flink，那麼如何將實時數據穩定、高效、靈活的傳送到計算引擎裏呢，這裏必須使用到分佈式消息引擎kafka。

kafka簡介

什麼是kafka

• kafka最初由LinkedIn使用Scala進行開發，後來使用Java重寫Producer API、Consumer API，2011年初加入Apache開源項目，2012年10月從Apache Incubator畢業，成爲Apache頂級項目，即Apache Kafka。
• kafka獨立於hadoop之外，支持獨立和分佈式安裝，分佈式控制中心統一由zookeeper擔任，所以安裝時，必須安裝zookeeper。
• 官網

kafka高吞吐率實現

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

kafka消息傳遞模式

點對點模型

• 基於拉取或輪詢的消息傳送模型，由消費者主動拉取數據，客戶端需要持續開啓獨立線程監控隊列中是否有數據。
• 在點對點的消息系統中，消息保留在隊列中， 一個或多個消費者可以同時工作，但最終只有一個消費者可以消費消息。典型實例如訂單處理系統，多個訂單處理器可以同時工作，但對於一個特定的訂單，只有其中一個訂單處理器可以拿到並進行處理。

發佈/訂閱模型

• 基於推送的消息傳送模型，由MQ主動推送消息給所有訂閱者，即使某個訂閱者不可用。
• 在發佈-訂閱系統中，消息被保留在主題中。消費者可以訂閱一個或多個主題並使用主題中的所有消息。在發佈-訂閱系統中，消息生產者稱爲發佈者，消息消費者稱爲訂閱者。

kafka優點

• 解耦：解耦業務處理過程，兩端業務流程僅通過消息API通信，兩端程序可獨立升級。
• 冗餘：消息默認進行持久化，直到消息被完全處理，規避數據丟失風險。
• 擴展性：kafka支持動態擴容，緩解集羣壓力。
• 可恢復性：系統的一部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復後被處理。
• 順序保證：Kafka保證一個Partition內的消息的有序性。
• 緩衝：消息隊列通過一個緩衝層來幫助任務最高效率的執行，寫入隊列的處理會盡可能的快速。緩衝有助於控制和優化數據流經過系統的速度。
• 異步通信：消息隊列提供了異步處理機制，允許用戶把消息放入隊列，但並不立即處理，在需要時再處理。

kafka架構

架構圖

主要構成

Record

• Record即Kafka消息，是Kafka處理的主要對象。

TOPIC

• Topic是承載Kafka消息數據的邏輯容器，用於區分具體的業務，但在物理上，不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存在一個或多個Broker上，但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存儲在何處。

partition

• Topic被分割爲一個或多個Partition，Partition是一個物理概念，對應一個或若干個目錄。Partition內部的消息是有序的，Partition間的消息是無序的。
• Kafka Broker配置文件中的num.partitions參數用於指定Topic的Partition數量，在創建Topic時也可以通過partitions參數指定Partition數量。

Broker

• Kafka集羣包含一個或多個服務器，每個服務器節點稱爲一個Broker。 Broker存儲Topic的數據。如果某Topic有N個Partition，集羣有N個Broker，那麼每個Broker存儲該Topic的一個Partition。
• 如果某Topic有N個Partition，集羣有(N+M)個Broker，那麼其中有N個Broker各存儲Topic的一個Partition，剩下的M個Broker不存儲Topic的Partition數據。
• 如果某Topic有N個Partition，集羣中Broker數目少於N個，那麼每個Broker存儲Topic的一個或多個Partition。實際生產環境中應儘量避免，否則容易導致Kafka集羣數據不均衡。

producer

• Producer（生產者）是消息的發佈者，生產者負責選擇將消息數據分配給Topic中的某個分區，即生產者生產的每一條消息，會被寫入到某一個Partition。

Consumer

• Consumer（消費者）從Broker中消費消息，一個Consumer可以消費多個Topic的消息，也可以消費同一個Topic中的多個Partition中的消息，Partition允許多個Consumer同時消費，以提高Kafka Broker的吞吐量。

Consumer Group

• Consumer Group是Kafka提供的可擴展且具有容錯性的消費者機制，多個消費者實例共同組成的一個組，同時消費多個分區以實現高吞吐。Consumer Group內可以有多個消費者，共享一個公共的ID，即Group ID，Consumer Group內的所有消費者協調在一起來消費訂閱Topic的所有分區。

• Kafka保證同一個Consumer Group中只有一個Consumer會消費某條消息，Kafka保證的是穩定狀態下每一個Consumer 實例只會消費某一個或多個特定的Partition，而某個Partition的數據只會被某一個特定的Consumer實例所消費。

• 如上圖，兩臺Broker組成的Kafka羣集，包含四個屬於兩個Consumer Group的分區（P0-P3）。Consumer Group A有兩個消費者實例，Consumer Group B有四個消費者實例。

partition Replica

• Replica（分區副本）爲了防止消息丟失而創建的分區備份。Kafka中同一條消息能夠被拷貝到多個地方以提供數據冗餘。副本分爲領導者副本和追隨者副本，各自有不同的角色劃分。副本是在分區層級下的，即每個分區可配置多個副本實現高可用。

Partition Leader

• 每個Partition有多個副本，其中有且僅有一個作爲Leader，Leader是當前負責消息讀寫的Partition，所有讀寫操作只能發生於Leader分區上。

Partition Follower

• 用於同步Leader和Replica消息，保持消息同步。Leader與Follower的關係是主備關係，而非主從。

Zookeeper

• Apache Zookeeper是一個分佈式配置和同步服務，是Kafka的一個核心依賴，它是Broker和Consumer之間的協調接口。Broker在Zookeeper中存儲基本元數據，通過Zookeeper集羣共享信息，例如主題、代理、消費者偏移(隊列讀取器)等的信息。Zookeeper負責維護和協調Broker以及Broker Controller的選舉。
• Kafka 0.9版本前，offset（消息位移）由Zookeeper負責管理。

應用場景

存儲系統

• 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提供了完全集成的Streams API，允許構建執行非重要處理的應用程序，流處理API建立在Kafka提供的核心原語上，使用生產者和使用者API進行輸入，使用Kafka進行狀態存儲，並使用相同的組機制來實現流處理器實例之間的容錯。
• 輕量級可使用，核心重要處理不建議使用。

同類型比對

Flume

• Flume是Cloudera提供的一個高可用的，高可靠的，分佈式的海量日誌採集、聚合和傳輸的系統，Flume支持在日誌系統中定製各類數據發送方，用於收集數據；同時，Flume提供對數據進行簡單處理，並寫到各種數據接受方（可定製）的能力，過程依賴於hadoop，操作過程基於channel（大多基於內存），資源佔用較大，巨量數據處理時，效率不高。
• 實際使用體驗，兼顧採集和輕量化的數據處理，既採集數據又計算處理，個人兩種場景能力都一般，建議使用功能專一組件，kafka+flink或kafka+spark。

RabbitMQ

• RabbitMQ是使用Erlang編寫的一個開源的重量級企業級消息隊列，本身支持很多的協議：AMQP、XMPP、SMTP、STOMP。RabbitMQ實現了Broker構架，消息在發送給客戶端時先在中心隊列排隊，對路由、負載均衡或者數據持久化支持很好。

Redis

• Redis是一個基於Key-Value對的NoSQL數據庫，但支持MQ功能，可以作爲輕量級的MQ使用。入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而如果數據大小超過10K，Redis較慢；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低於Redis。

ZeroMQ

• ZeroMQ能夠實現RabbitMQ不擅長的高級/複雜的隊列，但開發人員需要自己組合多種技術框架，技術上的複雜度是對ZeroMQ能夠應用成功的挑戰。ZeroMQ具有一個獨特的非中間件的模式，不需要安裝和運行消息服務器或中間件，應用程序會扮個服務器角色，但ZeroMQ僅提供非持久性的隊列。

ActiveMQ

• ActiveMQ能夠以代理人和點對點的技術實現隊列，少量代碼就可以高效地實現高級應用場景。

RocketMQ

• Apache RocketMQ是阿里開源的純Java實現的分佈式消息中間件，支持事務消息、順序消息、批量消息、定時消息、消息回溯等。
• 不建議使用，可能斷更可參考Dubbo

總結

• 流處理是大數據未來趨勢，網絡發達個人數據劇增的當下，實時加載算法分析處理用戶數據，如廣告精確推送、影視推薦、個人畫像、異常訪問分析等，都有很大需要，數據的核心價值是信息，而實時計算能加強這種價值。
• 學海無涯，任重道遠，加油。