kafka集群（docker kafka集群）

本篇文章给大家谈谈kafka集群，以及docker kafka集群对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、kafka集群扩容后的数据迁移
• 2、kafka集群配置和使用
• 3、Kafka集群部署（Docker容器的方式）
• 4、kafka架构详解
• 5、Kafka（四）集群之kafka

kafka集群扩容后的数据迁移

最近我们生产环境的kafka集群有增加节点的需求，然而kafka在新增节点后并不会像elasticsearch那样感知到新节点加入后自动将数据reblance到新集群中春败悔，因此这个过程需要我们手动分配。一番折腾之后，实现了增加kafka集群节点并将原有数据均匀分配到扩容后的集群。下面结合一个例子谈一下整个过程。

假定当前的cluster中只有（101，102，103）三个kafka节点，有一个名为think_tank的topic，该topic有2个replica，均匀分布在三个节点上.

我们要做的是在cluster中新增两个节点（记为104，105）后，将的数据均匀分到新集群中的5个节点上。

其实官方文档的这一小节关于集群扩容讲解很详细： Expanding your cluster ,整个过程需要分为三个步骤：获取kafka给出的建议分配方案、按照给出的分配方案执行分配、查看分配的进度以及状态。这三个步骤对应了kafka脚本提供的三个partition reassigment工具。

结合例子具体说明：

脚本的参数是以json文件的形式传入的，首先要新建一个json文件并设置需要分配哪些topic，think_tank-to-move.json:

使用/bin目录中提供的 kafka-reassign-partitions.sh 的脚本请求获取生成分配方案：

--broker-lsit 的参数 "101,102,103,104,105"是指集群中每个broker的id，由于我们是需要将所有topic均匀分配到扩完结点的5台机器上，所以要指定。同理，当业务改变为将原来的所有数据从旧节点（01,102,103）迁移到新节点（104，105）实现数据平滑迁移，这时的参数应"104，105".

脚本执行后返回的结果如下：

可以看出当前正在运行的方案中，think_tank的replica都是分布在101，102，103这3个节点，新给出的建议方案中replica均匀分布在扩容后的5个节点中。

将上一个步骤中生成的建议方案复制到新建的think_tank_reassignment.json中：

使用脚本执行：

脚本扒正执行，返回内容：

如上，成功开始执行分配数据，同时提示你如果有需要将之前的分配方案备份便于回滚到原方案。

查看脚本的方法如下，注意这次的json文件要和执行步骤中的json是同一个文件：

返回结果：

is still in progress表示还在处理中，全部迁移成功后每个partition都会显示 completed successfully.注意如果topic数据量大，这个过程可能会时间长一些， 不要轻易重启节点！ 可能会导致数据不一致！！！

这个partion reassignment工具同样可以按需手动地将某个特定的topic指定到特定的broker上，所要做的就是按照步骤一给定的格式关联partition到borker即可，如，将think_tank的partition0指定到101、102两节点上：

另外，如果有增加replica的个数的需求，同样可以使用这个脚本，可以翻一下官网文档。

一点儿感触，在确定问题所在后，官方的文档枯族应该作为我们优先考虑的一个重要资料源，网上的资料由于时间较早、版本不同的原因，解决方式可能需要细微的改动才能达到目的，这些坑在官方的一手资料上其实是可以规避的。

欢迎拍砖，欢迎交流~

kafka集群配置和使用

进入安装目录，修改server.properties文件

修改如下属性，除id外，其他每台主机一致：

语义配置：（可选）

先启动zookeeper集群，已经在三台主机上配置好了zookeeper集群，启动：

在各台主机上进入zookeeper目录，分别启动zk：

在各台主机上进入kafka目录，分别启动kafka：

启动结好悔果为：

kafka占据了前台，辩枯要使携袜洞用主机，需要打开新终端

在新打开的终端上，进入zk目录，

进入kafka目录，创建主体

Kafka集群部署（Docker容器的方式）

文章主要介绍以docker容器的方式部署kafka集群。

上述配置文件中的server.x，数字x对应到data/myid文件中的值。三台机器x的值分别就是1,2,3。参数详细说明请参考 官网文档唤含 。

