Kafka的知識點匯總

本篇內(nèi)容介紹了“Kafka的知識點匯總”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

1、Kafka是一種分布式的，基于發(fā)布/訂閱的消息系統(tǒng)。

2、常用Message Queue對比

• RabbitMQ
  RabbitMQ是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協(xié)議：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量級，更適合于企業(yè)級的開發(fā)。同時實現(xiàn)了Broker構(gòu)架，這意味著消息在發(fā)送給客戶端時先在中心隊列排隊。對路由，負載均衡或者數(shù)據(jù)持久化都有很好的支持。

• Redis
  Redis是一個基于Key-Value對的NoSQL數(shù)據(jù)庫，開發(fā)維護很活躍。雖然它是一個Key-Value數(shù)據(jù)庫存儲系統(tǒng)，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務(wù)來使用。對于RabbitMQ和Redis的入隊和出隊操作，各執(zhí)行100萬次，每10萬次記錄一次執(zhí)行時間。測試數(shù)據(jù)分為128Bytes、512Bytes、1K和10K四個不同大小的數(shù)據(jù)。實驗表明：入隊時，當數(shù)據(jù)比較小時Redis的性能要高于RabbitMQ，而如果數(shù)據(jù)大小超過了10K，Redis則慢的無法忍受；出隊時，無論數(shù)據(jù)大小，Redis都表現(xiàn)出非常好的性能，而RabbitMQ的出隊性能則遠低于Redis。

• ZeroMQ
  ZeroMQ號稱最快的消息隊列系統(tǒng)，尤其針對大吞吐量的需求場景。ZMQ能夠?qū)崿F(xiàn)RabbitMQ不擅長的高級/復(fù)雜的隊列，但是開發(fā)人員需要自己組合多種技術(shù)框架，技術(shù)上的復(fù)雜度是對這MQ能夠應(yīng)用成功的挑戰(zhàn)。ZeroMQ具有一個獨特的非中間件的模式，你不需要安裝和運行一個消息服務(wù)器或中間件，因為你的應(yīng)用程序?qū)缪萘诉@個服務(wù)角色。你只需要簡單的引用ZeroMQ程序庫，可以使用NuGet安裝，然后你就可以愉快的在應(yīng)用程序之間發(fā)送消息了。但是ZeroMQ僅提供非持久性的隊列，也就是說如果宕機，數(shù)據(jù)將會丟失。其中，Twitter的Storm 0.9.0以前的版本中默認使用ZeroMQ作為數(shù)據(jù)流的傳輸（Storm從0.9版本開始同時支持ZeroMQ和Netty作為傳輸模塊）。

• ActiveMQ
  ActiveMQ是Apache下的一個子項目。 類似于ZeroMQ，它能夠以代理人和點對點的技術(shù)實現(xiàn)隊列。同時類似于RabbitMQ，它少量代碼就可以高效地實現(xiàn)高級應(yīng)用場景。

• Kafka/Jafka
  Kafka是Apache下的一個子項目，是一個高性能跨語言分布式發(fā)布/訂閱消息隊列系統(tǒng)，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統(tǒng)開銷下進行消息持久化；高吞吐，在一臺普通的服務(wù)器上既可以達到10W/s的吞吐速率；完全的分布式系統(tǒng)，Broker、Producer、Consumer都原生自動支持分布式，自動實現(xiàn)復(fù)雜均衡；支持Hadoop數(shù)據(jù)并行加載，對于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的并行加載機制來統(tǒng)一了在線和離線的消息處理。Apache Kafka相對于ActiveMQ是一個非常輕量級的消息系統(tǒng)，除了性能非常好之外，還是一個工作良好的分布式系統(tǒng)。

3、經(jīng)驗證，順序?qū)懘疟P效率比隨機寫內(nèi)存還要高，這是Kafka高吞吐率的一個很重要的保證。

4、每一條消息被發(fā)送到broker時，會根據(jù)paritition規(guī)則選擇被存儲到哪一個partition。如果partition規(guī)則設(shè)置的合理，所有消息可以均勻分布到不同的partition里，這樣就實現(xiàn)了水平擴展。（如果一個topic對應(yīng)一個文件，那這個文件所在的機器I/O將會成為這個topic的性能瓶頸，而partition解決了這個問題）。

5、對于傳統(tǒng)的message queue而言，一般會刪除已經(jīng)被消費的消息，而Kafka集群會保留所有的消息，無論其被消費與否。當然，因為磁盤限制，不可能永久保留所有數(shù)據(jù)（實際上也沒必要），因此Kafka提供兩種策略去刪除舊數(shù)據(jù)。一是基于時間，二是基于partition文件大小。例如可以通過配置$KAFKA_HOME/config/server.properties，讓Kafka刪除一周前的數(shù)據(jù)，也可通過配置讓Kafka在partition文件超過1GB時刪除舊數(shù)據(jù)。

