kafka的特點和組件

這篇文章主要介紹“kafka的特點和組件”，在日常操作中，相信很多人在kafka的特點和組件問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”kafka的特點和組件”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

一、特點

MQ生來就是解決生產者和消費者速度不匹配的問題而誕生的，那么MQ系統一個最最基本的要求就是寫入速度必須要快，哪怕出隊速度慢點也無所謂，因為業務高峰期持續時間是有限的，高峰結束之后有的是時間讓消費者慢慢消化，更別說簡單粗暴多加幾臺消費者就好了。

1.同時為發布和訂閱提供高吞吐量。據了解，Kafka每秒可以生產約25萬消息（50 MB），每秒處理55萬消息（110 MB）。

2.可進行持久化操作。將消息持久化到磁盤，因此可用于批量消費，例如ETL，以及實時應用程序。通過將數據持久化到硬盤以及replication防止數據丟失。

3.分布式系統，易于向外擴展。所有的producer、broker和consumer都會有多個，均為分布式的。無需停機即可擴展機器。

4.消息被處理的狀態是在consumer端維護，而不是由server端維護。當失敗時能自動平衡。

5.支持online和offline的場景。

二、組件

broker：發布和訂閱的中間者，堆積消息。

zookeeper：管理kafka集群，監控每個broker的狀態，使得發布和訂閱都與有效的broker進行。

producer：消息的發布者。Producer將消息發布到指定的Topic中,同時Producer也能決定將此消息發送到哪個partition。

consumer：異步消費者，通過訂閱感興趣的topic，從broker拉取消息進行消費。在kafka中,一個partition中的消息只會被group中的一個consumer消費(同一時刻);每個group中consumer消息消費互相獨立;我們可以認為一個group是一個"訂閱"者,一個Topic中的每個partions,只會被一個"訂閱者"中的一個consumer消費,不過一個consumer可以同時消費多個partitions中的消息.kafka只能保證一個partition中的消息被某個consumer消費時是順序的.事實上,從Topic角度來說,當有多個partitions時,消息仍不是全局有序的.

**Consumer group:每個consumer客戶端被創建時,會向zookeeper注冊自己的信息;此作用主要是為了"負載均衡".**一個group中的多個consumer可以交錯的消費一個topic的所有partitions;簡而言之,保證此topic的所有partitions都能被此group所消費,且消費時為了性能考慮,讓partition相對均衡的分散到每個consumer上.

三、原理

1.持久化

kafka使用文件存儲消息(append only log),這就直接決定kafka在性能上嚴重依賴文件系統的本身特性.且無論任何OS下,對文件系統本身的優化是非常艱難的.文件緩存/直接內存映射等是常用的手段.因為kafka是對日志文件進行append操作,因此磁盤檢索的開支是較小的;同時為了減少磁盤寫入的次數,broker會將消息暫時buffer起來,當消息的個數(或尺寸)達到一定閥值時,再flush到磁盤,這樣減少了磁盤IO調用的次數.對于kafka而言,較高性能的磁盤,將會帶來更加直接的性能提升.

2.性能

除磁盤IO之外,我們還需要考慮網絡IO,這直接關系到kafka的吞吐量問題.kafka并沒有提供太多高超的技巧;對于producer端,可以將消息buffer起來,當消息的條數達到一定閥值時,批量發送給broker;對于consumer端也是一樣,批量fetch多條消息.不過消息量的大小可以通過配置文件來指定.對于kafka broker端,似乎有個sendfile系統調用可以潛在的提升網絡IO的性能:將文件的數據映射到系統內存中,socket直接讀取相應的內存區域即可,而無需進程再次copy和交換(這里涉及到"磁盤IO數據"/"內核內存"/"進程內存"/"網絡緩沖區",多者之間的數據copy).

其實對于producer/consumer/broker三者而言,CPU的開支應該都不大,因此啟用消息壓縮機制是一個良好的策略;壓縮需要消耗少量的CPU資源,不過對于kafka而言,網絡IO更應該需要考慮.可以將任何在網絡上傳輸的消息都經過壓縮.kafka支持gzip/snappy等多種壓縮方式.

3.負載均衡

kafka集群中的任何一個broker,都可以向producer提供metadata信息,這些metadata中包含"集群中存活的servers列表"/"partitions leader列表"等信息(請參看zookeeper中的節點信息). 當producer獲取到metadata信息之后, producer將會和Topic下所有partition leader保持socket連接;消息由producer直接通過socket發送到broker,中間不會經過任何"路由層".

異步發送，將多條消息暫且在客戶端buffer起來,并將他們批量發送到broker;小數據IO太多,會拖慢整體的網絡延遲,批量延遲發送事實上提升了網絡效率;不過這也有一定的隱患,比如當producer失效時,那些尚未發送的消息將會丟失。

4.Topic模型

