今天想在windows上使用kafka
在windows上推薦使用Windows Terminal (Preview)當作終端機，可以多開很多分頁很方便

步驟 1: 安裝kafka

用scoop安裝kafka
(scoop超好用 windows開發者必備的開發工具安裝器)

scoop install kafka
cd ~/scoop/apps/kafka/current/bin/windows/

步驟 2: 啟動服務器

Kafka依賴ZooKeeper服務器，所以必須先開一個單節點的ZooKeeper服務器:

./zookeeper-server-start.bat ../../config/zookeeper.properties

現在就可以打開 Kafka 伺服器了:

./kafka-server-start.bat ../../config/server.properties

步驟 3: 創建主題(Topic)

先建立一個名為 test 的主題

./kafka-topics.bat --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic test 

其中replication-factor跟partitions是kafka裡很重要的東西，待會再來學。

現在透過 --list 參數就可以看到在localhost:9092上剛剛建立的主題了

./kafka-topics.bat --list --bootstrap-server localhost:9092
test

除了手動新增主題的方式，也可透過事先配置broker的方法來自動創建主題，這個方式之後再來學。

步驟 4: 發送訊息

kafka producer可以從標準輸入或是檔案發送訊息。預設上，每一行都當成個別獨立的訊息。

./kafka-console-producer.bat --broker-list localhost:9092 --topic test

This is a message
This is another message

步驟 5: 啟動消費者

開起另一個終端機分頁，
Kafka consumer可以把訊息印到標準輸出。

./kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic test --from-beginning

This is a message
This is another message

步驟 6: 設定多broker的叢集

剛剛都是單節點的broker，看不到kafka真正的威力，所以現在就來做一個包含三節點的叢集吧!

首先把server的配置檔複製兩份，檔名就按照想建立的數量按照順序標上數字:

 copy config/server.properties config/server-1.properties
 copy config/server.properties config/server-2.properties

並且編輯修改剛剛複製那兩份配置檔:

config/server-1.properties:
broker.id=1
listeners=PLAINTEXT://:9093
log.dirs=/tmp/kafka-logs-1

config/server-2.properties:
broker.id=2
listeners=PLAINTEXT://:9094
log.dirs=/tmp/kafka-logs-2

The broker.id property is the unique and permanent name of each node in the cluster. We have to override the port and log directory only because we are running these all on the same machine and we want to keep the brokers from all trying to register on the same port or overwrite each other's data.

We already have Zookeeper and our single node started, so we just need to start the two new nodes:

 bin/kafka-server-start.sh config/server-1.properties &

 bin/kafka-server-start.sh config/server-2.properties &

Now create a new topic with a replication factor of three:
1

./kafka-topics.bat --create --bootstrap-server localhost:9092 --replication-factor 3 --partitions 1 --topic my-replicated-topic

Okay but now that we have a cluster how can we know which broker is doing what? To see that run the "describe topics" command:

./kafka-topics.bat --describe --bootstrap-server localhost:9092 --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

Here is an explanation of output. The first line gives a summary of all the partitions, each additional line gives information about one partition. Since we have only one partition for this topic there is only one line.

"leader" is the node responsible for all reads and writes for the given partition. Each node will be the leader for a randomly selected portion of the partitions.
"replicas" is the list of nodes that replicate the log for this partition regardless of whether they are the leader or even if they are currently alive.
"isr" is the set of "in-sync" replicas. This is the subset of the replicas list that is currently alive and caught-up to the leader. 

Note that in my example node 1 is the leader for the only partition of the topic.

We can run the same command on the original topic we created to see where it is:

./kafka-topics.bat --describe --bootstrap-server localhost:9092 --topic test

Topic:test PartitionCount:1 ReplicationFactor:1 Configs:
Topic: test Partition: 0 Leader: 0 Replicas: 0 Isr: 0

So there is no surprise there—the original topic has no replicas and is on server 0, the only server in our cluster when we created it.

