Kafka CLI是Kafka Command Line Interface。其实就是Kafka的命令行工具，可以让我们在终端里方面的进行Kafka的操作，比如创建Topic、Partition、Replication、Produce data、Consume data等等。后续的几个章节主要来介绍如何使用Kafka CLI。

Topic CLI

首先我们可以通过下面的命令创建Topic：

kafka-topics.sh —zookeeper 127.0.0.1:2181 —topic xxxx_topic —create —partitions 3 —replication-factor 1

这里需要注意一点，replication-factor不能大于Broker的数量，这个很好理解，前文中有过阐述。成功后可以看Created topic "first_topic".这样的提示。

这一节介绍如何在Linux服务器上搭建单机Kafka。

租赁服务器

为了更加真实，本小册的实践内容都搭建在云服务器上。可以在阿里云或者腾讯云租赁服务器，如果想租赁国外的服务器，可以在Vultr租赁。我选择在阿里云租赁了一台Linux服务器。配置不需要太高，入门级的就可以，系统可以选择CentOS或者Ubuntu。

注意：在配置ECS时，宽带计费方式要选择按量计费，这样可以自动分配公网IP，并且价格实惠。

安装JDK

使用终端登录服务器，首先安装JDK：

apt update
apt install openjdk-8-jdk

了解完Producer，接下来介绍Kafka中的Consumer的概念，以及在消费Message时有什么样的策略。

Consumer

Consumer负责从Topic中读取数据，我们已经知道了Topic是通过名称确定唯一的，所以指定Consumer从哪个Topic中读数据，同样使用Topic名称指定。Kafka中的Consumer有以下几点需要我们注意：

• 我们只需要指定需要从哪个Topic中读取数据即可。不需要关心Consumer是从哪个Broker中的哪个Partition中读数据，这些工作由Kafka帮我们处理好了。
• 当持有Topic的Broker挂掉，重新恢复后，Consumer可以自动重新从该Broker中读数据。
• 在一个Partition中，Consumer是按Offset的顺序读取数据的。
• 一个Consumer可以同时读取多个Broker中的不同Partition，但是Partition之间无法保证读取数据的顺序，因为是并行执行的。

通过上一章节，我们知道了Kafka的Message是如何持久化的，知道了保证高可用性、稳定性的策略。这一节来看看Kafka中如何生产Message以及相关的策略。

Producer

简而言之，Producer就负责往Topic里发送数据，或者说写入数据。换言之，就是往组成这个Topic的一至多个Partition里写入数据。这里有三点需要注意：

• 我们只需要通过Producer产生数据，往Topic里塞既可。Producer会自动去选择正确的、合适的Broker和Partition持久化数据。
• Producer默认采用轮询的机制选择Broker往Partition里持久化数据的。
• 如果其中有一个Broker挂了，当它再恢复时，Producer会自动接纳它。

Message keys

Producer默认采用轮询的机制选择Broker往Partition里持久化数据。但当我们需要根据数据中的某个字段按Partition进行分组或者排序时，就需要在每条Message里添加Key，这个Key可以是数字，也可以是字符串等等。然后相同Key的Message永远会持久化到同一个Partition。

了解了Kafka的窗户和内核之后，我们深入Broker中，看看Topic和Broker之间的关系，它们之间到底是用什么联系起来的。Broker对Message的持久化是如何处理的。

Partition

Kafka的Partition是分区的概念，在Kafka中，一个Topic可以有多个Partition，换句话说，就是一个Topic中的内容是被多个Partition分割的。对于Partition，我们需要注意以下几个要点：

• 一个Topic下的所有Partition是有顺序的，或者说在创建Topic和Partition时，Partition的顺序就已经是确定了的。
• 每条进入Partition中的Message都会获得一个自增的ID，这个ID称为Offset（消息的偏移量）。
• 通常在说Message的Offset时，只是针对该条Message所在的Partition而言。举个例子，Partition-0中Offset为3的Message和Partition-1中Offset为3的Message没有任何关系。
• 当说到Message的顺序时，通常有两种解读：
  • 业务语义上的Message顺序，如下图所示，1至4条Message之间是有语义顺序的，可以理解为是消息生产者生产消息时的顺序。
  • Partition中的Message顺序，如下图所示，Partition-1中的Message如果按照Offset的顺序，那么第一条和第二条Message其实是语义上的第一条和第三条Message。

• 当Message进入Partition后，它的Offset和内容就无法再修改了。
• Message默认是随机存储在一个Topic下的不同的Partition中的，如上图。除非显示的指定Partition。
• 存储在Partition中的Message是有时效性的，默认是保存一周，可以通过配置更改（后续章节会介绍）。