其他JMS實現,消息消費的位置是有proper保留,以便避免重復發送消息或者將沒有消費成功的消息重發等,同時還要控制消息的狀態.這就要求JMS broker需要太多額外的工作.在kafka中,partition中的消息只有一個consumer在消費,且不存在消息狀態的控制,也沒有復雜的消息確認機制,可見kafka broker端是相當輕量級的.**當消息被consumer接收之后,consumer可以在本地保存最后消息的offset,并間歇性的向zookeeper注冊offset.而且，在kafka0.10版本中的“auto.offset.reset”配置項中，無論是eraliest、lastest、none或anything else任何一個選項，都是在沒有初始offset或者在offset丟失下才會生效。**由此可見,consumer客戶端也很輕量級。

kafka中consumer負責維護消息的消費記錄,而broker則不關心這些,這種設計不僅提高了consumer端的靈活性,也適度的減輕了broker端設計的復雜度;這是和眾多JMS proper的區別.此外,kafka中消息ACK的設計也和JMS有很大不同,kafka中的消息是批量(通常以消息的條數或者chunk的尺寸為單位)發送給consumer,當消息消費成功后,向zookeeper提交消息的offset,而不會向broker交付ACK.或許你已經意識到,這種"寬松"的設計,將會有"丟失"消息/"消息重發"的危險.

5.log

每個log entry格式為"4個字節的數字N表示消息的長度" + "N個字節的消息內容";每個日志都有一個offset來唯一的標記一條消息,offset的值為8個字節的數字,表示此消息在此partition中所處的起始位置..每個partition在物理存儲層面,有多個log file組成(稱為segment).segment file的命名為"最小offset".kafka.例如"00000000000.kafka";其中"最小offset"表示此segment中起始消息的offset.

獲取消息時,需要指定offset和最大chunk尺寸,offset用來表示消息的起始位置,chunk size用來表示最大獲取消息的總長度(間接的表示消息的條數).根據offset,可以找到此消息所在segment文件,然后根據segment的最小offset取差值,得到它在file中的相對位置,直接讀取輸出即可.

6.分布式

kafka使用zookeeper來存儲一些meta信息,并使用了zookeeper watch機制來發現meta信息的變更并作出相應的動作(比如consumer失效,觸發負載均衡等)

Broker node registry: 當一個kafka broker啟動后,首先會向zookeeper注冊自己的節點信息(臨時znode),同時當broker和zookeeper斷開連接時,此znode也會被刪除.

Broker Topic Registry: 當一個broker啟動時,會向zookeeper注冊自己持有的topic和partitions信息,仍然是一個臨時znode.

Consumer and Consumer group: 每個consumer客戶端被創建時,會向zookeeper注冊自己的信息;此作用主要是為了"負載均衡".一個group中的多個consumer可以交錯的消費一個topic的所有partitions;簡而言之,保證此topic的所有partitions都能被此group所消費,且消費時為了性能考慮,讓partition相對均衡的分散到每個consumer上.

Consumer id Registry: 每個consumer都有一個唯一的ID(host:uuid,可以通過配置文件指定,也可以由系統生成),此id用來標記消費者信息.

Consumer offset Tracking: 用來跟蹤每個consumer目前所消費的partition中最大的offset.此znode為持久節點,可以看出offset跟group_id有關,以表明當group中一個消費者失效,其他consumer可以繼續消費.

Partition Owner registry: 用來標記partition正在被哪個consumer消費.臨時znode。此節點表達了"一個partition"只能被group下一個consumer消費,同時當group下某個consumer失效,那么將會觸發負載均衡(即:讓partitions在多個consumer間均衡消費,接管那些"游離"的partitions)

當consumer啟動時,所觸發的操作:

A) 首先進行"Consumer id Registry";

B) 然后在"Consumer id Registry"節點下注冊一個watch用來監聽當前group中其他consumer的"leave"和"join";只要此znode path下節點列表變更,都會觸發此group下consumer的負載均衡.(比如一個consumer失效,那么其他consumer接管partitions).

C) 在"Broker id registry"節點下,注冊一個watch用來監聽broker的存活情況;如果broker列表變更,將會觸發所有的groups下的consumer重新balance.

總結:

1. Producer端使用zookeeper用來"發現"broker列表,以及和Topic下每個partition leader建立socket連接并發送消息.

2. Broker端使用zookeeper用來注冊broker信息,已經監測partition leader存活性.

3. Consumer端使用zookeeper用來注冊consumer信息,其中包括consumer消費的partition列表等,同時也用來發現broker列表,并和partition leader建立socket連接,并獲取消息。

7.副本管理

Kafka盡量的使所有分區均勻的分布到集群所有的節點上而不是集中在某些節點上，另外主從關系也盡量均衡這樣每個幾點都會擔任一定比例的分區的leader.