1.--net=host: 容器与主机共享同一Network Namespace，即容器与网络看到的是相同的网络视图（host模式存在一定的风险，对安全要求很高的生产环境最好不要用host模兆链森式，应考虑除此之外的其他几种模式）

2.-v: 指定主机到容器的目录映射关系

这样就以容器的方式启动了zookeeper的服务，可以通过 "docker exec -it zookeeper bash" 命令进入容器中进行一些操作，例如查看服务启动是否正常。也可以通过查看2181端口是否被监听判断zookeeper的服务是否运行

详细的参数配置说明请参考 官方文档 ，参数不仅可以通过上述文件的方式来配置，也可以通过容器环境变量的方式来配置，这里结合两种方式使用。

1.KAFKA_ADVERTISED_HOST_NAME、KAFKA_BROKER_ID的值要结合每台机器自身设置

2./etc/hosts文件中最好配置ip与hostname的映射关系，否则会报出如下错误" Error: Exception thrown by the agent : java.net.MalformedURLException: Local host name unknown: java.net.UnknownHostException: node0: node0: System error "

3.通过-e 指定的环境变量与在server.properties中配置的选项其效果是一样的

4.配置文件中的选项若要通过环境变量来指定，方式为：如broker.id对应KAFKA_BROKER_ID，类似的log.dirs对应KAFKA_LOG_DIRS

5.KAFKA_HEAP_OPTS="-Xmx6G -Xms6G"指java堆内存大小的设置，6G大小是kafka官网给出的数值，此数值要结合机器的内存大小给出。超过6G的内存，可以设置为6G；若机器的内存低于6G而设置6G，则会报错。

5.启动成功后，可族亩以通过"docker logs kafka"命令查看日志

1.ZK_HOSTS：ZooKeeper访问地址（需指定机器的ip，localhost:2181或127.0.0.1:2181均会报 "java.net.ConnectException: Connection refused" 异常）

[img]

kafka架构详解

kafka是一个高性能、低延迟的分布式发布-订阅消息悔岁系统，适用于在线、离线消息消费，为了防止数据丢失，kafka将消息持久化到磁盘上并在集群内复制.

在深入了解kafka之前，先介绍kafka体系架构中的一些组件，包括Topic、裂前脊Producer、Consumer、Consumer Group、Broker、Partition、Leader、Follower。

Topic

消息被发送到kafak中都有一个类别，这个类别叫做Topic，kafka中的消息都是通过主题进行组织的，一个Topic可以有1个或多个Partition。

Producer

生产者，即是将消息发送到kafka的过程，发送消息是需要指定Topic，并且可以指定Partition。Broker接收到消息后，将消息存放在partition中。

Consumer

消费者，从broker topic中读取消息，可以订阅一个或多个topic。

Consumer Group

消费者组由一个或多肆渗个消费者组成，消费者组中的消费者共同消费一个主题的分区，主题中每个分区只能被同一个消费者组中的一个消费者消费。

Broker

kafka集群包括一个或多个节点，每个节点就叫做Broker。

Partition

Topic中的数据可以分割为一个或多个Partition，Partition在底层逻辑是log文件，每个Partition由多个Segment组成，任何发送到kafka的消息最终都是会被追加到log文件的尾部。

Leader

Topic的Partition允许有若干个副本，每个分区都一个leader和多个follower，leader负责所有的读写操作。

Follower

Follower追随Leader，所有的读写请求都是通过Leader路由，请求会广播给所有的Follower，Follower和Leader保持数据同步。如果Leader失效，通过Follower选举一个新的Leader.

下面通过一张简单的UML图简要说明组件之间的交互和关联关系

主要关系说明如下

- kafka集群可以有1个或多个Broker

- Broker 可以包含多个副本（每个分区可以包含多个副本，通常每个分区副本数不会多于Broker数量，一个broker中包含很多个分区）

- Topic可以有1个或多个分区

- broker中的每个partition可以有0个或1个副本

- 一个partition有一个leader副本和0个或多个follower副本

- partition的每个副本都必须位于单独的broker上

- 每个partition副本位于一个broker上，并且一个partition不能划分多个broker。

Kafka架构

下面重点介绍Producer、Topic、Consumer的关系，一个简单生产消费的过程例子如下图所示

在这个例子中，一个生产者将消息发送给单个topic

