本文學習自：官方文檔
Kafka是什么？
Kafka是Apache旗下的一款分布式流媒體平臺，Kafka是一種高吞吐量、持久性、分布式的發布訂閱的消息隊列系統。
它最初由LinkedIn(領英)公司發布，使用Scala語言編寫，與2010年12月份開源，成為Apache的頂級子項目。
它主要用于處理消費者規模網站中的所有動作流數據。動作指(網頁瀏覽、搜索和其它用戶行動所產生的數據)。
消息系統分類
我們知道常見的消息系統有Kafka、RabbitMQ、ActiveMQ等等，但是這些消息系統中所使用的消息模式如下：
Peer-to-Peer (Queue)
簡稱PTP隊列模式，也可以理解為點到點。例如單發郵件，我發送一封郵件給XuWeiLiang，我發送過之后郵件會保存在服務器的云端，當XuWeiLiang打開郵件客戶端并且成功連接云端服務器后，可以自動接收郵件或者手動接收郵件到本地，當服務器云端的郵件被XuWeiLiang消費過之后，云端就不再存儲(這根據郵件服務器的配置方式而定)
名詞解釋：
Producer=生產者
Queue=隊列
Consumer=消費者
Peer-to-Peer模式工作原理：
- 消息生產者
Producer1生產消息到Queue，然后Consumer1從Queue中取出并且消費消息。 - 消息被消費后，
Queue將不再存儲消息，其它所有Consumer不可能消費到已經被其它Consumer消費過的消息。 Queue支持存在多個Producer，但是對一條消息而言，只會有一個Consumer可以消費，其它Consumer則不能再次消費。- 但
Consumer不存在時，消息則由Queue一直保存，直到有Consumer把它消費。
Publish/Subscribe（Topic）
簡稱發布/訂閱模式。例如我微博有30萬粉絲，我今天更新了一條微博，那么這30萬粉絲都可以接收到我的微博更新，大家都可以消費我的消息。
注：以下圖示中的Pushlisher是錯誤的名詞，正確的為Publisher
名詞解釋：
Publisher=發布者
Topic=主題
Subscriber=訂閱者
Publish/Subscribe模式工作原理：
- 消息發布者
Publisher將消息發布到主題Topic中，同時有多個消息消費者Subscriber消費該消息。 - 和PTP方式不同，發布到
Topic的消息會被所有訂閱者消費。 - 當發布者發布消息，不管是否有訂閱者，都不會報錯信息。
- 一定要先有消息發布者，后有消息訂閱者。
注意：Kafka所采用的就是發布/訂閱模式，被稱為一種高吞吐量、持久性、分布式的發布訂閱的消息隊列系統。
常用消息系統對比
- RabbitMQ Erlang編寫，支持多協議 AMQP，XMPP，SMTP，STOMP。支持負載均衡、數據持久化。同時 支持Peer-to-Peer和發布/訂閱模式
- Redis 基于Key-Value對的NoSQL數據庫，同時支持MQ功能，可做輕量級隊列服務使用。就入隊操作而言， Redis對短消息(小于10KB)的性能比RabbitMQ好，長消息的性能比RabbitMQ差。
- ZeroMQ 輕量級，不需要單獨的消息服務器或中間件，應用程序本身扮演該角色，Peer-to-Peer。它實質上是 一個庫，需要開發人員自己組合多種技術，使用復雜度高
- ActiveMQ JMS實現，Peer-to-Peer，支持持久化、XA事務
- Kafka/Jafka 高性能跨語言的分布式發布/訂閱消息系統，數據持久化，全分布式，同時支持在線和離線處理
- MetaQ/RocketMQ 純Java實現，發布/訂閱消息系統，支持本地事務和XA分布式事務
Kafka組件
1.Kafka的三大特點
1.高吞吐量：可以滿足每秒百萬級別消息的生產和消費。
2.持久性：有一套完善的消息存儲機制，確保數據高效安全且持久化。
3.分布式：基于分布式的擴展；Kafka的數據都會復制到幾臺服務器上，當某臺故障失效時，生產者和消費者轉而使用其它的Kafka。
2.流媒體平臺有三個關鍵功能：
1.發布和訂閱記錄流，類似于消息隊列或企業消息傳遞系統。
2.以容錯的持久方式存儲記錄流。
3.記錄發生時處理數據流
3.Kafka通常用于兩大類應用：
1.構建可在系統或應用程序之間可靠獲取數據的實時流數據管道
2.構建轉換或響應數據流的實時流應用程序
4.Kafka的幾個概念
1.Kafka作為一個集群運行在一個或多個服務器上，這些服務器可以跨多個機房，所以說kafka是分布式的發布訂閱消息隊列系統。
2.Kafka集群將記錄流存儲在稱為Topic的類別中。
3.每條記錄由鍵值；"key value"和一個時間戳組成。
5.Kafka的四個核心API：
1. Producer API：生產者API允許應用程序將一組記錄發布到一個或多個Kafka Topic中。
2. Consumer AIP：消費者API允許應用程序訂閱一個或多個Topic，并處理向他們傳輸的記錄流。
3. Streams API：流API允許應用程序充當流處理器，從一個或者多個Topic中消費輸入流，并將輸出流生成為一個或多個輸出主題，從而將輸入流有效地轉換為輸出流。
4. Connector API：連接器API允許構建和運行可重用的生產者或消費者，這些生產者或消費者將Kafka Topic連接到現有的應用程序或數據系統。例如：連接到關系數據庫的連接器可能會捕獲對表的每次更改。
在Kafka中，客戶端和服務器之間的通信采用TCP協議完成，該協議經過版本控制，新版本與舊版本保存向后兼容性，我們為Kafka提供了一個Java客戶端，但是客戶端可以使用多種語言。
#Kafka架構簡介
上圖中只是簡單的畫了一下Kafka的架構，畫的比較亂，但是希望大家能夠仔細看下
- Producer：消息和數據的生產者，主要負責生產
Push消息到指定Broker的Topic中。 - Broker：Kafka節點就是被稱為Broker，Broker主要負責創建Topic，存儲Producer所發布的消息，記錄消息處理的過程，現是將消息保存到內存中，然后持久化到磁盤。
- Topic：同一個Topic的消息可以分布在一個或多個Broker上，一個Topic包含一個或者多個Partition分區，數據被存儲在多個Partition中。
- replication-factor：復制因子；這個名詞在上圖中從未出現，在我們下一章節創建Topic時會指定該選項，意思為創建當前的Topic是否需要副本，如果在創建Topic時將此值設置為1的話，代表整個Topic在Kafka中只有一份，該復制因子數量建議與Broker節點數量一致。
- Partition：分區；在這里被稱為Topic物理上的分組，一個Topic在Broker中被分為1個或者多個Partition，也可以說為每個Topic包含一個或多個Partition，(一般為kafka節. 點數CPU的總核心數量)分區在創建Topic的時候可以指定。分區才是真正存儲數據的單元。
- Consumer：消息和數據的消費者，主要負責主動到已訂閱的Topic中拉取消息并消費，為什么Consumer不能像Producer一樣的由Broker去push數據呢？因為Broker不知道Consumer能夠消費多少，如果push消息數據量過多，會造成消息阻塞，而由Consumer去主動pull數據的話，Consumer可以根據自己的處理情況去pull消息數據，消費完多少消息再次去取。這樣就不會造成Consumer本身已經拿到的數據成為阻塞狀態。
- ZooKeeper：ZooKeeper負責維護整個Kafka集群的狀態，存儲Kafka各個節點的信息及狀態，實現Kafka集群的高可用，協調Kafka的工作內容。
我們可以看到上圖，Broker和Consumer有使用到ZooKeeper，而Producer并沒有使用到ZooKeeper，因為Kafka從0.8版本開始，Producer并不需要根據ZooKeeper來獲取集群狀態，而是在配置中指定多個Broker節點進行發送消息，同時跟指定的Broker建立連接，來從該Broker中獲取集群的狀態信息，這是Producer可以知道集群中有多少個Broker是否在存活狀態，每個Broker上的Topic有多少個Partition，Prodocuer會講這些元信息存儲到Producuer的內存中。如果Producoer像集群中的一臺Broker節點發送信息超時等故障，Producer會主動刷新該內存中的元信息，以獲取當前Broker集群中的最新狀態，轉而把信息發送給當前可用的Broker，當然Prodocuer也可以在配置中指定周期性的去刷新Broker的元信息以更新到內存中。
注意：只有Broker和ZooKeeper才是服務，而Producer和Consumer只是Kafka的SDK罷了
基本特性
可擴展：
1.在不需要下線的情況下進行擴容
2.數據流分區(Partition)存儲在多個機器上
高性能：
1.單個Broker節點就能服務上千個客戶端
2.單個Broker節點每秒鐘讀/寫可達每秒幾百兆字節
3.多個Brokers組成的集群將達到非常強的吞吐能力
4.性能穩定，無論數據多大
5.Kafka在底層棄用了Java堆緩存機制，采用了操作系統級別的頁緩存，同時將隨機寫操作改為順序寫，再結合Zero-Copy的特性極大地改善了IO性能。
持久存儲：
1.存儲在磁盤上
2.冗余備份到其它服務器上以防止節點故障及丟失
主題和日志
主題和日志官方被稱為是Topic and log
Topic是記錄發布到的類別或者訂閱源的名稱，Kafka的Topic總是多用戶的；也就是說，一個Topic可以有零個，一個或者多個消費者訂閱寫入它的數據。
每個Topic，Kafka集群都為一個Partition分區日志，如下圖所示：
每個Partition分區都是一個有序的記錄序列(不可變),如果有新的日志會按順序結構化添加到末尾，分區中的記錄每個都按順序的分配一個ID號，稱之為偏移量，在整個Partition中具有唯一性。如上圖所示，有Partition、Partition1、Partition2，其中日志寫入的順序從Old到New，ID號從0-12等。
Kafka集群發布過的消息記錄會被持久化到硬盤中，無論該消息是否被消費，發布記錄都會被Kafka保留到硬盤當中，我們可以設置保留期限。例如，如果保留策略我們設置為兩天，則在發布記錄的兩天內，該消息可供使用，之后則被Kafka丟棄以釋放空間，Kafka的性能在數據大小方面是非常出色的，可以長時間保留數據不成問題。
實際上，以消費者為單位地保留的唯一元數據是消費者在日志中的偏移或位置。這個偏移量由消費者控制的：消費者通常會在讀取記錄時線性地推進偏移量，但事實上，由于消費者的位置時由消費者控制的，所以它可以按照自己喜歡的任何順序進行消費記錄。例如，消費者可以重置之前的偏移量來處理之前的數據，或者直接從最新的偏移量開始消費。
這些功能的組合意味著Kafka消費者非常的不值一提，他們可以很隨便，即使這樣，對集群或者其他消費者沒有太大影響。例如：可以使用命令工具來“tail”任何Topic的內容，而不會更改任何現有使用者所使用的內容。
日志中分區有幾個用途。首先，他們允許日志的大小超出適合單臺服務器的大小，每個單獨的分區必須適合托管它的服務器，但是一個主題可能有許多分區，因此它可以處理任意數量的數據，其次，他們作為并行的單位-更多的是在一點上。
Distribution(分布)
日志Partition分區分布在Kafka集群中的服務器上，每臺服務器都處理數據并請求共享分區。為了實現容錯，每個Partition分區被復制到多個可配置的Kafka集群中的服務器上。
名詞介紹：
leader：領導者
followers：追隨者
每個Partition分區都有一個"leader"(領導者)服務器，是每個Partition分區，假如我們的Partition1分區分別被復制到了三臺服務器上，其中第二臺為這個Partition分區的領導者，其它兩臺服務器都為這個Partition的followers(追隨者)。其中Partition分片的leader(領導者)處理該Partition分區的所有讀和寫請求，而follower(追隨者)被動地復制leader(領導者)所發生的改變，如果該Partition分片的領導者發生了故障等，兩個follower(追隨者)中的其中一臺服務器將自動成為新的leader領導者。每臺服務器都充當一些分區的leader(領導者)和一些分區的follower(追隨者)，因此集群內的負載非常平衡。
注意：我們上面講的leader和follower僅僅是每個Partition分區的領導者和追隨者，并不是我們之前學習到的整個集群的主節點和備節點，希望大家不要混淆。
Geo-Replication(地域復制)
Kafka Mirrormaker為集群提供地域復制支持，使用MirrorMaker，可以跨多個機房或云端來復制數據，可以在主動/被動方案中使用它進行備份和恢復；在主動方案中，可以使數據更接近用戶，或支持數據位置要求。
Producers(生產者)
生產者將數據發布到他們選擇的Topic，生產者負責選擇分配給Topic中的哪個分區的記錄。這可以通過循環方式來完成，只是為了負載均衡，或者可以根據一些語義分區函數(比如基于記錄中的某個鍵)來完成。
Consumers(消費者)
名詞介紹：
Consumers：消費者
Consumers Group：消費者組
Consumers Group name：消費者組名
Consumers使用Consumers Group name標記自己，并且發布到Topic的每個記錄被傳遞到每個訂閱Consumers Group中的一個Consumers實例，Consumers實例可以在單獨的進程中，也可以在不同的機器，如果所有Consumers實例具有相同的Consumers Group，則記錄將有效地在Consumers上進行負載均衡。
如果所有Consumers實例在不同的Consumers Group中，則每個記錄將廣播到所有Consumers進程中。
兩個Kafka Cluster，托管了四個Partition(分區)，從P0-P3，包含兩個Consumers Group分別是Consumer Group A和Consumer Group B，Consumners Group A有兩個Consumers實例，B有四個Consumers實例。也就是消費者A組有兩個消費者，B組有四個消費者。
然后，更常見的是，我們發現Topic有少量的Consumers Group，每個消費者對應一個用戶組，每個組有許多消費者實例組成，用于可伸縮和容錯，這只不過是發布/訂閱語義，其中訂閱者是一組消費者，而不是單個進程。
在Kfaka中實現消費者的方式是通過在消費者實例上劃分日志中的Partition分區，以便每個實例在任何時間點都是分配的“相同份額”，維護消費者組成功資格的過程由Kafka動態協議實現，如果新的消費者實例加入該消費者組，新消費者實例將從該組的其它成員手里接管一些分區；如果消費者實例故障，其分區將分發給其余消費者實例。
Kafka僅提供分區內記錄的總順序，而不是Topic中不同分區之間的記錄。對于大多數應用程序而言，按分區排序和按鍵分許數據的能力已經足夠，但是如果你需要記錄總順序，則可以使用只有一個分區的Topic來實現，盡管這意味著每個消費者組只有一個消費者進程。
Consumer Group
我們開始處有講到消息系統分類：P-T-P模式和發布/訂閱模式，也有說到我們的Kafka采用的就是發布訂閱模式，即一個消息產生者產生消息到Topic中，所有的消費者都可以消費到該條消息，采用異步模型；而P-T-P則是一個消息生產者生產的消息發不到Queue中，只能被一個消息消費者所消費，采用同步模型
其實發布訂閱模式也可以實現P-T-P的模式，即將多個消費者加入一個消費者組中，例如有三個消費者組，每個組中有3個消息消費者實例，也就是共有9個消費者實例，如果當Topic中有消息要接收的時候，三個消費者組都會去接收消息，但是每個人都接收一條消息，然后消費者組再將這條消息發送給本組內的一個消費者實例，而不是所有消費者實例，到最后也就是只有三個消費者實例得到了這條消息，當然我們也可以將這些消費者只加入一個消費者組，這樣就只有一個消費者能夠獲得到消息了。
Guarantees(擔保)
在高級別的Kafka中提供了以下保證：
- 生產者發送到特定Topic分區的消息將按照其發送順序附加。也就是說，如果一個Producers生產者發送了M1和M2，一般根據順序來講，肯定是先發送的M1，隨后發送的M2，如果是這樣，假如M1的編號為1，M2的編號為2，那么在日志中就會現有M1，隨后有M2。
- 消費者實例按照他們存儲在日志中的順序查看記錄。
- 對于具有復制因子N的Topic，Kafka最多容忍N-1個服務器故障，則不會丟失任何提交到日志的記錄。
本文鏈接：http://www.thecarconnectin.com/34283.html
網友評論comments