優化leader的選擇過程也是很重要的，它決定了系統發生故障時的空窗期有多久。Kafka選擇一個節點作為“controller”,當發現有節點down掉的時候它負責在分區的所有節點中選擇新的leader,這使得Kafka可以批量的高效的管理所有分區節點的主從關系。如果controller down掉了，活著的節點中的一個會備切換為新的controller.

8.Leader與副本同步

創建副本的單位是topic的分區，每個分區都有一個leader和零或多個followers.所有的讀寫操作都由leader處理，一般分區的數量都比broker的數量多的多，各分區的leader均勻的分布在brokers中。所有的followers都復制leader的日志，日志中的消息和順序都和leader中的一致。followers向普通的consumer那樣從leader那里拉取消息并保存在自己的日志文件中。

許多分布式的消息系統自動的處理失敗的請求，它們對一個節點是否著（alive）”有著清晰的定義。Kafka判斷一個節點是否活著有兩個條件：

1. 節點必須可以維護和ZooKeeper的連接，Zookeeper通過心跳機制檢查每個節點的連接。

2. 如果節點是個follower,他必須能及時的同步leader的寫操作，延時不能太久。

符合以上條件的節點準確的說應該是“同步中的（in sync）”，而不是模糊的說是“活著的”或是“失敗的”。Leader會追蹤所有“同步中”的節點，一旦一個down掉了，或是卡住了，或是延時太久，leader就會把它移除。至于延時多久算是“太久”，是由參數replica.lag.max.messages決定的，怎樣算是卡住了，怎是由參數replica.lag.time.max.ms決定的。

四、版本比較

（一）、0.8.x vs 0.9

1.安全

Kafka提供了三個安全特性。

一是提供Kerberos 和 TLS 身份認證。

二是提供了類似Unix-like權限系統，控制哪些用戶可以訪問數據。

三是提供數據傳輸加密。

當然只有新的producer，consumer API和0.9的consumer實現才能使用這些安全特性。老的API還是沒有這些安全方面的控制。

這些安全特性實現了向下兼容的方式，不啟動安全特性的用戶不必擔心性能的降低。

這只是第一版的安全特性，更多的安全控制會在將來的版本中提供。

2.新的Consumer

Kafka 0.8.2, Producer被重新設計， Kafka 0.9則重新設計了Consumer接口。它不再區分high-level consumer API和low-level consumer API，而是提供了一個統一的consumer API。

1）Kafka可以自行維護Offset、消費者的Position。也可以開發者自己來維護Offset，實現相關的業務需求。消費時，可以只消費指定的Partitions

2）.可以使用外部存儲記錄Offset，如數據庫之類的。

3）.自行控制Consumer消費消息的位置。

4）.可以使用多線程進行消費。

3.為用戶定義配額

一個大的Kafka集群可能有多個用戶。0.9以前，consumer 如果處理的消息非常快，可能會壟斷整個broker的網絡資源，producer也是如此。現在Kafka 0.9提供了基于client的用戶配額控制。對于Producer可以控制每個client的每秒寫的字節數，對于Consumer控制每個 client的每秒讀的字節。

（二）、0.9 vs 0.10

1.Kafka Streams

Kafka Streams包含了一整套描述常見流操作的高級語言API（比如 joining, filtering以及aggregating records），這使得開發者可以快速開發強大的流處理應用程序。Kafka Streams提供了狀態和無狀態的處理能力，并且可以部署在很多系統之上。

2.Connectors連接狀態/控制的REST API

在Kafka 0.10.0.0中，Kafka Connect得到了持續提升。

在此之前，用戶需要監控日志以便看到各個connectors以及他們task的狀態，現在Kafka已經支持了獲取的狀態API這樣使得監控變得更簡單。

同時也添加了控制相關的API，這使得用戶可以在進行維護的時候停止一個connector；或者手動地重啟那些失敗的task。這些能夠直觀的在用戶界面展示和管理connector目前可以在控制中心(Control Center)看到。

3.SASL改進

新的安全特性，包括通過SASL支持Kerberos。Apache Kafka 0.10.0.0現在支持更多的SASL特性，包括外部授權服務器，在一臺服務器上支持多種類型的SASL認證以及其他的改進。

4.Rack Awareness

現在Kafka已經內置了機架感知以便隔離副本，這使得Kafka保證副本可以跨越到多個機架或者是可用區域，顯著提高了Kafka的彈性和可用性。這個功能是由Netflix提供的。

5.Kafka Consumer Max Records

在Kafka 0.9.0.0，開發者們在新consumer上使用poll()函數的時候是幾乎無法控制返回消息的條數。不過值得高興的是，此版本的Kafka引入了max.poll.records參數，允許開發者控制返回消息的條數。

6.協議版本改進

Kafka brokers現在支持返回所有支持的協議版本的請求API，這個特點的好處就是以后將允許一個客戶端支持多個broker版本。

到此，關于“kafka的特點和組件”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！