上面这个图中，1个生产者发布消息到1个topic，一个消费者消费1个Topic，如上图中的Producer 1和Consumer 1；一个Topic可以是由多个生产者发布消息，如Topic4；1个消费者可以消费多个Topic，如图中的Consumer 2。

如上图的例子，一个生产者可以给多个Topic发布消息。一个消费者同一时间只能给一个topic发布消息，但是可以使用异步发布消息，生产者可以一次将多个消息发送给多个Topic.

生产者负责将每条消息发送到分区，默认分区由消息key通过hash算法确定，如果没有指定消息key，则通过循环轮询来确定分区。但是在实际业务场景中，默认的分区行为并不能满足业务需要，比如需要确保消息的顺序或需要将消息平均分配给消费者等等。因此，生产者在发布消息的时候可以使用自定义分区方式，为消息指定分区key、重写分区算法或手动设置分区等方式将消息发布到特定分区。

kafka内部运作的基本逻辑大概为：每个主题都有1个或多个分区，这些分区分不在1个或多个Broker上，为了提高消息的可靠性不会丢失，可以配置多个副本因子，这样每个分区可以被复制到一个或多个Broker上，每个分区对应一个log文件，只能被一个消费组中的一个消费者消费，用于提高Topic的并发性。因此一般将消费组消费者数量设置为小于或者等于topic的分区数量，如果要增加消费者也相应的增加对应的分区数量。

同一个分区内的消息是由顺序的，每个分区仅能被同一个消费组中的一个消费者顺序消费。但是，当多个消费组订阅了同一个topic，则每个组中的消费者都会收到消息。

下面例子说明多分区情况下，消费者组和消费者消费的几种情况。

分区数和消费者数相同，如下图所示

这种情况，同一个消费组的每个消费者只消费一个分区。

另外一种情况，消费组中的消费者数量多于分区数，如下图所示

消费者数量多于分区数，则某些消费者就处于空闲状态，当有消费者down掉或添加新的分区情况时，空闲消费者将发挥作用。

另外一种情况，消费者数比分区数少，如下图所示

这种情况，导致某些分区需要负责更多的分区，处理更多的消息。

最后，多个消费组消费了同一个topic

topic消息被广播到每个消费组，每个消费组都可以接受同一个消息。这是kafka实现一个Topic广播的方式，一个Topic可以被多个Conumse Group的消费者同时消费；同一个消息只能被一个消费者组中的一个消费者消费。

Kafka（四）集群之kafka

在章节二（ ）中，我们部署了单机的kafka，现在我们部署一套集群模式的kafka。

这里我准备了三台虚拟机：

192.168.184.134

192.168.184.135

192.168.184.136

每台机器部署一个zk和kafka。

上一章节中zk集群已经神中部署完毕。

在章节二中，134这台机器已经有kafka存在了，我们在另外两台机器上安装kafka：

在上面的文件中有几个关键点，我们一一进行配置，我会对配置中的说明翻译：

以下这两个listeners，advertised_listeners 是对外暴露的服务端口，真正建立连接用的是 listeners。

在内网中我们使用listenners就可以了，在docker等容器或云中使用advertised。游判山

下面这个是日志路径的配置

下面这个是个重点的东西，topic在磁盘上会分为多个partitions存储，相比单一文件存储，增加了并行性，在后续文章中会详细去讲解：

日志的保存时间：

以下是zookeeper的配置：

这里我们直接设置后台启动，三个节点都是如此：

这里面有个小坑，还记得之前我们搭建的单机环境吗？那时候默认的日志文件夹在/tmp/kafka-logs下面，生成了很多内容，导致我们134这个节点无法启动成功，报错如下：

解决这个问题只需要把/tmp/kafka-logs文件删除就好了。

看到日志出现这一句表明启动成功了：

下面我们验证下是否搭建成功了，首先使用kafkatool工机具连接看下：

我们在134节点创建一个topic：

查看topic列表：

在kafkatool中查看：

创建生产者：

创建消费者：

生成者发送冲游消息：

消费者接收消息：

到此为止，kafka的集群搭建已经完成了。在后面的文章我们会去学习如何在springboot中集成kafka。

关于kafka集群和docker kafka集群的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。