Step 1: Download the code

Download the lastest release and un-tar it

清華鏡像站
http://mirrors.tuna.tsinghua.edu.cn/apache/kafka/2.1.0/kafka_2.12-2.1.0.tgz

# tar -xzf kafka_2.12-2.1.0.tgz
# cd kafka_2.12-2.1.0

Step 2: Start the server

Start the Zookeeper server:

# bin/zookeeper-server-start.sh config/zookeeper.properties &

Now start the Kafka server:

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

Step 3: Create a topic

Let's create a topic named "test" with a single partition and only one replica:

# bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test

We can now see that topic if we run the list topic command:

# bin/kafka-topics.sh --list --zookeeper localhost:2181

...
test

Step 4: Send some messages

Kafka has a command line producer , run the producer and then type a few messages into the console to send to the server.

# bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test

> This is a message
> This is another message

Step 5: Start a consumer

Kafka also has a command line consumer that will dump out messages to standard output.

# bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning

This is a message
This is another message

Step 6: Setting up a multi-broker cluster

First we make a config file for each of the brokers

# cp config/server.properties config/server-1.properties
# cp config/server.properties config/server-2.properties

Now edit these new files and set the following properties:

• config/server-1.properties:

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

• config/server-2.properties:

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

The broker.id property is the unique and permanent name of each node in the cluster.

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:

# bin/kafka-topics.sh --create --zookeeper localhost:2181 --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:

# 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" 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:

# 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

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:

# bin/kafka-console-producer.sh --broker-list localhost:9093 --topic my-replicated-topic

...
> my test message 1
> my test message 2
> ^C

Now let's consume these messages:

# bin/kafka-console-consumer.sh --bootstrap-server localhost:9094 --from-beginning --topic my-replicated-topic

...
my test message 1
my test message 2
^C

Step 7: Use Kafka Connect to import/export data

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

# echo -e "foo\nbar" > 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.^[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:

# 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):

# 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:

# 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.

1. 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. ↩