Let's publish a few messages to our new topic:

./kafka-console-producer.bat --broker-list localhost:9092 --topic my-replicated-topic

my test message 1
my test message 2
^C

Now let's consume these messages:

./kafka-console-consumer.bat --bootstrap-server localhost:9092 --from-beginning --topic my-replicated-topic

my test message 1
my test message 2
^C

Now let's test out fault-tolerance. Broker 1 was acting as the leader so let's kill it:
1
2
3

 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
On Windows use:

wmic process where "caption = 'java.exe' and commandline like '%server-1.properties%'" get processid

ProcessId
6016

taskkill /pid 6016 /f

Leadership has switched to one of the followers and node 1 is no longer in the in-sync replica set:

./kafka-topics.bat --describe --bootstrap-server localhost:9092 --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

But the messages are still available for consumption even though the leader that took the writes originally is down:

./kafka-console-consumer.bat --bootstrap-server localhost:9092 --from-beginning --topic my-replicated-topic

...
my test message 1
my test message 2
^C
Step 7: Use Kafka Connect to import/export data

Writing data from the console and writing it back to the console is a convenient place to start, but you'll probably want to use data from other sources or export data from Kafka to other systems. For many systems, instead of writing custom integration code you can use Kafka Connect to import or export data.

Kafka Connect is a tool included with Kafka that imports and exports data to Kafka. It is an extensible tool that runs connectors, which implement the custom logic for interacting with an external system. In this quickstart we'll see how to run Kafka Connect with simple connectors that import data from a file to a Kafka topic and export data from a Kafka topic to a file.

First, we'll start by creating some seed data to test with:
1

echo -e "foo\nbar" > test.txt
Or on Windows:

echo foo> test.txt
echo bar>> test.txt

Next, we'll start two connectors running in standalone mode, which means they run in a single, local, dedicated process. We provide three configuration files as parameters. The first is always the configuration for the Kafka Connect process, containing common configuration such as the Kafka brokers to connect to and the serialization format for data. The remaining configuration files each specify a connector to create. These files include a unique connector name, the connector class to instantiate, and any other configuration required by the connector.
1

bin/connect-standalone.sh config/connect-standalone.properties config/connect-file-source.properties config/connect-file-sink.properties

These sample configuration files, included with Kafka, use the default local cluster configuration you started earlier and create two connectors: the first is a source connector that reads lines from an input file and produces each to a Kafka topic and the second is a sink connector that reads messages from a Kafka topic and produces each as a line in an output file.

During startup you'll see a number of log messages, including some indicating that the connectors are being instantiated. Once the Kafka Connect process has started, the source connector should start reading lines from test.txt and producing them to the topic connect-test, and the sink connector should start reading messages from the topic connect-test and write them to the file test.sink.txt. We can verify the data has been delivered through the entire pipeline by examining the contents of the output file:
1
2
3

more test.sink.txt
foo
bar

Note that the data is being stored in the Kafka topic connect-test, so we can also run a console consumer to see the data in the topic (or use custom consumer code to process it):
1
2
3
4

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic connect-test --from-beginning
{"schema":{"type":"string","optional":false},"payload":"foo"}
{"schema":{"type":"string","optional":false},"payload":"bar"}
...

The connectors continue to process data, so we can add data to the file and see it move through the pipeline:
1

echo Another line>> test.txt

You should see the line appear in the console consumer output and in the sink file.
Step 8: Use Kafka Streams to process data

Kafka Streams is a client library for building mission-critical real-time applications and microservices, where the input and/or output data is stored in Kafka clusters. Kafka Streams combines the simplicity of writing and deploying standard Java and Scala applications on the client side with the benefits of Kafka's server-side cluster technology to make these applications highly scalable, elastic, fault-tolerant, distributed, and much more. This quickstart example will demonstrate how to run a streaming application coded in this library.