開源軟件之消息系統(tǒng)-kafka簡介

什么是kafkaKafka是最初由Linkedin公司開發(fā)，是一個分布式、分區(qū)的、多副本的、多訂閱者，基于zookeeper協(xié)調(diào)的分布式日志系統(tǒng)\MessageQueue系統(tǒng)?？梢杂糜趙eb/nginx日志、訪問日志，消息服務(wù)以及微服務(wù)。Linkedin于2010年貢獻給了Apache基金會并成為頂級開源項目。主要應(yīng)用場景是：日志收集系統(tǒng)和消息系統(tǒng)。什么是kafka舉個例子生產(chǎn)者消費者，生產(chǎn)者生產(chǎn)雞蛋，消費者消費雞蛋，生產(chǎn)者生產(chǎn)一個雞蛋，消費者就消費一個雞蛋，假設(shè)消費者消費雞蛋的時候噎住了（系統(tǒng)宕機了），生產(chǎn)者還在生產(chǎn)雞蛋，那新生產(chǎn)的雞蛋就丟失了。再比如生產(chǎn)者很強勁（大交易量的情況），生產(chǎn)者1秒鐘生產(chǎn)100個雞蛋，消費者1秒鐘只能吃50個雞蛋，那要不了一會，消費者就吃不消了（消息堵塞，最終導致系統(tǒng)超時），消費者拒絕再吃了，”雞蛋“又丟失了，這個時候我們放個籃子在它們中間，生產(chǎn)出來的雞蛋都放到籃子里，消費者去籃子里拿雞蛋，這樣雞蛋就不會丟失了，都在籃子里，而這個籃子就是”kafka“。

雞蛋其實就是“數(shù)據(jù)流”，系統(tǒng)之間的交互都是通過“數(shù)據(jù)流”來傳輸?shù)模ň褪莟cp、https什么的），也稱為報文，也叫“消息”。

消息隊列滿了，其實就是籃子滿了，”雞蛋“放不下了，那趕緊多放幾個籃子，其實就是kafka的擴容。

各位現(xiàn)在知道kafka是干什么的了吧，它就是那個”籃子“。

什么是kafka名詞解釋producer：生產(chǎn)者，就是它來生產(chǎn)“雞蛋”的。consumer：消費者，生出的“雞蛋”它來消費。topic：主題，可理解為標簽，生產(chǎn)者每生產(chǎn)出來一個雞蛋就貼上一個標簽（topic），消費者可不是誰生產(chǎn)的“雞蛋”都吃的，這樣不同的生產(chǎn)者生產(chǎn)出來的“雞蛋”，消費者就可以選擇性的“吃”了。broker：就是籃子了。

什么是kafka名詞解釋producer：生產(chǎn)者，就是它來生產(chǎn)“雞蛋”的。consumer：消費者，生出的“雞蛋”它來消費。topic：主題，可理解為標簽，生產(chǎn)者每生產(chǎn)出來一個雞蛋就貼上一個標簽（topic），消費者可不是誰生產(chǎn)的“雞蛋”都吃的，這樣不同的生產(chǎn)者生產(chǎn)出來的“雞蛋”，消費者就可以選擇性的“吃”了。broker：就是籃子了。

