Apache Kafka-初体验Kafka(01)-入门整体认识kafka
文章目錄
- kafka官方文檔
- 使用場景
- Kafka基本概念
- 消息( Message )相關術語
- 主題Topic & 消息日志Log
- 分布式Distribution
- Producers
- Consumers
- 消費順序
kafka官方文檔
官網： https://kafka.apache.org/
快速開始： https://kafka.apache.org/documentation/#quickstart
Kafka是最初由Linkedin公司開發，是一個分布式、支持分區的（partition）、多副本的（replica），基于zookeeper協調的分布式消息系統 .
Kafka的最大的特性就是可以實時的處理大量數據以滿足各種需求場景：比如基于hadoop的批處理系統、低延遲的實時系統、storm/Spark流式處理引擎，web/nginx日志、訪問日志，消息服務等等.
Kafka用scala語言編寫，Linkedin于2010年貢獻給了Apache基金會并成為頂級開源 項目。
使用場景
- 日志收集：一個公司可以用Kafka可以收集各種服務的log，通過kafka以統一接口服務的方式開放給各種 consumer，例如hadoop、Hbase、ES等
- 消息系統：解耦和生產者和消費者、緩存消息等
- 用戶活動跟蹤： 記錄web用戶或者app用戶的各種活動，如瀏覽網頁、搜索、點擊等活動，這些活動信息被各個服務器發布到kafka的topic中，然后訂閱者通過訂閱這些topic來做實時的監控分析，或者裝載到 hadoop、數據倉庫中做離線分析和挖掘
- 運營指標： 收集各種分布式應用的數據，生產各種操作的集中反 饋，比如報警和報告
我們來看個常見的系統架構圖
Kafka基本概念
kafka是一個分布式的，分區的消息(官方稱之為 commit log )服務。
它提供一個消息系統應該具備的功能，但是確有著獨特的設計，Kafka借鑒了JMS規范的思想，但是確并沒有完全遵循JMS規范。
消息( Message )相關術語
首先，我們來看一下基礎的消息( Message )相關術語：
| Broker | 消息中間件處理節點，一個Kafka節點就是一個broker，一個或者多個Broker可以組成一個Kafka集群 |
| Topic | Kafka根據topic對消息進行歸類，發布到Kafka集群的每條消息都需要指定一個topic |
| Producer | 消息生產者，向Broker發送消息的客戶端 |
| Consumer | 消息消費者，從Broker讀取消息的客戶端 |
| ConsumerGroup | 每個Consumer屬于一個特定的ConsumerGroup，一條消息可以被多個不同的Consumer Group消費，但是一個Consumer Group中只能有一個Consumer能夠消費該消息 |
| Partition | 物理上的概念，一個topic可以分為多個partition，每個partition內部消息是有序的 |
因此，從一個較高的層面上來看，producer通過網絡發送消息到Kafka集群，然后consumer來進行消費,如下圖：
服務端(brokers)和客戶端(producer、consumer)之間通信通過TCP協議來完成。
主題Topic & 消息日志Log
讓我們首先深入理解Kafka提出一個高層次的抽象概念-Topic。
Topic是一個類別的名稱，同類消息發送到同一個Topic下面。對于每一個Topic，下面可以有多個分區(Partition)日志文件.
Partition是一個有序的message序列，這些message按順序添加到一個叫做commit log的文件中。
每個partition中的消息都有一個唯一的編號，稱之為offset，用來唯一標示某個分區中的message。
注：每個partition，都對應一個commit log文件。一個partition中的message的offset都是唯一的，但是不同的partition中的message的offset可能是相同的
可以這么來理解Topic，Partition和Broker：
一個topic，代表邏輯上的一個業務數據集，比如按數據庫里不同表的數據操作消息區分放入不同topic，訂單相關操作消息放入訂單topic，用戶相關操作消息放入用戶topic.
對于大型網站來說，后端數據都是海量的，訂單消息很可能是非常巨量的，比如有幾百個G甚至達到TB級別，如果把這么多數據都放在一臺機器上可定會有容量限制問題，那么就可以topic內部劃分多個partition來分片存儲數據，不同的partition可以位于不同的機器上，每臺機器上都運行一個Kafka的進程Broker.
kafka集群，在配置的時間范圍內，維護所有的由producer生成的消息，而不管這些消息有沒有被消費.
例如日志保留(log retention )時間被設置為2天。kafka會維護最近2天生產的所有消息，而2天前的消息會被丟棄。kafka的性能與保留的數據量的大小沒有關系，因此保存大量的數據(日志信息)不會有什么影響。
每個consumer是基于自己在commit log中的消費進度(offset)來進行工作的。在kafka中，消費offset由consumer自己來維護；一般情況下我們按照順序逐條消費commit log中的消息，當然我可以通過指定offset來重復消費某些消息，或者跳過某些消息。
這意味kafka中的consumer對集群的影響是非常小的，添加一個或者減少一個consumer，對于集群或者其他consumer來說，都是沒有影響的，因為每個consumer維護各自的offset。所以說kafka集群是無狀態的，性能不會因為consumer數量受太多影響。kafka還將很多關鍵信息記錄在zookeeper里，保證自己的無狀態，從而在水平擴容時非常方便。
為什么要對Topic下數據進行分區存儲？
分布式Distribution
log的partitions分布在kafka集群中不同的broker上，每個broker可以請求備份其他broker上partition上的數據。kafka集群支持配置一個partition備份的數量。
針對每個partition，都有一個broker起到“ leader ”的作用，0個或多個其他的broker作為“ follwers ”的作用。
leader處理所有的針對這個partition的讀寫請求，而followers被動復制leader的結果。如果這個leader失效了，其中的一個follower將會自動的變成新的leader。
Producers
生產者將消息發送到topic中去，同時負責選擇將message發送到topic的哪一個partition中。通過 round--robin 做簡單的負載均衡。也可以根據消息中的某一個關鍵字來進行區分。通常第二種方式使用的更多。
Consumers
傳統的消息傳遞模式有2種：隊列( queue) 和（publish-subscribe）
- queue模式：多個consumer從服務器中讀取數據，消息只會到達一個consumer。
- publish-subscribe模式：消息會被廣播給所有的consumer。
Kafka基于這2種模式提供了一種consumer的抽象概念： consumer group 。
- queue模式：所有的consumer都位于同一個consumer group 下。
- publish-subscribe模式：所有的consumer都有著自己唯一的consumer group。
圖例說明： 由2個broker組成的kafka集群，總共有4個partition(P0-P3)。這個集群由2個Consumer Group， A有2個consumer instances ，B有四個。
可以看到，每個Consumer屬于一個特定的ConsumerGroup，一條消息可以被多個不同的Consumer Group消費，但是一個Consumer Group中只能有一個Consumer能夠消費該消息 。
通常一個topic會有幾個consumer group，每個consumer group都是一個邏輯上的訂閱者（ logicalsubscriber ）。每個consumer group由多個consumer instance組成，從而達到可擴展和容災的功能。
消費順序
Kafka比傳統的消息系統有著更強的順序保證。
一個partition同一個時刻在一個consumer group中只有一個consumer instance在消費，從而保證順序 。 consumer group中的consumer instance的數量不能比一個Topic中的partition的數量多，否則，多出來的consumer消費不到消息。
Kafka只在partition的范圍內保證消息消費的局部順序性，不能在同一個topic中的多個partition中保證總的消費順序性。
如果有在總體上保證消費順序的需求，那么我們可以通過將topic的partition數量設置為1，將consumer group中的consumer instance數量也設置為1。
從較高的層面上來說的話，Kafka提供了以下的保證：
- 發送到一個Topic中的message會按照發送的順序添加到commit log中。意思是，如果消息 M1，M2由同一個producer發送，M1比M2發送的早的話，那么在commit log中，M1的offset就會比commit 2的offset小。
- 一個consumer在commit log中可以按照發送順序來消費message。
- 如果一個topic的備份因子設置為N，那么Kafka可以容忍N-1個服務器的失敗，而存儲在commit log中的消息不會丟失。
總結
以上是生活随笔為你收集整理的Apache Kafka-初体验Kafka(01)-入门整体认识kafka的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： RocketMQ-初体验RocketMQ
- 下一篇： Apache Kafka-初体验Kafk