1.2 使用案例
消息處理
kafka是一個很好的傳統消息代理（message broker）替代產品。使用消息代理有幾種原因：解耦生產者與消息處理、緩存消息等。與大多數消息系統相比，kafka有更好的吞吐量，內置分區，復制和容錯性，這使它成為大規模消息處理應用很好的解決方案。
根據我們的經驗，消息傳遞的使用往往是相對較低的吞吐量，但可能需要較低的端到端延遲，并且通常取決于Kafka提供的強大的持久性保證。
在這個領域，Kafka與傳統的消息系統（如ActiveMQ或RabbitMQ）相當。
網站行為跟蹤
kafka的原始用例（為此而生）是能重建一套可以實時發布，實時訂閱消息，用于處理用戶活動軌跡跟蹤的管道。也就是說網站的活動（頁面瀏覽、搜索、用戶其它行為）可以按活動類型分別發布到各自的主題；這些訂閱可以被用于后續各種用途：包括實時處理、實時監控、加載到hadoop、離線數據倉庫以進行離線處理和生成報告。
因為每個用戶瀏覽頁面都會產生活動消息，因此，活動跟蹤數據量非常大。
Metrics度量
Kafka經常被用于處理監控數據。這涉及到從分布式應用收集統計數據，并且做為后續分析的一個統一的數據源。（即分布式統計數據查詢入口或代理）
日志收集
很多人把kafka做為日志收集解決方案的替代品。日志收集是從服務器上采集日志文件并把它們放入一個集中位置（如：文件服務器或hdfs）進行處理。kafka抽象了文件細節，并將日志或事件數據作為消息流進行更清晰的抽象。這樣可以實現更低延遲的處理，更容易支持多數據源以及分布式消息處理。與Scribe和Flume相比，kafka提供同樣的良好性能，并提供更好的可用性（因為多個副本），和更低的延時。
流處理
Kafka的許多用戶在處理管道中處理數據，這些數據由多個階段組成，其中原始輸入數據從Kafka topic中消費，然后聚合，補充或以其他方式轉化為新的topic，供進一步消費或后續處理。通過kafka topics串聯起所有步驟，形成一個數據處理通道。
如：一個處理新聞的流程：首先通過RSS收集新聞，并發布到”articles”主題中；第二步，從“articles”主題中取新聞并清洗重復內容，然后發布一個新的主題中；最后，從上步的主題中取數據并推薦給用戶。
這樣的處理管道是基于單個主題的實時數據流程圖。從0.10.0.0版本開始，一個輕量但強大的，被稱為kafka stream的功能用于處理這樣的數據。除了Kafka stream還有另外相似的開源工具：Apache Storm / Apache Samza。
事件溯源（Event Sourcing）
事件溯源是應用程序設計的一種風格，其中狀態更改以時間排序的記錄序列進行記錄。 Kafka對非常大的存儲日志數據的支持使得它成為以這種風格構建的應用程序的優秀后端。
提交日志Commit Log
kafka可以做為分布式系統的外部提交日志服務器?？梢詭椭植际焦濣c存儲數據失敗時，做為重新同步機制，在節點與操作之間復制日志，以恢復數據。
這種情況，kafka與Apache BookKeeper 非常相似。
1.3 快速開始
本教程，假設你沒有任何kafka知識。并且沒有現成的kafka和zookeeper數據。
Step 1: 下載代碼
下載0.11.0.2版本代碼，并且解壓
1 > tar -xzf kafka_2.11-0.11.0.2.tgz
2 > cd kafka_2.11-0.11.0.2
Step 2: 啟動服務
kafka依賴zookeeper，因此首先要啟動zookeeper；如果沒有安裝獨立的zookeeper，可以使用kafka內嵌的zookepper。雖然這種方式快速但不是很好。
啟動zookeeper
bin/zookeeper-server-start.sh config/zookeeper.properties
啟動 kafka
bin/kafka-server-start.sh config/server.properties
Step 3: 創建一個主題
手動創建一個名為“test”的主題
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
查看剛創建的主題
bin/kafka-topics.sh --list --zookeeper localhost:2181
可以通過配置“自動創建主題”，這樣如果沒有提前創建主題，那么在發布消息時，如果此消息對應的主題不存在，會自動創建。
Step 4: 發送消息
通過命令行客戶端，可以通過文件或標準輸入（命令行）向kafka集群發送消息。默認每行都是一條消息。
啟動生產者（啟動成功進入命令行阻塞狀態，可以輸入數據，回車發送）
bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
Step 5: 啟動消費者
啟動消費者命令行(啟動后命令行處于阻塞狀態，生產者發布的消息會在此顯示)
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning
Step 6: 設置服務器集群
到目前為止，我們一直在使用一個broker，但這并不好玩。 對于kafka來說，一個broker是只是有一臺服務的集群，所以集群除了多啟動幾個broker實例之外，沒有太大的改變。。 現在來感受下，讓我們把我們的集群擴展到三個節點（仍然都在我們的本地機器上）。
cp config/server.properties config/server-1.properties
cp config/server.properties config/server-2.properties
現在編輯這些新文件并設置以下屬性：
config/server-1.properties:
broker.id=1
listeners=PLAINTEXT://:9093
log.dir=/tmp/kafka-logs-1
config/server-2.properties:
broker.id=2
listeners=PLAINTEXT://:9094
log.dir=/tmp/kafka-logs-2
broker.id屬性是群集中每個節點的唯一且永久的名稱。 我們必須重寫端口和日志目錄，因為我們在同一臺機器上運行這些端口和日志目錄，我們希望讓代理不要嘗試在同一個端口上注冊或覆蓋彼此的數據。
我們已經有Zookeeper和我們的一個單節點了，所以我們只需要啟動兩個新的節點：
bin/kafka-server-start.sh config/server-1.properties &
...
bin/kafka-server-start.sh config/server-2.properties &
...
現在創建一個復制因子為3的新主題：
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 1 --topic my-replicated-topic
現在我們已經創建一個集群，但是我們怎么知道每個broker都做了什么？執行如下命令：”describe toics”：
>bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic
Topic:my-replicated-topic PartitionCount:1 ReplicationFactor:3 Configs:
Topic: my-replicated-topic Partition: 0 Leader: 1 Replicas: 1,2,0 Isr: 1,2,0
這里是對輸出的解釋。 第一行給出了所有分區的摘要，每個附加行給出了關于一個分區的信息。 由于我們只有一個分區，所以只有一行。
- “leader” 是負責該節點指定分區的所有讀寫操作。如果一個節點被分配（隨機的）了一個分區，則這個節點會是這個分區的leader。上圖可以看出分區leader的broker.id是1，可以唯一一個，因為分區數是1。
- “replicas” 是分區副本保存節點的列表，無論這些備份節點是否leader，也不管這些節點是否活著，上面可以看出在節點1,2,0上各保存了一個副本。
- “isr” 是同步的副本。這是副本列表的子集，即當前還活著的并且可以被leader聯系到的。
請注意，在示例中，節點1是該主題的唯一分區的領導者。
我們可以運行相同的命令行，用來查看我們最初創建的topic的信息
>bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test
Topic:test PartitionCount:1 ReplicationFactor:1 Configs:
Topic: test Partition: 0 Leader: 0 Replicas: 0 Isr: 0
毫無疑問，最初的topic沒有副本備份，并且處于server 0上，就是當我們創建這個server時，我們的集群中僅有的server。
下面向新topic發送一些消息：
>bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-replicated-topic
...
my test message 1
my test message 2
^C
然后消費這些消息：
>bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic my-replicated-topic
...
my test message 1
my test message 2
^C
現在可以測試kafka 的容錯性能，broker 1一直充當leader，我們可以殺掉他：
>ps aux | grep server-1.properties
7564 ttys002 0:15.91 /System/Library/Frameworks/JavaVM.framework/Versions/1.8/Home/bin/java...
kill -9 7564
leader已經切換到兩個從節點中的一個，并且broker1已經不在ISR中：
>bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic
Topic:my-replicated-topic PartitionCount:1 ReplicationFactor:3 Configs:
Topic: my-replicated-topic Partition: 0 Leader: 2 Replicas: 1,2,0 Isr: 2,0
即使當初寫入的leader已經被killed，但是消息仍然可以使用
>bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic my-replicated-topic
...
my test message 1
my test message 2
^C
Step7：使用 Kafka Connect導出/導入數據
通過命令行讀寫數據是一個方便簡單的開始。但是你可能希望通過其它數據源或者從kafka導出數據到其它系統。對大多數系統，你不需要寫定制化的代碼，只需要使用kafka connect 就可以導入或導出數據。kafka connect是一個可以運行多個connectors的擴展工具集。這些connectors實現了與外部系統交互的邏輯。在這個示例中，我們將體驗怎么運行kafka connect ,并通過簡單的connectors從文件把數據導入到主題，并從主題中把數據導出到文件。
首先，我們創建一些種子數據，如下：
> echo -e "foo\nbar" > test.txt
接下來，我們在獨立模式下啟動運行兩個connectors，也就是在單一的，本地，專用的線程中。我們提供了三個配置文件作為參數。第一個是 Kafka Connect進程的，包含一些常見的配置，比如要鏈接的brokers和要序列格式化的數據。其余的每個配置都指定一個連接器去創建。這些文件包括一個唯一的連接器名稱，連接器實例化類，和一些連接器需要的其他配置。
> bin/connect-standalone.sh config/connect-standalone.properties config/connect-file-source.properties config/connect-file-sink.properties
kafka包內包含了這些配置文件，用默認本地的kafka集群配置，并且創建兩個connectors：第一個是一個source connector用來從輸入文件逐行讀取并且發送到topic，第二個是sink connector從topic讀取消息并且逐行寫到文件中。
當啟動過程中，在會看到連接器的實例化日志。啟動成功后，source connector開始從test.txt讀取數據并且發送到connect-test這個topic中。同時sink connector開始從connect-test topic中讀取消息并且寫到test.sink.txt文件中。
我們可以看下test.sink.txt這個文件，看有沒有數據寫入：
> cat test.sink.txt foo bar
foo
bar
該數據被存儲在kafka的connect-test topic中，所以我們可以運行一個消費者終端去看看在這個topic中的數據：
> bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic connect-test --from-beginning
{"schema":{"type":"string","optional":false},"payload":"foo"} {"schema":{"type":"string","optional":false},"payload":"bar"} ...
connectors 繼續處理數據，我們嘗試向test.txt文件中繼續添加數據：
> echo "Another line" >> test.txt
你應該看到有一行在消費者控制臺輸入，并且寫入了sink文件。
Step 8：使用Kafka流來處理數據
見第9章