6、Kafka讀取特定消息的時間復(fù)雜度為O(1)，即與文件大小無關(guān)，所以這里刪除文件與Kafka性能無關(guān)，選擇怎樣的刪除策略只與磁盤以及具體的需求有關(guān)。另外，Kafka會為每一個consumer group保留一些metadata信息—當前消費的消息的position，也即offset。這個offset由consumer控制。正常情況下consumer會在消費完一條消息后線性增加這個offset。當然，consumer也可將offset設(shè)成一個較小的值，重新消費一些消息。因為offet由consumer控制，所以Kafka broker是無狀態(tài)的，它不需要標記哪些消息被哪些consumer過，不需要通過broker去保證同一個consumer group只有一個consumer能消費某一條消息，因此也就不需要鎖機制，這也為Kafka的高吞吐率提供了有力保障。

7、一條消息只有被“in sync” list里的所有follower都從leader復(fù)制過去才會被認為已提交。這樣就避免了部分數(shù)據(jù)被寫進了leader，還沒來得及被任何follower復(fù)制就宕機了，而造成數(shù)據(jù)丟失（consumer無法消費這些數(shù)據(jù)）。而對于producer而言，它可以選擇是否等待消息commit，這可以通過request.required.acks來設(shè)置。這種機制確保了只要“in sync” list有一個或以上的flollower，一條被commit的消息就不會丟失。

8、這里的復(fù)制機制即不是同步復(fù)制，也不是單純的異步復(fù)制。事實上，同步復(fù)制要求“活著的”follower都復(fù)制完，這條消息才會被認為commit，這種復(fù)制方式極大的影響了吞吐率（高吞吐率是Kafka非常重要的一個特性）。而異步復(fù)制方式下，follower異步的從leader復(fù)制數(shù)據(jù)，數(shù)據(jù)只要被leader寫入log就被認為已經(jīng)commit，這種情況下如果follwer都落后于leader，而leader突然宕機，則會丟失數(shù)據(jù)。而Kafka的這種使用“in sync” list的方式則很好的均衡了確保數(shù)據(jù)不丟失以及吞吐率。follower可以批量的從leader復(fù)制數(shù)據(jù)，這樣極大的提高復(fù)制性能（批量寫磁盤），極大減少了follower與leader的差距（前文有說到，只要follower落后leader不太遠，則被認為在“in sync” list里）。

9、每一個consumer實例都屬于一個consumer group，每一條消息只會被同一個consumer group里的一個consumer實例消費。（不同consumer group可以同時消費同一條消息）

10、實際上，Kafka的設(shè)計理念之一就是同時提供離線處理和實時處理。根據(jù)這一特性，可以使用Storm這種實時流處理系統(tǒng)對消息進行實時在線處理，同時使用Hadoop這種批處理系統(tǒng)進行離線處理，還可以同時將數(shù)據(jù)實時備份到另一個數(shù)據(jù)中心，只需要保證這三個操作所使用的consumer在不同的consumer group即可。

11、Kafka默認保證At least once，并且允許通過設(shè)置producer異步提交來實現(xiàn)At most once。

12、在1臺機器上跑多個實例對吞吐率的增加不會有太大幫忙，因為網(wǎng)卡已經(jīng)基本飽和了

13、需要注意的是，replication factor并不會影響consumer的吞吐率測試，因為consumer只會從每個partition的leader讀數(shù)據(jù)，而與replicaiton factor無關(guān)。同樣，consumer吞吐率也與同步復(fù)制還是異步復(fù)制無關(guān)?！?/p>

14、上面的所有測試都基于短消息（payload 100字節(jié)），而正如上文所說，短消息對Kafka來說是更難處理的使用方式，可以預(yù)期，隨著消息長度的增大，records/second會減小，但MB/second會有所提高。下圖是records/second與消息長度的關(guān)系圖。

正如我們所預(yù)期的那樣，隨著消息長度的增加，每秒鐘所能發(fā)送的消息的數(shù)量逐漸減小。但是如果看每秒鐘發(fā)送的消息的總大小，它會隨著消息長度的增加而增加，如下圖所示。

從上圖可以看出，當消息長度為10字節(jié)時，因為要頻繁入隊，花了太多時間獲取鎖，CPU成了瓶頸，并不能充分利用帶寬。但從100字節(jié)開始，我們可以看到帶寬的使用逐漸趨于飽和（雖然MB/second還是會隨著消息長度的增加而增加，但增加的幅度也越來越?。?。

15、Kafka支持對消息集合進行壓縮，Producer端可以通過GZIP或Snappy格式對消息集合進行壓縮。Producer端進行壓縮之后，在Consumer端需進行解壓。壓縮的好處就是減少傳輸?shù)臄?shù)據(jù)量，減輕對網(wǎng)絡(luò)傳輸?shù)膲毫?，在對大?shù)據(jù)處理上，瓶頸往往體現(xiàn)在網(wǎng)絡(luò)上而不是CPU（壓縮和解壓會耗掉部分CPU資源）。那么如何區(qū)分消息是壓縮的還是未壓縮的呢，Kafka在消息頭部添加了一個 描述壓縮屬性字節(jié) ，這個字節(jié)的后兩位表示消息的壓縮采用的編碼，如果后兩位為0，則表示消息未被壓縮。

“Kafka的知識點匯總”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！