天天看點

[喵咪KafKa(1)]KafKa的介紹以及使用場景[喵咪KafKa(1)]KafKa的介紹以及使用場景

[喵咪KafKa(1)]KafKa的介紹以及使用場景[喵咪KafKa(1)]KafKa的介紹以及使用場景

哈喽!大家好呀,真是一坑未平一坑又起,otter還在繼續更新的同時,筆者也為大家帶來了關于kafka相關的一系列部落格,要說到kafka就離不開現在特别火熱的大資料技術,了解的童鞋可能隻要一些大資料的帶名詞比如hadoop,spark,storm,包括最近很火的微服務,kafka也是其中一員,但是不同的是kafka并不負責處理資料,要給kafka一個定義的話應該是一個分布式釋出訂閱消息系統可以說是一個資料通道保證資料穩定傳輸,要是感興趣就開始和喵咪開始一場kafka的冒險吧!

附上:

筆者是怎麼了解到kafka的呢?其實這個也源于infoq大會的功勞(infoq大會是一個技術架構分享峰會),在之間有很多大家耳熟能詳的公司來分享一些技術,大家在談論大資料技術的時候使用到了本文開篇提的hadoop,spark,storm此類技術,但是他們都要有一個共同點,就是大部分使用了kafka作為了資料傳輸的通道,并且還有很多不需要使用到大資料的公司也在使用kafka,為什麼都要使用kafka呢?kafka能支撐大資料處理嗎,kafka還能做什麼,筆者帶着這些疑問,開始對kafka進行了了解!

kafka是一款由apache軟體基金會開源,由scala編寫的一個分布式釋出訂閱消息系統,kafka最初是由linkedin開發,并于2011年初開源(知道這個就夠了),kafka它最初的目的是為了解決,統一,高效低延時,高通量(同時能傳輸的資料量)并且高可用一個消息平台.

說的更簡單易懂一點就是幫助程式之間互相傳遞消息,并且提供一些保證,所有的大資料處理也好,微服務也好他們都有一個共同的需求就是一個穩定的資料通道,kafka剛好就是一個穩定高效通道最佳選擇!

broker:對于kafka叢集來說,每一個kafka執行個體都被稱為一個broker

topic(主題):在kafka中每一條消息都所屬一個topic下,topic之間是完全實體隔離的

partitine(分區):一個topic下面可以擁有一個到多個partitine,partitine也是實體層面的隔離

peoduker(生産者):向kafka的topic釋出消息

consumer(消費者):向topic注冊,并且接收釋出到這些topic的消息

筆者也是總結了一些關于kafka的一些特性如下:

kafka接收到的消息最終會以檔案的形式存在本地保證了,隻要消息接受成功理論上就不會丢失

kafka通過append來實作消息的追加,保證消息都是有序的有先來後到的順序

kafka叢集有良好的容災機制,比如有n台伺服器,可以承受n-1台伺服器故障是保證送出的消息不會丢失

kafka會更具topic以及partition來進行消息在本地的實體劃分

kafka依賴zookeeper實作了offset,你不用關心到你擷取了那些消息kafka會知道并且在你下次擷取時接着給你

你可以擷取任意一個offset的記錄

消息可以在kafka内儲存很長的時間也可以很短,kafka基于檔案系統能存儲消息的容量取決于硬碟空間

kafka的性能不會受到消息的數量影響

kafka可以代替傳統的消息隊列軟體(阿裡的隊列軟體rocketmq就是基于kafka實作的),在隊列軟體的選擇上kafka已經成了不二之選,使用kafka來實作隊列有如下優點

kafka的append來實作消息的追加,保證消息都是有序的有先來後到的順序,

穩定性強隊列在使用中最怕丢失資料,kafka能做到理論上的寫成功不丢失

分布式容災好

容量大相對于記憶體隊列,kafka的容量受硬碟影響

資料量不會影響到kafka的速度

就以上幾點和筆者之前使用的redis來承載隊列服務要優秀的多,在後續文章的比較中會一一說明

在很多時候我們需要對一些龐大的資料進行存留,一些業務型公司可能永不上應為基本可以依靠資料庫解決日志的問題,但是服務型公司比如jpush,雲監控此類服務,日志存儲這塊會遇到巨大的問題,日志不能丢,日志存檔案不好找,定位一條消息成本高(周遊當天日志檔案),實時顯示給使用者難,這幾類問題kafka都能遊刃有餘

kafka的叢集備份機制能做到n/2的可用,當n/2以下的機器當機時存儲的日志不會丢失

kafka可以對消息進行分組分片,并且通過offset可以做到擷取中間莫一條消息(通過算法很容易的到莫個時段的日志)

kafka非常容易做到實時日志查詢,可以從日志尾部擷取需要顯示給使用者查詢的資料即可

kafka特有的offset機制能夠保證消息至少被擷取一次,當程式在擷取途中死亡這條消息會被認定為未被消費,下次會繼續消費這條消息,此特性使得kafka可以作為一個保障資料傳輸的通道來使用,但是kafka并沒有提供jms中的"事務性""消息傳輸擔保(消息确認機制)""消息分組"等企業級特性;是以kafka隻能使用作為"正常"的消息系統

本節簡單介紹了一下kafka的一些相關知識,在後續的博文中喵咪将會從搭建單機到叢集對kafka進行優化測試等場景進行說明,那麼今天的就到這裡了,再次感謝大家的支援!

注:筆者能力有限有說的不對的地方希望大家能夠指出,也希望多多交流!