kafka剖析(一)kafka背景及架構(gòu)介紹

《kafka剖析(一)kafka背景及架構(gòu)介紹》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在工程資料-天天文庫(kù)。

1、Kafka剖析(一)：Kafka背景及架構(gòu)介紹Kafka是由Linkedln開發(fā)的一個(gè)分布式的消息系統(tǒng)，使用Scala編寫，它以可水平擴(kuò)展和高吞吐率而被廣泛使用。門前越來(lái)越多的開源分布式處理系統(tǒng)如Cloudera、ApacheStorm、Spark都支持與Kafka集成。InfoQ—直在緊密關(guān)注Kafka的應(yīng)川以及發(fā)展,“Kafka剖析”專欄將會(huì)從架構(gòu)設(shè)計(jì)、實(shí)現(xiàn)、應(yīng)用場(chǎng)景、性能等方面深度解析Kafka。背景介紹Kafka創(chuàng)建背景Kafka是一個(gè)消，包系統(tǒng)，原木開發(fā)白Linkedln，用作Linkedln的灑動(dòng)流(Acti

2、vityStream)和運(yùn)背數(shù)裾處理管道(Pipeline)的某礎(chǔ)。現(xiàn)在它已被多家不同類型的公司作為多種類型的數(shù)據(jù)管道和消息系統(tǒng)使用?；顒?dòng)流數(shù)裾是幾乎所有站點(diǎn)在對(duì)站使用情況做報(bào)表時(shí)都要用到的數(shù)裾屮最常規(guī)的部分。活動(dòng)數(shù)據(jù)包括頁(yè)面訪14量(PageView)、被杏看內(nèi)界方血的信息以及搜索情況等內(nèi)界。這種數(shù)椐通常的處理方式是先把各種活動(dòng)以U志的形式寫入某種文件，然盾周期性地對(duì)這些文件進(jìn)行統(tǒng)計(jì)分析。運(yùn)營(yíng)數(shù)據(jù)指的是服務(wù)器的性能數(shù)據(jù)(CPU、10使用率、請(qǐng)求時(shí)間、服務(wù)LI志等等數(shù)拋)。運(yùn)營(yíng)數(shù)拋的統(tǒng)計(jì)方法種類繁多。近年來(lái)，活動(dòng)和運(yùn)營(yíng)數(shù)

3、裾處理己經(jīng)成為了網(wǎng)站軟件產(chǎn)品特性巾一個(gè)至關(guān)熏要的組成部分，這就需耍一袞稍微更加復(fù)雜的基礎(chǔ)設(shè)施對(duì)其提供支持。Kafka簡(jiǎn)介Kafka是一種分布式的，基于發(fā)布/訂閱的消息系統(tǒng)。主要設(shè)計(jì)目稱如下：?以時(shí)間復(fù)雜度為0(1)的方式提供消息持久化能力，即使對(duì)TB級(jí)以上數(shù)裾也能保證常數(shù)吋間復(fù)雜度的訪問性能。?高吞吐率。即使在非常廉價(jià)的商用機(jī)器上也能做到單機(jī)支持每秒100K條以上消息的傳輸。?文持KafkaServerI'uj的消息分區(qū)，及分布式消費(fèi)，同時(shí)保證每個(gè)Partition內(nèi)的消息順序傳輸。?M時(shí)支持離線數(shù)據(jù)處理和實(shí)時(shí)數(shù)據(jù)處理。

4、?Scaleout：支持在線水平擴(kuò)展。為何使用消息系統(tǒng)?解耦在項(xiàng)n啟動(dòng)之初來(lái)預(yù)測(cè)將來(lái)項(xiàng)n會(huì)碰到什么耑求，是極其w難的。消息系統(tǒng)在處理過程屮M插入了一個(gè)隱含的、基于數(shù)裾的接u層，兩邊的處理過程都要實(shí)現(xiàn)這一接u。這允許你獨(dú)立的擴(kuò)展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。?冗余有些情況下，處理數(shù)據(jù)的過程會(huì)失敗。除非數(shù)據(jù)被持久化，否則將造成丟失。消息隊(duì)列把數(shù)據(jù)進(jìn)行持久化直到它們己經(jīng)被完全處理，通過這-方式規(guī)避了數(shù)據(jù)￡失風(fēng)險(xiǎn)。許多消息隊(duì)列所采用的”插入-獲取?刪除"范式中，在把一個(gè)消息從隊(duì)列中刪除之前，需耍你的處理系

5、統(tǒng)明確的指出該消息已經(jīng)被處理完畢，從而確保你的數(shù)裾被安全的保存直到你使川完畢。?擴(kuò)展性因?yàn)橄㈥?duì)列解耦Y你的處理過稈，所以增人消息入隊(duì)和處理的頻率足很界易的，只要另外增加處理過程即可。不需耍改變代碼、不需要調(diào)甘參數(shù)。擴(kuò)展就像調(diào)大電力按鈕-樣簡(jiǎn)單。?靈活性&峰值處理能力在訪問量劇增的怙況下，應(yīng)用仍然需耍繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量并不常見；如果為以能處理這類峰位訪問為標(biāo)準(zhǔn)來(lái)投入資源隨時(shí)待命無(wú)疑是巨人的浪費(fèi)。使用消息隊(duì)列能夠使關(guān)鍵組件頂住突發(fā)的訪問壓力，而不會(huì)因?yàn)橥话l(fā)的超負(fù)份的請(qǐng)求而完全崩潰。?可恢復(fù)性系統(tǒng)的?一部分組件

6、失效時(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閃的消息的柯序性。?緩沖在任何重要的系統(tǒng)屮，都會(huì)有需要不同的處理吋間的元素。例如，加載一張圖片比應(yīng)川過濾器花貲更少的吋間。消息隊(duì)列通過一個(gè)緩沖e來(lái)幫助任務(wù)最高效率的執(zhí)行寫入隊(duì)列的處理會(huì)盡可能的快速。該緩沖行助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的

7、速度。?異步通信很多時(shí)候，用戶不想也不需耍立即處理消息。消息隊(duì)列提供了異步處理機(jī)制，允許用戶把一個(gè)消息放入隊(duì)列，但并不立即處理它。想m隊(duì)列屮放入多少消息就放多少，然后在需要的吋候再去處理它們。常用MessageQueue對(duì)比?RabbitMQRabbitMQ是使用Erlang編寫的一個(gè)開源的消息隊(duì)列，木身支持很多的協(xié)議：AMQP,XMPP，SMTP，STOMP,也正因如此，它非常重S級(jí)，更適合于企業(yè)級(jí)的開發(fā)。同時(shí)實(shí)現(xiàn)了Broker構(gòu)架，這意味著消息4:發(fā)送給客戶端時(shí)先奮:中心隊(duì)列排隊(duì)。對(duì)路由，負(fù)載均衡或者數(shù)裾持久化都有很

8、好的支持。?RedisRedis是一個(gè)基于Key-Value對(duì)的NoSQL數(shù)據(jù)庫(kù)，開發(fā)維護(hù)很活躍。雖然它是一個(gè)Key-Value數(shù)據(jù)庫(kù)存儲(chǔ)系統(tǒng)，但它本身支持MQ功能，所以完全對(duì)以當(dāng)做一個(gè)輕fi級(jí)的隊(duì)列服務(wù)來(lái)使用。對(duì)于RabbitMQ和Redis的入隊(duì)和出隊(duì)楝作，各執(zhí)行100萬(wàn)次，每10萬(wàn)次記錄一次執(zhí)行時(shí)間。測(cè)試數(shù)據(jù)分