開(kāi)源軟件之消息系統(tǒng)-kafka簡(jiǎn)介

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

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

消息隊(duì)列滿了，其實(shí)就是籃子滿了，”雞蛋“放不下了，那趕緊多放幾個(gè)籃子，其實(shí)就是kafka的擴(kuò)容。

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

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

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

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