之前我介紹過RabbitMQ，RabbitMQ作為企業級的訊息佇列其實未必能滿足所有的需求，RabbitMQ在持久化、可靠性、訊息確認機制、任務分發等方面都非常優秀。但也因為這些原因導致RabbitMQ的效能受限。所以如果你需要一個對併發能力高而對可靠性、訊息確認等沒有這麼高要求的時候那麼kafka可能是一個不錯的選擇。

為什麼要使用訊息佇列

當然既然你開始學習Kafka了，很多人是知道要做什麼的，所有這部分如果你已經清楚為什麼要使用訊息佇列，請略過。

• 解耦

  　　在專案啟動之初來預測將來專案會碰到什麼需求，是極其困難的。訊息系統在處理過程中間插入了一個隱含的、基於資料的介面層，兩邊的處理過程都要實現這一介面。這允許你獨立的擴充套件或修改兩邊的處理過程，只要確保它們遵守同樣的介面約束。

• 冗餘

  　　有些情況下，處理資料的過程會失敗。除非資料被持久化，否則將造成丟失。訊息佇列把資料進行持久化直到它們已經被完全處理，通過這一方式規避了資料丟失風險。許多訊息佇列所採用的”插入-獲取-刪除”正規化中，在把一個訊息從佇列中刪除之前，需要你的處理系統明確的指出該訊息已經被處理完畢，從而確保你的資料被安全的儲存直到你使用完畢。

• 擴充套件性

  　　因為訊息佇列解耦了你的處理過程，所以增大訊息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變程式碼、不需要調節引數。擴充套件就像調大電力按鈕一樣簡單。

• 靈活性 & 峰值處理能力

  　　在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量並不常見；如果為以能處理這類峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用訊息佇列能夠使關鍵元件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全崩潰。

• 可恢復性

  　　系統的一部分元件失效時，不會影響到整個系統。訊息佇列降低了程序間的耦合度，所以即使一個處理訊息的程序掛掉，加入佇列中的訊息仍然可以在系統恢復後被處理。

• 順序保證

  　　在大多使用場景下，資料處理的順序都很重要。大部分訊息佇列本來就是排序的，並且能保證資料會按照特定的順序來處理。Kafka保證一個Partition內的訊息的有序性。當然序列性更多是kafka的特性並不是所有的訊息佇列都可以支援。

• 緩衝

  　　在任何重要的系統中，都會有需要不同的處理時間的元素。例如，載入一張圖片比應用過濾器花費更少的時間。訊息佇列通過一個緩衝層來幫助任務最高效率的執行———寫入佇列的處理會盡可能的快速。該緩衝有助於控制和優化資料流經過系統的速度。

• 非同步通訊

  　　很多時候，使用者不想也不需要立即處理訊息。訊息佇列提供了非同步處理機制，允許使用者把一個訊息放入佇列，但並不立即處理它。想向佇列中放入多少訊息就放多少，然後在需要的時候再去處理它們。

和RabbitMQ等傳統訊息佇列有什麼不同

如果一句話來說明Kafka和傳統訊息佇列的不同的話：傳統訊息佇列更側重可靠性和功能性，而Kafka更側重效能。Kafka單機可以支援十萬級別的併發能力，而RabbitMQ也就是一兩萬。

下面一張圖來看下幾種訊息佇列有什麼不同

Kafka應用場景

• 訊息

kafka更好的替換傳統的訊息系統，訊息系統被用於各種場景（解耦資料生產者，快取未處理的訊息，等），與大多數訊息系統比較，kafka有更好的吞吐量，內建分割槽，副本和故障轉移，這有利於處理大規模的訊息。

根據我們的經驗，訊息往往用於較低的吞吐量，但需要低的端到端延遲，並需要提供強大的耐用性的保證。

在這一領域的kafka比得上傳統的訊息系統，如的ActiveMQ或RabbitMQ的。

• 網站活動追蹤

kafka原本的使用場景：使用者的活動追蹤，網站的活動（網頁遊覽，搜尋或其他使用者的操作資訊）釋出到不同的話題中心，這些訊息可實時處理，實時監測，也可載入到Hadoop或離線處理資料倉庫。

每個使用者頁面檢視都會產生非常高的量。

• 指標

kafka也常常用於監測資料。分散式應用程式生成的統計資料集中聚合。

• 日誌聚合

使用kafka代替一個日誌聚合的解決方案。

• 流處理

kafka訊息處理包含多個階段。其中原始輸入資料是從kafka主題消費的，然後彙總，豐富，或者以其他的方式處理轉化為新主題，例如，一個推薦新聞文章，文章內容可能從“articles”主題獲取；然後進一步處理內容，得到一個處理後的新內容，最後推薦給使用者。這種處理是基於單個主題的實時資料流。從0.10.0.0開始，輕量，但功能強大的流處理，就進行這樣的資料處理了。

除了Kafka Streams，還有Apache Storm和Apache Samza可選擇。

• 事件採集

事件採集是一種應用程式的設計風格，其中狀態的變化根據時間的順序記錄下來，kafka支援這種非常大的儲存日誌資料的場景。

• 提交日誌

kafka可以作為一種分散式的外部提交日誌，日誌幫助節點之間複製資料，並作為失敗的節點來恢復資料重新同步，kafka的日誌壓縮功能很好的支援這種用法，這種用法類似於Apacha BookKeeper專案。

Kafka建立背景

Kafka是一個訊息系統，原本開發自LinkedIn，用作LinkedIn的活動流（Activity Stream）和運營資料處理管道（Pipeline）的基礎。現在它已被多家不同型別的公司 作為多種型別的資料管道和訊息系統使用。
　　活動流資料是幾乎所有站點在對其網站使用情況做報表時都要用到的資料中最常規的部分。活動資料包括頁面訪問量（Page View）、被檢視內容方面的資訊以及搜尋情況等內容。這種資料通常的處理方式是先把各種活動以日誌的形式寫入某種檔案，然後週期性地對這些檔案進行統計分析。運營資料指的是伺服器的效能資料（CPU、IO使用率、請求時間、服務日誌等等資料)。運營資料的統計方法種類繁多。
　　近年來，活動和運營資料處理已經成為了網站軟體產品特性中一個至關重要的組成部分，這就需要一套稍微更加複雜的基礎設施對其提供支援。

訊息佇列基本概念

請參考我之前寫的RabbitMQ的基本概念，差不多
http://blog.csdn.net/super_rd/article/details/70238869