深入解析kafka 架構原理
更新時間：2021年11月26日 12:00:01 作者：程序員耕耘
Kafka使用領域非常廣泛，在大數(shù)據(jù)時代kafka使用真香，LinkedIn、Microsoft和Netflix每天都用Kafka處理萬億級的信息。本文就讓我們一起來大白話kafka的架構原理，感興趣的朋友一起看看吧
?kafka 架構原理
大數(shù)據(jù)時代來臨，如果你還不知道Kafka那就真的out了！據(jù)統(tǒng)計，有三分之一的世界財富500強企業(yè)正在使用Kafka，包括所有TOP10旅游公司，7家TOP10銀行，8家TOP10保險公司，9家TOP10電信公司等等。LinkedIn、Microsoft和Netflix每天都用Kafka處理萬億級的信息。本文就讓我們一起來大白話kafka的架構原理。
kafka官網(wǎng)：http://kafka.apache.org/
01 kafka簡介
Kafka最初由Linkedin公司開發(fā)，是一個分布式的、分區(qū)的、多副本的、多訂閱者，基于zookeeper協(xié)調的分布式日志系統(tǒng)（也可以當做MQ系統(tǒng)），常用于web/nginx日志、訪問日志、消息服務等等，Linkedin于2010年貢獻給了Apache基金會并成為頂級開源項目。
02 kafka的特性
- 高吞吐量、低延遲：kafka每秒可以處理幾十萬條消息，它的延遲最低只有幾毫秒；
- 可擴展性：kafka集群支持熱擴展；
- 持久性、可靠性：消息被持久化到本地磁盤，并且支持數(shù)據(jù)備份防止丟失；
- 容錯性：允許集群中的節(jié)點失敗(若分區(qū)副本數(shù)量為n,則允許n-1個節(jié)點失敗)；
- 高并發(fā)：單機可支持數(shù)千個客戶端同時讀寫；
03 kafka的應用場景
- 日志收集：一個公司可以用Kafka收集各種服務的log，通過kafka以統(tǒng)一接口開放給各種消費端，例如hadoop、Hbase、Solr等。
- 消息系統(tǒng)：解耦生產(chǎn)者和消費者、緩存消息等。
- 用戶活動跟蹤：Kafka經(jīng)常被用來記錄web用戶或者app用戶的各種活動，如瀏覽網(wǎng)頁、搜索記錄、點擊等活動，這些活動信息被各個服務器發(fā)布到kafka的topic中，然后訂閱者通過訂閱這些topic來做實時的監(jiān)控分析，或者裝載到hadoop、數(shù)據(jù)倉庫中做離線分析和挖掘。
- 運營指標：Kafka也經(jīng)常用來記錄運營監(jiān)控數(shù)據(jù)。
- 流式處理
04 kafka架構（重頭戲!）
下面是一個kafka的架構圖，
整體來看，kafka架構中包含四大組件：生產(chǎn)者、消費者、kafka集群、zookeeper集群。對照上面的結構圖，我們先來搞清楚幾個很重要的術語，（看圖！對照圖理解~）
1、broker
kafka 集群包含一個或多個服務器，每個服務器節(jié)點稱為一個broker。
2、topic
每條發(fā)布到kafka集群的消息都有一個類別，這個類別稱為topic，其實就是將消息按照topic來分類，topic就是邏輯上的分類，同一個topic的數(shù)據(jù)既可以在同一個broker上也可以在不同的broker結點上。
3、partition
分區(qū)，每個topic被物理劃分為一個或多個分區(qū)，每個分區(qū)在物理上對應一個文件夾，該文件夾里面存儲了這個分區(qū)的所有消息和索引文件。在創(chuàng)建topic時可指定parition數(shù)量，生產(chǎn)者將消息發(fā)送到topic時，消息會根據(jù) 分區(qū)策略 追加到分區(qū)文件的末尾，屬于順序寫磁盤，因此效率非常高（經(jīng)驗證，順序寫磁盤效率比隨機寫內存還要高，這是Kafka高吞吐率的一個很重要的保證）。
上面提到了分區(qū)策略，所謂分區(qū)策略就是決定生產(chǎn)者將消息發(fā)送到哪個分區(qū)的算法。Kafka 為我們提供了默認的分區(qū)策略，同時它也支持自定義分區(qū)策略。kafka允許為每條消息設置一個key，一旦消息被定義了 Key，那么就可以保證同一個 Key 的所有消息都進入到相同的分區(qū)，這種策略屬于自定義策略的一種，被稱作"按消息key保存策略"，或Key-ordering 策略。
同一主題的多個分區(qū)可以部署在多個機器上，以此來實現(xiàn) kafka 的伸縮性。同一partition中的數(shù)據(jù)是有序的，但topic下的多個partition之間在消費數(shù)據(jù)時不能保證有序性，在需要嚴格保證消息順序消費的場景下，可以將partition數(shù)設為1，但這種做法的缺點是降低了吞吐，一般來說，只需要保證每個分區(qū)的有序性，再對消息設置key來保證相同key的消息落入同一分區(qū)，就可以滿足絕大多數(shù)的應用。
4、offset
partition中的每條消息都被標記了一個序號，這個序號表示消息在partition中的偏移量，稱為offset，每一條消息在partition都有唯一的offset，消息者通過指定offset來指定要消費的消息。
正常情況下，消費者在消費完一條消息后會遞增offset，準備去消費下一條消息，但也可以將offset設成一個較小的值，重新消費一些消費過的消息，可見offset是由consumer控制的，consumer想消費哪一條消息就消費哪一條消息，所以kafka broker是無狀態(tài)的，它不需要標記哪些消息被消費過。
5、producer
生產(chǎn)者，生產(chǎn)者發(fā)送消息到指定的topic下，消息再根據(jù)分配規(guī)則append到某個partition的末尾。
6、consumer
消費者，消費者從topic中消費數(shù)據(jù)。
7、consumer group
消費者組，每個consumer屬于一個特定的consumer group，可為每個consumer指定consumer group，若不指定則屬于默認的group。
同一topic的一條消息只能被同一個consumer group內的一個consumer消費，但多個consumer group可同時消費這一消息。這也是kafka用來實現(xiàn)一個topic消息的廣播和單播的手段，如果需要實現(xiàn)廣播，一個consumer group內只放一個消費者即可，要實現(xiàn)單播，將所有的消費者放到同一個consumer group即可。
用consumer group還可以將consumer進行自由的分組而不需要多次發(fā)送消息到不同的topic。
8、leader
每個partition有多個副本，其中有且僅有一個作為leader，leader會負責所有的客戶端讀寫操作。
9、follower
follower不對外提供服務，只與leader保持數(shù)據(jù)同步，如果leader失效，則選舉一個follower來充當新的leader。當follower與leader掛掉、卡住或者同步太慢，leader會把這個follower從ISR列表中刪除，重新創(chuàng)建一個follower。
10、rebalance
同一個consumer group下的多個消費者互相協(xié)調消費工作，我們這樣想，一個topic分為多個分區(qū)，一個consumer group里面的所有消費者合作，一起去消費所訂閱的某個topic下的所有分區(qū)(每個消費者消費部分分區(qū))，kafka會將該topic下的所有分區(qū)均勻的分配給consumer group下的每個消費者，如下圖，
rebalance表示"重平衡"，consumer group內某個消費者掛掉后，其他消費者自動重新分配訂閱主題分區(qū)的過程，是 Kafka 消費者端實現(xiàn)高可用的重要手段。如下圖Consumer Group A中的C2掛掉，C1會接收P1和P2，以達到重新平衡。同樣的，當有新消費者加入consumer group，也會觸發(fā)重平衡操作。
05 對kafka架構的幾點解釋
- 一個典型的kafka集群中包含若干producer，若干broker（Kafka支持水平擴展，一般broker數(shù)量越多，集群吞吐率越高），若干consumer group，以及一個zookeeper集群。kafka通過zookeeper協(xié)調管理kafka集群，選舉分區(qū)leader，以及在consumer group發(fā)生變化時進行rebalance。
- kafka的topic被劃分為一個或多個分區(qū)，多個分區(qū)可以分布在一個或多個broker節(jié)點上，同時為了故障容錯，每個分區(qū)都會復制多個副本，分別位于不同的broker節(jié)點，這些分區(qū)副本中（不管是leader還是follower都稱為分區(qū)副本），一個分區(qū)副本會作為leader，其余的分區(qū)副本作為follower。其中l(wèi)eader負責所有的客戶端讀寫操作，follower不對外提供服務，僅僅從leader上同步數(shù)據(jù)，當leader出現(xiàn)故障時，其中的一個follower會頂替成為leader，繼續(xù)對外提供服務。
- 對于傳統(tǒng)的MQ而言，已經(jīng)被消費的消息會從隊列中刪除，但在Kafka中被消費的消息也不會立馬刪除，在kafka的server.propertise配置文件中定義了數(shù)據(jù)的保存時間，當文件到設定的保存時間時才會刪除，
# 數(shù)據(jù)的保存時間(單位:小時，默認為7天)
log.retention.hours=168
因為Kafka讀取消息的時間復雜度為O(1)，與文件大小無關，所以這里刪除過期文件與提高Kafka性能并沒有關系，所以選擇怎樣的刪除策略應該考慮磁盤以及具體的需求。
- 點對點模式 VS 發(fā)布訂閱模式
傳統(tǒng)的消息系統(tǒng)中，有兩種主要的消息傳遞模式：點對點模式、發(fā)布訂閱模式。
①點對點模式?
生產(chǎn)者發(fā)送消息到queue中，queue支持存在多個消費者，但是對一個消息而言，只可以被一個消費者消費，并且在點對點模式中，已經(jīng)消費過的消息會從queue中刪除不再存儲。
②發(fā)布訂閱模式
生產(chǎn)者將消息發(fā)布到topic中，topic可以被多個消費者訂閱，且發(fā)布到topic的消息會被所有訂閱者消費。而kafka就是一種發(fā)布訂閱模式。
- 消費端 pull 和 push
① push方式：由消息中間件主動地將消息推送給消費者；
優(yōu)點：優(yōu)點是不需要消費者額外開啟線程監(jiān)控中間件，節(jié)省開銷。
缺點：無法適應消費速率不相同的消費者。因為消息的發(fā)送速率是broker決定的，而消
費者的處理速度又不盡相同，所以容易造成部分消費者空閑，部分消費者堆積，造成緩
沖區(qū)溢出。
② pull方式：由消費者主動向消息中間件拉取消息；
優(yōu)點：消費端可以按處理能力進行拉??；
缺點：消費端需要另開線程監(jiān)控中間件，有性能開銷；
對于Kafka而言，pull模式更合適。pull模式可簡化broker的設計，Consumer可自主控制消費消息的速率，同時Consumer可以自己控制消費方式，既可批量消費也可逐條消費，同時還能選擇不同的提交方式從而實現(xiàn)不同的傳輸語義。
06 kafka和rabbitMQ對比
|
RabbitMQ |
Kafka |
|
|
開發(fā)語言 |
erlang |
scala，Java |
|
架構模型 |
① 遵循AMQP； ② 生產(chǎn)者、消費者、broker。 ③ broker由exchange、binding、queue組成； ④ consumer消費位置由broker通過確認機制保存； |
① 不遵循AMQP； ② 生產(chǎn)者、消費者、kafka集群、zookeeper集群； ③ kafka集群由多個broker節(jié)點組成，消息按照topic分類，每個topic又劃分為多個partition； ④ broker無狀態(tài)，offset由消費者指定； |
|
可靠性 |
RabbitMQ可靠性更好，支持事務，支持消息確認機制 |
|
|
高可用 |
采用鏡像隊列，即主從模式，數(shù)據(jù)是異步同步的，當消息過來，主從全部寫完后，回ack，這樣保障了數(shù)據(jù)的一致性。 |
每個分區(qū)都有一個或多個副本，這些副本保存在不同的broker上，其中有且僅有一個分區(qū)副本作為leader，其余的作為follower，當leader不可用時，會選舉follower作為新leader繼續(xù)提供服務。 只有l(wèi)eader提供讀寫服務，follower從leader同步拉取數(shù)據(jù)然后備份。 |
|
吞吐量 |
kafka更高 |
|
|
是否支持事務 |
支持 |
不支持 |
|
負載均衡 |
需要外部支持才能實現(xiàn)（如：loadbalancer） |
kafka利用zk和分區(qū)機制實現(xiàn)負載均衡 |
|
是否支持消費者Push |
不支持 |
支持 |
|
是否支持消費者Pull |
支持 |
支持 |
|
適用場景 |
kafka的優(yōu)勢主要體現(xiàn)在吞吐量上，它主要用在高吞吐量的場景。比如日志采集。 |
具有較高的嚴謹性，數(shù)據(jù)丟失的可能性更小，同時具備較高的實時性，用在對實時性、可靠性要求較高的消息傳遞上。 |
07 kafka吞吐量為什么這么高
1、順序讀寫磁盤
Kafka是將消息持久化到本地磁盤中的，一般人會認為磁盤讀寫性能差，可能會對Kafka性能提出質疑。實際上不管是內存還是磁盤，快或慢的關鍵在于尋址方式，磁盤分為順序讀寫與隨機讀寫，內存一樣也分為順序讀寫與隨機讀寫。基于磁盤的隨機讀寫確實很慢，但基于磁盤的順序讀寫性能卻很高，一般而言要高出磁盤的隨機讀寫三個數(shù)量級，一些情況下磁盤順序讀寫性能甚至要高于內存隨機讀寫，這里貼一張著名學術期刊 ACM Queue 上的一張性能對比圖：
2、page cache
為了優(yōu)化讀寫性能，Kafka利用了操作系統(tǒng)本身的Page Cache，就是利用操作系統(tǒng)自身的內存而不是JVM空間內存。這樣做是因為，
JVM中一切皆對象，對象的存儲會帶來額外的內存消耗；
使用JVM會受到GC的影響，隨著數(shù)據(jù)的增多，垃圾回收也會變得復雜與緩慢，降低吞吐量；
另外操作系統(tǒng)本身對page cache做了大量優(yōu)化，通過操作系統(tǒng)的Page Cache，Kafka的讀寫操作基本上是基于系統(tǒng)內存的，讀寫性能也得到了極大的提升。
3、零拷貝
零拷貝是指Kafka利用 linux 操作系統(tǒng)的 "zero-copy" 機制在消費端做的優(yōu)化。首先來看一下消費端在消費數(shù)據(jù)時，數(shù)據(jù)從broker磁盤通過網(wǎng)絡傳輸?shù)较M端的整個過程：
操作系統(tǒng)從磁盤讀取數(shù)據(jù)到內核空間（kernel space）的page cache；
應用程序讀取page cache的數(shù)據(jù)到用戶空間（user space）的緩沖區(qū)；
應用程序將用戶空間緩沖區(qū)的數(shù)據(jù)寫回內核空間的socket緩沖區(qū)（socket buffer）；
操作系統(tǒng)將數(shù)據(jù)從socket緩沖區(qū)復制到硬件（如網(wǎng)卡）緩沖區(qū)；
整個過程如上圖所示，這個過程包含4次copy操作和2次系統(tǒng)上下文切換，而上下文切換是CPU密集型的工作，數(shù)據(jù)拷貝是I/O密集型的工作，性能其實非常低效。
零拷貝就是使用了一個名為sendfile()的系統(tǒng)調用方法，將數(shù)據(jù)從page cache直接發(fā)送到Socket緩沖區(qū)，避免了系統(tǒng)上下文的切換，消除了從內核空間到用戶空間的來回復制。從上圖可以看出，"零拷貝"并不是說整個過程完全不發(fā)生拷貝，而是站在內核的角度來說的，避免了內核空間到用戶空間的來回拷貝。
4、分區(qū)分段
Kafka的message是按topic分類存儲的，topic中的數(shù)據(jù)又是按照一個一個的partition即分區(qū)存儲到不同broker節(jié)點。每個partition對應了操作系統(tǒng)上的一個文件夾，partition實際上又是按照segment分段存儲的。這也非常符合分布式系統(tǒng)分區(qū)分桶的設計思想。
通過這種分區(qū)分段的設計，Kafka的message消息實際上是分布式存儲在一個一個小的segment中的，每次文件操作也是直接操作的segment。為了進一步的查詢優(yōu)化，Kafka又默認為分段后的數(shù)據(jù)文件建立了索引文件，就是文件系統(tǒng)上的.index文件。這種分區(qū)分段+索引的設計，不僅提升了數(shù)據(jù)讀取的效率，同時也提高了數(shù)據(jù)操作的并行度。
總之，Kafka采用順序讀寫、Page Cache、零拷貝以及分區(qū)分段等這些設計，再加上在索引方面做的優(yōu)化，另外Kafka數(shù)據(jù)讀寫也是批量的而不是單條的，使得Kafka具有了高性能、高吞吐、低延時的特點。
到此這篇關于深入解析kafka 架構原理的文章就介紹到這了,更多相關kafka 架構原理內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！
相關文章
已有的springcloud+mybatis項目升級為mybatis-plus的方法
這篇文章主要介紹了已有的springcloud+mybatis項目升級為mybatis-plus，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2021-03-03
這篇文章主要介紹了詳解Kotlin中的面向對象（一）的相關資料,需要的朋友可以參考下2017-06-06
本篇文章小編為大家介紹，基于jstl 標簽的使用介紹，需要的朋友參考下2013-04-04
SpringBoot實現(xiàn)本地上傳文件到resources目錄
Java后端項目上傳文件是一個很常見的需求，這篇文章主要為大家介紹了SpringBoot如何實現(xiàn)本地上傳文件到resources目錄永久保存下載，需要的可以參考一下2023-07-07
下面小編就為大家?guī)硪黄獪\談Java中強制類型轉換的問題。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2016-05-05
今天帶大家復習Java基礎知識,文中對Java運算符相關知識作了詳細總結,對正在學習java基礎的小伙伴們很有幫助,需要的朋友可以參考下2021-05-05
這篇文章主要介紹了idea日志亂碼和tomcat日志亂碼問題的解決方法,本文給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2020-08-08
這篇文章主要介紹了Mybatis的Dao層實現(xiàn)原理分析，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2022-12-12
這篇文章主要為大家詳細介紹了jQuery ajax實現(xiàn)省市縣三級聯(lián)動的相關資料，具有一定的參考價值，感興趣的小伙伴們可以參考一下,希望能幫助到你2021-07-07
這篇文章主要為大家介紹了深入理解Hibernate中的懶加載異常及解決方法示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪<BR>2023-10-10