Kafka相關

1、Kafka概念

Apache Kafka是由Apache開發的一種發佈訂閱消息系統，它是一個分佈式的、分區的和重複的日誌服務。

傳統的消息傳遞方法：

排隊：在隊列中，一組用戶能夠從服務器中讀取消息，每條消息都發送給其中一我的。

發佈-訂閱：在這個模型中，消息被廣播給全部的用戶

kafka的優點：

快速：單一的Kafka代理能夠處理成千上萬的客戶端，每秒處理數兆字節的讀寫操做。

可伸縮：在一組機器上對數據進行分區和簡化，以支持更大的數據

持久：消息是持久性的，並在集羣中進行復制，以防止數據丟失。

設計：它提供了容錯保證和持久性

kafka的缺陷：

沒有完整的監控工具集

消息調整的問題

不支持通配符主題選擇

速度問題

2、Kafka應用場景

一、日誌收集：一個公司的各類應用均可以做爲生產者將日誌吐到kafka，再由hbase，solr，es等來消費kafka的日誌做統計，查錯。

二、消息系統：解耦和生產者和消費者、緩存消息等。

三、用戶活動跟蹤：Kafka常常被用來記錄web用戶或者app用戶的各類活動，如瀏覽網頁、搜索、點擊等活動，這些活動信息被各個服務器發佈到kafka的topic中，而後訂閱者經過訂閱這些topic來作實時的監控分析，或者裝載到hadoop、數據倉庫中作離線分析和挖掘。

四、運營指標：Kafka也常常用來記錄運營監控數據。包括收集各類分佈式應用的數據，生產各類操做的集中反饋，好比報警和報告

3、Kafka相關組件

主題：Kafka主題是一堆或一組消息。

生產者：在Kafka，生產者發佈通訊以及向Kafka主題發佈消息。

消費者：Kafka消費者訂閱了一個主題，而且還從主題中讀取和處理消息。

經紀人：在管理主題中的消息存儲時，咱們使用Kafka Brokers。

4、Kafka消息是採用Pull模式，仍是Push模式？

Kafka採用Pull模式。

一、解決了當broker推送的速率遠大於consumer消費的速率時的狀況。

二、consumer能夠自主決定是否批量的從broker拉取數據。避免了Push模式下爲了不consumer崩潰而採用較低的推送速率，形成資源浪費。

Pull有個缺點是，若是broker沒有可供消費的消息，將致使consumer不斷在循環中輪詢，直到新消息到達。爲了不這點，Kafka有個參數可讓consumer阻塞知道新消息到達。

5、Zookeeper

Zookeeper是一個開放源碼的、高性能的協調服務，它用於Kafka的分佈式應用。

不可能越過Zookeeper，直接聯繫Kafka broker。一旦Zookeeper中止工做，它就不能服務客戶端請求。

Zookeeper做用：

一、Zookeeper主要用於在集羣中不一樣節點之間進行通訊

二、在Kafka中，它被用於提交偏移量，所以若是節點在任何狀況下都失敗了，它均可以從以前提交的偏移量中獲取

三、它還執行其餘活動，如: leader檢測、分佈式同步、配置管理、識別新節點什麼時候離開或鏈接、集羣、節點實時狀態等等。

6、解決kafka的數據丟失

Producer端：

宏觀上看保證數據的可靠安全性，確定是依據分區數作好數據備份，設立副本數。

Broker端：

topic設置多分區，分區自適應所在機器，爲了讓各分區均勻分佈在所在的broker中，分區數要大於broker數。分區是kafka進行並行讀寫的單位，是提高kafka速度的關鍵。

Consumer端

consumer端丟失消息的情形比較簡單：若是在消息處理完成前就提交了offset，那麼就有可能形成數據的丟失。因爲Kafka consumer默認是自動提交位移的，因此在後臺提交位移前必定要保證消息被正常處理了，所以不建議採用很重的處理邏輯，若是處理耗時很長，則建議把邏輯放到另外一個線程中去作。爲了不數據丟失，現給出兩點建議：

一、enable.auto.commit=false  關閉自動提交位移二、在消息被完整處理以後再手動提交位移