說起Kafka的第一個突出特定就是“快”，而且是那種變態的“快”。據最新的數據：每天利用Kafka處理的消息超過1萬億條，在峰值時每秒鐘會發布超過百萬條消息，就算是在內存和CPU都不高的情況下，Kafka的速度最高可以達到每秒十萬條數據，並且還能持久化存儲。那麼，Kafka是如何做到的呢？
Kafka簡介
Kafka是一種分佈式的，基於發佈/訂閱的消息系統。原本開發自LinkedIn，用作 LinkedIn的活動流（Activity Stream）和運營數據處理管道（Pipeline）的基礎。之後成為Apache項目的一部分，主要用於處理活躍的流式數據。
kafka有如下特性：
1、通過O(1)的磁盤數據結構提供消息的持久化，這種結構對於即使數以TB的消息存儲也能夠保持長時間的穩定性能；
2、高吞吐量：即使是非常普通的硬件kafka也可以支持每秒數十萬的消息；
3、支持通過kafka服務器和消費機集群來分區消息；
4、支持Hadoop並行數據加載。
Kafka 架構
Kafka的整體架構非常簡單，是顯式分佈式架構，producer、broker（kafka）和consumer都可以有多個。Producer，consumer實現Kafka註冊的接口，數據從 producer發送到broker，broker承擔一箇中間緩存和分發的作用。broker分發註冊到系統中的consumer。broker的作用類似於緩存，即活躍的數據和離線處理系統之間的緩存。
kafka相關名詞解釋如下：
1、producer：消息生產者，發佈消息到kafka集群的終端或服務。
2、broker：kafka集群中包含的服務器。
3、topic：每條發佈到kafka集群的消息屬於的類別，即kafka是面向topic的。
4、partition：partition是物理上的概念，每個topic包含一個或多個partition，kafka分配的單位是partition。
5、consumer：從kafka集群中消費消息的終端或服務。
6、Consumer group：high-level consumer API中，每個consumer都屬於一個consumer group，每條消息只能被consumer group的一個Consumer消費，但可以被多個consumer group消費。
7、replica：partition的副本，保障partition的高可用。
8、leader：replica中的一個角色， producer和consumer只跟leader交互。
9、follower：replica中的一個角色，從leader中複製數據。
10、controller：kafka集群中的其中一個服務器，用來進行leader election以及各種failover。
11、zookeeper：kafka通過zookeeper來存儲集群的meta信息。
Kafka有四個核心的API。客戶端和服務器端的通信，是基於簡單，高性能，且與編程語言無關的TCP協議。
因為每條消息都被append到該Partition中，屬於順序寫磁盤，因此效率非常高（經驗證，順序寫磁盤效率比隨機寫內存還要高，這是Kafka高吞吐率的一個很重要的保證）。Kafka集群分區日誌如下所示：
每個分區是一個有序的，不可變的記錄序列，不斷附加到結構化的提交日誌中。每個分區中的記錄都被分配一個順序的id號，稱為唯一標識分區中每個記錄的偏移量。
Kafka 應用場景
消息隊列
比起大多數的消息系統來說，Kafka有更好的吞吐量，內置的分區，冗餘及容錯性，這讓Kafka成為了一個很好的大規模消息處理應用的解決方案。
消息系統一般吞吐量相對較低，但是需要更小的端到端延時，並嚐嚐依賴於Kafka提供的強大的持久性保障。在這個領域，Kafka足以媲美傳統消息系統，如ActiveMR或RabbitMQ。
行為跟蹤
Kafka的另一個應用場景是跟蹤用戶瀏覽頁面、搜索及其他行為，以發佈-訂閱的模式實時記錄到對應的Topic裡。那麼這些結果被訂閱者拿到後，就可以做進一步的實時處理，或實時監控，或放到hadoop離線數據倉庫裡處理。
元信息監控
作為操作記錄的監控模塊來使用，即彙集記錄一些操作信息，可以理解為運維性質的數據監控吧。
日誌收集
日誌收集方面，其實開源產品有很多，包括Scribe、Apache Flume。很多人使用Kafka代替日誌聚合（log aggregation）。
日誌聚合一般來說是從服務器上收集日誌文件，然後放到一個集中的位置（文件服務器或HDFS）進行處理。然而Kafka忽略掉文件的細節，將其更清晰地抽象成一個個日誌或事件的消息流。
這就讓Kafka處理過程延遲更低，更容易支持多數據源和分佈式數據處理。比起以日誌為中心的系統比如Scribe或者Flume來說，Kafka提供同樣高效的性能和因為複製導致的更高的耐用性保證，以及更低的端到端延遲。
流處理
這個場景可能比較多，也很好理解。保存收集流數據，以提供之後對接的Storm或其他流式計算框架進行處理。很多用戶會將那些從原始Topic來的數據進行階段性處理，彙總，擴充或者以其他的方式轉換到新的Topic下再繼續後面的處理。
例如一個文章推薦的處理流程，可能是先從RSS數據源中抓取文章的內容，然後將其丟入一個叫做“文章”的topic中；後續操作可能是需要對這個內容進行清理，比如回覆正常數據或者刪除重複數據，最後再將內容匹配的結果返還給用戶。
這就在一個獨立的Topic之外，產生了一系列的實時數據處理的流程。Strom和Samza是非常著名的實現這種類型數據轉換的框架。
事件源
事件源是一種應用程序設計的方式，該方式的狀態轉移被記錄為按時間順序排序的記錄序列。Kafka可以存儲大量的日誌數據，這使得它成為一個對這種方式的應用來說絕佳的後臺。比如動態彙總（News feed）。
Kafka可以為一種外部的持久性日誌的分佈式系統提供服務。這種日誌可以在節點間備份數據，併為故障節點數據回覆提供一種重新同步的機制。Kafka中日誌壓縮功能為這種用法提供了條件。在這種用法中，Kafka類似於Apache BookKeeper項目。
閱讀更多 手機用戶102108520067 的文章
