今天要介紹的是消息中間件KafKa，應該說是一個很牛的中間件吧，背靠Apache 與很多有名的中間件搭配起來用效果更好哦 ，為什麼不用RabbitMQ，因為公司需要它。
網上已經有很多怎麼用和用到哪的内容，但結果很多人都倒在了入門第一步 環境都搭不起來，可謂是從了解到放棄，是以在此特記錄如何在linux環境搭建，windows中配置一樣，隻是啟動運作bat檔案。
想要用它就先必須了解它能做什麼及能做到什麼程度，先看看它是什麼吧。
當今社會各種應用系統諸如商業、社交、搜尋、浏覽等像資訊工廠一樣不斷的生産出各種資訊，在大資料時代，我們面臨如下幾個挑戰： 如何收集這些巨大的資訊 如何分析它 如何及時做到如上兩點 以上幾個挑戰形成了一個業務需求模型，即生産者生産（produce）各種資訊，消費者消費（consume）（處理分析）這些資訊，而在生産者與消費者之間，需要一個溝通兩者的橋梁-消息系統。從一個微觀層面來說，這種需求也可了解為不同的系統之間如何傳遞消息。
kafka 應用場景 日志收集：一個公司可以用Kafka可以收集各種服務的log，通過kafka以統一接口服務的方式開放給各種consumer，例如hadoop、Hbase、Solr等。 消息系統：解耦和生産者和消費者、緩存消息等。 使用者活動跟蹤：Kafka經常被用來記錄web使用者或者app使用者的各種活動，如浏覽網頁、搜尋、點選等活動，這些活動資訊被各個伺服器釋出到kafka的topic中，然後訂閱者通過訂閱這些topic來做實時的監控分析，或者裝載到hadoop、資料倉庫中做離線分析和挖掘。 營運名額：Kafka也經常用來記錄營運監控資料。包括收集各種分布式應用的資料，生産各種操作的集中回報，比如報警和報告。 流式處理：比如spark streaming和storm 事件源 解耦 在項目啟動之初來預測将來項目會碰到什麼需求，是極其困難的。消息系統在處理過程中間插入了一個隐含的、基于資料的接口層，兩邊的處理過程都要實作這一接口。這允許你獨立的擴充或修改兩邊的處理過程，隻要確定它們遵守同樣的接口限制。 備援有些情況下，處理資料的過程會失敗。除非資料被持久化，否則将造成丢失。消息隊列把資料進行持久化直到它們已經被完全處理，通過這一方式規避了資料丢失風險。許多消息隊列所采用的"插入-擷取-删除"範式中，在把一個消息從隊列中删除之前，需要你的處理系統明确的指出該消息已經被處理完畢，進而確定你的資料被安全的儲存直到你使用完畢。 擴充性 因為消息隊列解耦了你的處理過程，是以增大消息入隊和處理的頻率是很容易的，隻要另外增加處理過程即可。不需要改變代碼、不需要調節參數。擴充就像調大電力按鈕一樣簡單。 靈活性 & 峰值處理能力 在通路量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量并不常見；如果為以能處理這類峰值通路為标準來投入資源随時待命無疑是巨大的浪費。使用消息隊列能夠使關鍵元件頂住突發的通路壓力，而不會因為突發的超負荷的請求而完全崩潰。 可恢複性 系統的一部分元件失效時，不會影響到整個系統。消息隊列降低了程序間的耦合度，是以即使一個處理消息的程序挂掉，加入隊列中的消息仍然可以在系統恢複後被處理。 順序保證 在大多使用場景下，資料處理的順序都很重要。大部分消息隊列本來就是排序的，并且能保證資料會按照特定的順序來處理。Kafka能保證一個Partition内的消息的有序性。 緩沖 在任何重要的系統中，都會有需要不同的處理時間的元素。例如，加載一張圖檔比應用過濾器花費更少的時間。消息隊列通過一個緩沖層來幫助任務最高效率的執行———寫入隊列的處理會盡可能的快速。該緩沖有助于控制和優化資料流經過系統的速度。 用于資料流 在一個分布式系統裡，要得到一個關于使用者操作會用多長時間及其原因的總體印象，是個巨大的挑戰。消息系列通過消息被處理的頻率，來友善的輔助确定那些表現不佳的處理過程或領域，這些地方的資料流都不夠優化。 異步通信 很多時候，使用者不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許使用者把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然後在需要的時候再去處理它們。
Kafka主要特點： 同時為釋出和訂閱提供高吞吐量。據了解，Kafka每秒可以生産約25萬消息（50 MB），每秒處理55萬消息（110 MB）。 可進行持久化操作。将消息持久化到磁盤，是以可用于批量消費，例如ETL，以及實時應用程式。通過将資料持久化到硬碟以及replication防止資料丢失。 分布式系統，易于向外擴充。所有的producer、broker和consumer都會有多個，均為分布式的。無需停機即可擴充機器。 消息被處理的狀态是在consumer端維護，而不是由server端維護。當失敗時能自動平衡。 支援online和offline的場景。 Kafka的架構： Kafka 的整體架構非常簡單，是顯式分布式架構，producer、broker（kafka）和consumer都可以有多個。 Producer，consumer實作Kafka注冊的接口，資料從producer發送到broker，broker承擔一個中間緩存和分發的作用。 broker分發注冊到系統中的consumer。broker的作用類似于緩存，即活躍的資料和離線處理系統之間的緩存。用戶端和伺服器端的通信，是基 于簡單，高性能，且與程式設計語言無關的TCP協定。
幾個基本概念：
Topic：特指Kafka處理的消息源（feeds of messages）的不同分類。
Partition：Topic實體上的分組，一個topic可以分為多個partition，每個partition是一個有序的隊列。partition中的每條消息都會被配置設定一個有序的id（offset）。
Message：消息，是通信的基本機關，每個producer可以向一個topic（主題）釋出一些消息。
Producers：消息和資料生産者，向Kafka的一個topic釋出消息的過程叫做producers。
Consumers：消息和資料消費者，訂閱topics并處理其釋出的消息的過程叫做consumers。
Broker：緩存代理，Kafa叢集中的一台或多台伺服器統稱為broker。
消息發送的流程：
Producer根據指定的partition方法（round-robin、hash等），将消息釋出到指定topic的partition裡面
kafka叢集接收到Producer發過來的消息後，将其持久化到硬碟，并保留消息指定時長（可配置），而不關注消息是否被消費。
Consumer從kafka叢集pull資料，并控制擷取消息的offset
CentOS7.0
kafka_2.11-0.10.1.0版本
用root使用者安裝
Java環境，最好是最新版本的。
安裝Zookeeper
分布式時多機間要確定能正常通訊，關閉防火牆或讓涉及到的端口通過。
去官網下載下傳 ：http://kafka.apache.org/downloads.html 選擇最新版本（在此下載下傳編譯好的包，不要下載下傳src源碼包）。
下載下傳後放進CentOS中的/usr/local/ 檔案夾中，并解壓到目前檔案中 /usr/local/kafka212
由于Kafka叢集需要依賴ZooKeeper叢集來協同管理，是以需要事先搭建好ZK叢集。
将壓縮檔案夾壓到目前檔案夾
進入config目錄，修改server.properties檔案
vi server.properties
注意：
broker.id=0 值每台伺服器上的都不一樣
jps
顯示包含
25014 QuorumPeerMain
25778 Kafka
檢視目錄情況
顯示
[controller_epoch, controller, brokers, zookeeper, test, admin, isr_change_notification, consumers, config]
找到為0的leader的程序，并殺死
啟動各伺服器上的kafka後，有機器通路主機時出現：
WARN Fetching topic metadata with correlation id 5 for topics [Set(hotnews)] from broker [BrokerEndPoint(1,H33,9092)] failed (kafka.client.ClientUtils$)
這裡需要關閉機器的防火牆或将9092加入防火牆。
Kafka在分布式設計中有着相當重要的作用，算是一個基礎工具，是以需要不斷的學習了解與實踐，如何處理大并發訂單這隻是一種場景。
這裡留有一個問題：如何确定Kafka的分區數、key和consumer線程數
本文轉自歡醉部落格園部落格，原文連結http://www.cnblogs.com/zhangs1986/p/6565639.html如需轉載請自行聯系原作者
歡醉