Kafka設(shè)計目標以時間復雜度為O(1)的方式提供消息持久化能力，即使對TB級以上數(shù)據(jù)也能保證訪問性能。高吞吐率。即使在非常廉價的商用機器上也能做到單機支持每秒100K條消息的傳輸。支持KafkaServer間的消息分區(qū)，及分布式消費，同時保證每個partition內(nèi)的消息順序傳輸。同時支持離線數(shù)據(jù)處理和實時數(shù)據(jù)處理。Scaleout:支持在線水平擴展消息系統(tǒng)一個消息系統(tǒng)負責將數(shù)據(jù)從一個應(yīng)用傳遞到另外一個應(yīng)用，應(yīng)用只需關(guān)注于數(shù)據(jù)，無需關(guān)注數(shù)據(jù)在兩個或多個應(yīng)用間是如何傳遞的。分布式消息傳遞基于可靠的消息隊列，在客戶端應(yīng)用和消息系統(tǒng)之間異步傳遞消息。有兩種主要的消息傳遞模式：點對點傳遞模式、發(fā)布-訂閱模式。大部分的消息系統(tǒng)選用發(fā)布-訂閱模式。Kafka就是一種發(fā)布-訂閱模式。消息系統(tǒng)點對點消息傳遞模式消息持久化到一個隊列中。此時，將有一個或多個消費者消費隊列中的數(shù)據(jù)。但是一條消息只能被消費一次。當一個消費者消費了隊列中的某條數(shù)據(jù)之后，該條數(shù)據(jù)則從消息隊列中刪除。生產(chǎn)者發(fā)送一條消息到queue，只有一個消費者能收到。ActiveMQ消息系統(tǒng)發(fā)布-訂閱消息傳遞模式消息被持久化到一個topic中。與點對點消息系統(tǒng)不同的是，消費者可以訂閱一個或多個topic，消費者可以消費該topic中所有的數(shù)據(jù)，同一條數(shù)據(jù)可以被多個消費者消費，數(shù)據(jù)被消費后不會立馬刪除。在發(fā)布-訂閱消息系統(tǒng)中，消息的生產(chǎn)者稱為發(fā)布者，消費者稱為訂閱者。發(fā)布者發(fā)送到topic的消息，只有訂閱了topic的訂閱者才會收到消息。KafkaKafka的優(yōu)點解耦在項目啟動之初來預測將來項目會碰到什么需求，是極其困難的。消息系統(tǒng)在處理過程中間插入了一個隱含的、基于數(shù)據(jù)的接口層，兩邊的處理過程都要實現(xiàn)這一接口。這允許你獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。冗余有些情況下，處理數(shù)據(jù)的過程會失敗。除非數(shù)據(jù)被持久化，否則將造成丟失。消息隊列把數(shù)據(jù)進行持久化直到它們已經(jīng)被完全處理，通過這一方式規(guī)避了數(shù)據(jù)丟失風險。許多消息隊列所采用的"插入-獲取-刪除"范式中，在把一個消息從隊列中刪除之前，需要你的處理系統(tǒng)明確的指出該消息已經(jīng)被處理完畢，從而確保你的數(shù)據(jù)被安全的保存直到你使用完畢。擴展性因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調(diào)節(jié)參數(shù)。擴展就像調(diào)大電力按鈕一樣簡單。Kafka的優(yōu)點靈活性&峰值處理能力在訪問量劇增的情況下，應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量并不常見；如果為以能處理這類峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列能夠使關(guān)鍵組件頂住突發(fā)的訪問壓力，而不會因為突發(fā)的超負荷的請求而完全崩潰?？苫謴托韵到y(tǒng)的一部分組件失效時，不會影響到整個系統(tǒng)。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統(tǒng)恢復后被處理。順序保證在大多使用場景下，數(shù)據(jù)處理的順序都很重要。大部分消息隊列本來就是排序的，并且能保證數(shù)據(jù)會按照特定的順序來處理。Kafka保證一個Partition內(nèi)的消息的有序性。Kafka的優(yōu)點緩沖在任何重要的系統(tǒng)中，都會有需要不同的處理時間的元素。例如，加載一張圖片比應(yīng)用過濾器花費更少的時間。消息隊列通過一個緩沖層來幫助任務(wù)最高效率的執(zhí)行———寫入隊列的處理會盡可能的快速。該緩沖有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的速度。異步通信很多時候，用戶不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然后在需要的時候再去處理它們。Kafka與其他MQ對比RabbitMQRabbitMQ是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協(xié)議：AMQP，XMPP,SMTP,STOMP，也正因如此，它非常重量級，更適合于企業(yè)級的開發(fā)。同時實現(xiàn)了Broker構(gòu)架，這意味著消息在發(fā)送給客戶端時先在中心隊列排隊。對路由，負載均衡或者數(shù)據(jù)持久化都有很好的支持。RedisRedis是一個基于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。Kafka與其他MQ對比ActiveMQActiveMQ是Apache下的一個子項目。類似于ZeroMQ，它能夠以代理人和點對點的技術(shù)實現(xiàn)隊列。同時類似于RabbitMQ，它少量代碼就可以高效地實現(xiàn)高級應(yīng)用場景。Kafka/JafkaKafka是Apache下的一個子項目，是一個高性能跨語言分布式發(fā)布/訂閱消息隊列系統(tǒng)，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統(tǒng)開銷下進行消息持久化；高吞吐，在一臺普通的服務(wù)器上既可以達到10W/s的吞吐速率；完全的分布式系統(tǒng)，Broker、Producer、Consumer都原生自動支持分布式，自動實現(xiàn)負載均衡；支持Hadoop數(shù)據(jù)并行加載，對于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的并行加載機制統(tǒng)一了在線和離線的消息處理。ApacheKafka相對于ActiveMQ是一個非常輕量級的消息系統(tǒng)，除了性能非常好之外，還是一個工作良好的分布式系統(tǒng)。Kafka原理Kafka原理Kafka原理brokerKafka集群包含一個或多個服務(wù)器，服務(wù)器節(jié)點稱為broker。broker存儲topic的數(shù)據(jù)。如果某topic有N個partition，集群有N個broker，那么每個broker存儲該topic的一個partition。如果某topic有N個partition，集群有(N+M)個broker，那么其中有N個broker存儲該topic的一個partition，剩下的M個broker不存儲該topic的partition數(shù)據(jù)。如果某topic有N個partition，集群中broker數(shù)目少于N個，那么一個broker存儲該topic的一個或多個partition。在實際生產(chǎn)環(huán)境中，盡量避免這種情況的發(fā)生，這種情況容易導致Kafka集群數(shù)據(jù)不均衡。Kafka原理Topic每條發(fā)布到Kafka集群的消息都有一個類別，這個類別被稱為Topic。物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存于一個或多個broker上但用戶只需指定消息的Topic即可生產(chǎn)或消費數(shù)據(jù)而不必關(guān)心數(shù)據(jù)存于何處。類似于數(shù)據(jù)庫的表名Partitiontopic中的數(shù)據(jù)分割為一個或多個partition。每個topic至少有一個partition。每個partition中的數(shù)據(jù)使用多個segment文件存儲。partition中的數(shù)據(jù)是有序的，如果topic有多個partition，消費數(shù)據(jù)時就不能保證數(shù)據(jù)的順序。在需要嚴格保證消息的消費順序的場景下，需要將partition數(shù)目設(shè)為1。Kafka原理Producer生產(chǎn)者即數(shù)據(jù)的發(fā)布者，該角色將消息發(fā)布到Kafka的topic中。broker接收到生產(chǎn)者發(fā)送的消息后，broker將該消息追加到當前用于追加數(shù)據(jù)的segment文件中。生產(chǎn)者發(fā)送的消息，存儲到一個partition中，生產(chǎn)者也可以指定數(shù)據(jù)存儲的partition。Consumer消費者可以從broker中讀取數(shù)據(jù)。消費者可以消費多個topic中的數(shù)據(jù)。ConsumerGroup每個Consumer屬于一個特定的ConsumerGroup?？蔀槊總€Consumer指定groupname，若不指定groupname則屬于默認的group。Kafka原理Leader個partition有多個副本，其中有且僅有一個作為Leader，Leader是當前負責數(shù)據(jù)的讀寫