Kafka是由LinkedIn開發的一個分佈式基於發佈/訂閱的消息系統,使用Scala編寫,它以可水平擴展和高吞吐率而被普遍使用。面試
Kafka是一個消息系統,用做LinkedIn的活動流(Activity Stream)和運營數據處理管道(Pipeline)的基礎。活動流數據是幾乎全部站點在對其網站使用狀況作報表時都要用到的數據中最常規的部分。服務器
活動數據包括頁面訪問量(Page View)、被查看內容方面的信息以及搜索狀況等內容。這種數據一般的處理方式是先把各類活動以日誌的形式寫入某種文件,而後週期性地對這些文件進行統計分析。架構
運營數據指的3是服務器的性能數據(CPU、IO使用率、請求時間、服務日誌等等數據)。運營數據的統計方法種類繁多。app
Kafka集羣包含一個或多個服務器,這種服務器被稱爲broker。broker端不維護數據的消費狀態,提高了性能。直接使用磁盤進行存儲,線性讀寫,速度快:避免了數據在JVM內存和系統內存之間的複製,減小耗性能的建立對象和垃圾回收。異步
負責發佈消息到Kafka broke分佈式
消息消費者,向Kafka broker讀取消息的客戶端,consumer從broker拉取(pull)數據並進行處理。工具
每條發佈到Kafka集羣的消息都有一個類別,這個類別被稱爲Topic。(物理上不一樣Topic的消息分開存儲,邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic便可生產或消費數據而沒必要關心數據存於何處)oop
Parition是物理上的概念,每一個Topic包含一個或多個Partition.性能
每一個Consumer屬於一個特定的Consumer Group(可爲每一個Consumer指定group name,若不指定group name則屬於默認的group)網站
Topic在邏輯上能夠被認爲是一個queue,每條消費都必須指定它的Topic,能夠簡單理解爲必須指明把這條消息放進哪一個queue裏。爲了使得Kafka的吞吐率能夠線性提升,物理上把Topic分紅一個或多個Partition,每一個Partition在物理上對應一個文件夾,該文件夾下存儲這個Partition的全部消息和索引文件。
若建立topic1和topic2兩個topic,且分別有13個和19個分區,則整個集羣上會相應會生成共32個文件夾(本文所用集羣共8個節點,此處topic1和topic2 replication-factor均爲1)。
對於一些常規的消息系統,kafka是個不錯的選擇;partitons/replication和容錯,可使kafka具備良好的擴展性和性能優點.不過到目前爲止,咱們應該很清楚認識到,kafka並無提供JMS中的"事務性""消息傳輸擔保(消息確認機制)""消息分組"等企業級特性;kafka只能使用做爲"常規"的消息系統,在必定程度上,還沒有確保消息的發送與接收絕對可靠(好比,消息重發,消息發送丟失等)
kafka能夠做爲"網站活性跟蹤"的最佳工具;能夠將網頁/用戶操做等信息發送到kafka中.並實時監控,或者離線統計分析等
Kafka一般被用於可操做的監控數據。這包括從分佈式應用程序來的聚合統計用來生產集中的運營數據提要。
kafka的特性決定它很是適合做爲"日誌收集中心";application能夠將操做日誌"批量""異步"的發送到kafka集羣中,而不是保存在本地或者DB中;kafka能夠批量提交消息/壓縮消息等,這對producer端而言,幾乎感受不到性能的開支.此時consumer端可使hadoop等其餘系統化的存儲和分析系統。
最後,關注公衆號民工哥技術之路,能夠獲取我整理的 消息隊列、中間件相關的技術文章、面試題精選,很是齊全。
連接:https://blog.csdn.net/code52/...