Kakfa概述及安裝過程

1. kafka是由linkedin（領英）開發的乙個分布式的訊息系統，最初是用作linkedin的活動流（activity stream）和運營資料處理的基礎

a. 活動流資料報括頁面訪問量（page view）、被檢視內容方面的資訊以及搜尋情況等內容。這種資料通常的處理方式是先把各種活動以日誌的形式寫入某種檔案，然後周期性地對這些檔案進行統計分析

b. 運營資料指的是伺服器的效能資料（cpu、io使用率、請求時間、服務日誌等等資料)。運營資料的統計方法種類繁多。　

2. kafka是乙個分布式的流式處理平台，主要包含三個功能　　　　

a. 發布和訂閱資料，類似於訊息佇列或者企業中的訊息傳遞系統

b. 儲存資料的時候有容錯（分布式+複本機制）和持久化機制

c. 資料產生的時候處理記錄（資料）

3. 應用場景

a. 在系統或者應用程式之間構建可靠的資料傳輸的實時流管道

b. 在轉換或者響應資料流的時候構建實時流程式

4. kafka使用scala編寫，它以可水平擴充套件和高吞吐率而被廣泛使用。

目前越來越多的開源分布式處理系統如cloudera、apache storm、spark都支援與kafka整合

5.kafla之間傳輸資料是使用的零拷貝技術a. rabbitmq是使用erlang編寫的乙個開源的訊息佇列，本身支援很多的協議：amqp，xmpp, smtp, stomp，也正因如此，它非常重量級，更適合於企業級的開發

b. 實現了broker構架，這意味著訊息在傳送給客戶端時先在中心佇列排隊。對路由，負載均衡或者資料持久化都有很好的支援

a. redis是乙個基於key-value對的nosql資料庫，開發維護很活躍

b. 雖然它是乙個key-value資料庫儲存系統，但它本身支援mq功能，所以完全可以當做乙個輕量級的佇列服務來使用

a. zeromq號稱最快的訊息佇列系統，尤其針對大吞吐量的需求場景

b. zeromq能夠實現rabbitmq不擅長的高階/複雜的佇列，但是開發人員需要自己組合多種技術框架，技術上的複雜度是對這mq能夠應用成功的挑戰

c. zeromq僅提供非永續性的佇列，也就是說如果宕機，資料將會丟失。其中，twitter的storm 0.9.0以前的版本中預設使用zeromq作為資料流的傳輸（storm從0.9版本開始同時支援zeromq和netty（nio）作為傳輸模組）

a. activemq是apache下的乙個子專案　　

b. 類似於zeromq，它能夠以**人和點對點的技術實現佇列，

c.類似於rabbitmq，它少量**就可以高效地實現高階應用場景。

a. 遮蔽生產者和消費者之間的異構型

b.實現消峰限流

a. 對於一些常規的訊息系統,kafka是個不錯的選擇，partitons/replication和容錯,可以使kafka具有良好的擴充套件性和效能優勢

b. kafka並沒有提供jms中的"事務性""訊息傳輸擔保(訊息確認機制)""訊息分組"等企業級特性；kafka只能使用作為"常規"的訊息系統,在一定程度上,尚未確保訊息的傳送與接收絕對可靠(比如,訊息重發,訊息傳送丟失等)

a. kafka可以作為"**活性跟蹤"的最佳工具;可以將網頁/使用者操作等資訊傳送到kafka中.並實時監控,或者離線統計分析等

a. kafka通常被用於可操作的監控資料。這包括從分布式應用程式來的聚合統計用來生產集中的運營資料提要。

a. kafka的特性決定它非常適合作為"日誌收集中心"；

c. kafka可以批量提交訊息/壓縮訊息等，這對producer端而言,幾乎感覺不到效能的開支。此時consumer端可以使hadoop等其他系統化的儲存和分析系統

wget

tar -zxvf kafka_2.11-2.3.0.tgz

cd kafka_2.11-2.3.0/config

vim server.properties

21行：broker.id=0（隨意不重複即可）

60行：配置日誌路徑

123行：配置zookeeper集群