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

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

前言##

哈嘍!你們好呀,真是一坑未平一坑又起,otter還在繼續更新的同時,筆者也爲你們帶來了關於kafka相關的一系列博客,要說到kafka就離不開如今特別火熱的大數據技術,瞭解的童鞋可能只要一些大數據的帶名詞好比Hadoop,spark,storm,包括最近很火的微服務,kafka也是其中一員,可是不一樣的是kafka並不負責處理數據,要給kafka一個定義的話應該是一個分佈式發佈訂閱消息系統能夠說是一個數據通道保證數據穩定傳輸,要是感興趣就開始和喵咪開始一場kafka的冒險吧!

附上:

喵了個咪的博客:w-blog.cn

KafKa官網地址:http://kafka.apache.org/

Git地址:https://github.com/apache/kafka

1. KafKa簡介##

初識KafKa

筆者是怎麼了解到KafKa的呢?其實這個也源於InfoQ大會的功勞(InfoQ大會是一個技術架構分享峯會),在之間有不少你們耳熟能詳的公司來分享一些技術,你們在談論大數據技術的時候使用到了本文開篇提的Hadoop,spark,storm此類技術,可是他們都要有一個共同點,就是大部分使用了KafKa做爲了數據傳輸的通道,而且還有不少不須要使用到大數據的公司也在使用KafKa,爲何都要使用KafKa呢?KafKa能支撐大數據處理嗎,KafKa還能作什麼,筆者帶着這些疑問,開始對KafKa進行了瞭解!

kafKa是什麼

KafKa是一款由Apache軟件基金會開源,由Scala編寫的一個分佈式發佈訂閱消息系統,Kafka最初是由LinkedIn開發，並於2011年初開源(知道這個就夠了),KafKa它最初的目的是爲了解決,統一,高效低延時,高通量(同時能傳輸的數據量)而且高可用一個消息平臺.

說的更簡單易懂一點就是幫助程序之間互相傳遞消息,而且提供一些保證,全部的大數據處理也好,微服務也好他們都有一個共同的需求就是一個穩定的數據通道,KafKa恰好就是一個穩定高效通道最佳選擇!

KafKa中的幾個角色

• broker:對於KafKa集羣來講,每個KafKa實例都被稱爲一個broker
• Topic(主題):在KafKa中每一條消息都所屬一個Topic下,Topic之間是徹底物理隔離的
• Partitine(分區):一個Topic下面能夠擁有一個到多個Partitine,Partitine也是物理層面的隔離
• peoduker(生產者):向kafka的Topic發佈消息
• consumer(消費者):向Topic註冊，而且接收發布到這些Topic的消息

KafKa的特性

筆者也是總結了一些關於KafKa的一些特性以下:

• kafka接收到的消息最終會以文件的形式存在本地保證了,只要消息接受成功理論上就不會丟失
• KafKa經過append來實現消息的追加,保證消息都是有序的有先來後到的順序
• KafKa集羣有良好的容災機制,好比有N臺服務器,能夠承受N-1臺服務器故障是保證提交的消息不會丟失
• KafKa會更具Topic以及partition來進行消息在本地的物理劃分
• KafKa依賴zookeeper實現了offset,你不用關心到你獲取了那些消息KafKa會知道而且在你下次獲取時接着給你
• 你能夠獲取任意一個offset的記錄
• 消息能夠在KafKa內保存很長的時間也能夠很短,KafKa基於文件系統能存儲消息的容量取決於硬盤空間
• KafKa的性能不會受到消息的數量影響

2. KafKa的使用場景##

消息隊列(MQ)

KafKa能夠代替傳統的消息隊列軟件(阿里的隊列軟件RocketMQ就是基於KafKa實現的),在隊列軟件的選擇上KafKa已經成了不二之選,使用KafKa來實現隊列有以下優勢

• KafKa的append來實現消息的追加,保證消息都是有序的有先來後到的順序,
• 穩定性強隊列在使用中最怕丟失數據,KafKa能作到理論上的寫成功不丟失
• 分佈式容災好
• 容量大相對於內存隊列,KafKa的容量受硬盤影響
• 數據量不會影響到KafKa的速度

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

分佈式日誌系統(Log)

在不少時候咱們須要對一些龐大的數據進行存留,一些業務型公司可能永不上應爲基本能夠依靠數據庫解決日誌的問題,可是服務型公司好比jpush,雲監控此類服務,日誌存儲這塊會遇到巨大的問題,日誌不能丟,日誌存文件很差找,定位一條消息成本高(遍歷當天日誌文件),實時顯示給用戶難,這幾類問題KafKa都能遊刃有餘

• KafKa的集羣備份機制能作到n/2的可用,當n/2如下的機器宕機時存儲的日誌不會丟失
• KafKa能夠對消息進行分組分片,而且經過offset能夠作到獲取中間莫一條消息(經過算法很容易的到莫個時段的日誌)
• KafKa很是容易作到實時日誌查詢,能夠從日誌尾部獲取須要顯示給用戶查詢的資料便可

數據通道(Messaging)

kafka特有的offset機制可以保證消息至少被獲取一次,當程序在獲取途中死亡這條消息會被認定爲未被消費,下次會繼續消費這條消息,此特性使得kafka能夠做爲一個保障數據傳輸的通道來使用,可是kafka並無提供JMS中的"事務性""消息傳輸擔保(消息確認機制)""消息分組"等企業級特性;因此kafka只能使用做爲"常規"的消息系統

3. 總結##

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

注:筆者能力有限有說的不對的地方但願你們可以指出,也但願多多交流!