ZOOKEEPER+KAFKA消息队列群集

前言

消息队列(Message Queue)，是分布式系统中重要的组件，其通用的使用场景可以简单地描述为:当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。

消息队列

什么是消息队列

消息(Message)是指在应用间传送的数据。消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。
消息队列(Message Queue)是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保消息的可靠传递。消息发布者只管把消息发布到MQ 中而不用管谁来取,消息使用者只管从MQ中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。

为什么需要消息队列

(1)解耦
允许你独立的扩展或修改两边的处理过程，只要确保它们进守同样的接口约束。
(2)冗余
消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的“插入-获取-删除"范式中，在把一个消息从队列中副除之前，雷要你的处理系统明确的指出该消息已经被处理完毕,从面确保你的数据被安全的保存直到你使用完毕。
(3)扩展性
因为消息队列解糯了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外
增加处理过程即可。
(4)灵活性 &峰值处理能力
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费,使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。(5)可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程问的合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统复后被处理。(6)顺序保证:
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。(Kafka保证一个Partition 内的消息的有序性)
(7)缓冲有助于控制和优化数据流经过系统的速度,解决生产消息和消费消息的处理速度不一致的情况。
(8)异步通信
很多时候，用户不想也不需要立即处理消息。消总队列提供了异步处理机，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

kafka基础入门

kafka基本概念

Kafka 是一种高吞吐量的分布式发布/订阅消息系统，这是官方对 kafka 的定义，这样说起来，可能不太好理解，这里简单举个例子:现在是个大数据时代，各种商业、社交、搜索、浏览都会产生大量的数据。那么如何快速收集这些数据，如何实时的分析这些数据，是一个必须要解决的问题，同时，这也形成了一个业务需求模型，即生产者生产(produce)各种数据，消费者(consume)消费(分析、处理)这些数据。那么面对这些需求，如何高
效、稳定的完成数据的生产和消费呢?这就需要在生产者与消费者之间，建立一个通信的桥梁，这个桥梁就是消息系统。从微观层面来说，这种业务需求也可理解为不同的系统之间如何传递消息。
kafka 是 Apache 组织下的一个开源系统,它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于hadoop平台的数据分析、低时延的实时系统、storm/spark 流式处理引擎等。kafka 现在它已被多家大型公司作为多种类型的数据管道和消息系统使用。

kafka角色术语

kafka 的一些核心概念和角色
(1)Broker:Kafka集群包含一个或多个服务器，每个服务器被称为 broker。
(2)Topic:每条发布到 Kafka 集群的消息都有一个分类，这个类别被称为 Topic(主题)。
(3)Producer:指消息的生产者，负责发布消息到kafka broker。
(4)Consumer:指消息的消费者，从 kafka broker 拉取数据，并消费这些已发布的消息。(5)Partition:Partition 是物理上的概念，每个Topic 包含一个或多个 Partition,每个 partition 都是一个有序的队列。partition 中的每条消息都会被分配一个有序
的id(offset)。
(6)Consumer Group:消费者组，可以给每个Consumer 指定消费组，若不指定消费者组则属于默认的 group。
(7)Message:消息，通信的基本单位，每个producer 可以向一个 topic 发布一些消息。

kafka拓扑架构

一个典型的 Kafka 集群包含若干 Producer，若干 broker、若干 Consumer Group,以及一个 Zookeeper 集群。Kafka通过 Zookeeper 管理集群配置，选举 leader，以及在Consumer Group 发生变化时进行 rebalance。Producer 使用 push 模式将消息发布到broker，consumer 使用 pu11 模式从 broker 订阅并消费消息。典型架构如下图所示:

从图中可以看出，典型的消息系统有生产者(Producer)，存储系统(broker)和消费者(Consumer)组成，Kafka作为分布式的消息系统支持多个生产者和多个消费者，生产者可以将消息分布到集群中不同节点的不同 Partition 上，消费者也可以消费集群中多个节点上的多个 Partition。在写消息时允许多个生产者写到同一个 Partition 中，但是读消息时一个 Partition 只允许被一个消费组中的一个消费者所消费，而一个消费者可以消费多个 Partition。也就是说同一个消费组下消费者对 Partition 是互斥的，而不同消费组之间是共享的
kafka 支持消息持久化存储，持久化数据保存在 kafka的日志文件中，在生产者生产消息后，kafka不会直接把消息传递给消费者，而是先要在 broker 中进行存储，为了减少磁盘写入的次数，broker 会将消息暂时缓存起来，当消息的个数或尺寸、大小达到一定阀值时，再统一写到磁盘上,这样不但提高了 kafka 的执行效率,也减少了磁盘 I0 调用次数。kafka 中每条消息写到 partition 中，是顺序写入磁盘的，这个很重要，因为在机械盘中如果是随机写入的话，效率将是很低的，但是如果是顺序写入，那么效率却是非常高，这种顺序写入磁盘机制是 kafka 高吞吐率的一个很重要的保证。

topic和partition

Kafka 中的 topic(主题)是以 partition 的形式存放的，每一个 topic 都可以设置它的 partition数量,Partition的数量决定了组成topic的log的数量,推荐partition的数量一定要大于同时送行的 consumer 的数量。另外，建议 partition 的数量要小于等于集群 broker 的数量，这样消息数据就可以均匀的分布在各个broker中
那么，Topic 为什么要设置多个 Partition 呢，这是因为kafka 是基于文件存储的，
通过配置多个partition可以将消息内容分散存储到多个broker上,这样可以避免文件尺寸达到单机磁盘的上限。同时，将一个 topic切分成任意多个 partitions，可以保证消息存储、消息消费的效率，因为越多的partitions 可以容纳更多的 consumer，可有效提升Kafka 的吞吐率。因此，将Topic 切分成多个 partitions 的好处是可以将大量的消息分成多批数据同时写到不同节点上，将写请求分担负载到各个集群节点。
在存储结构上，每个partition在物理上对应一个文件夹，该文件夹下存储这个partition 的所有消息和索引文件。partiton 命名规则为 topic 名称+序号，第一个partiton 序号从8开始，序号最大值为partitions 数减1.
在每个 partition(文件夹)中有多个大小相等的segment(段)数据文件，每个segment 的大小是相同的,但是每条消息的大小可能不相同，因此 segment<br/>数据文件中消息数量不一定相等。segment 数据文件有两个部分组成，分别为index file 和 datafile，此两个文件是一一对应，成对出现，后”,index“和“,10g”分别表示为 segment索引文件和数据文件。

producer生产机制

Producer 是消息和数据的生产者，它发送消息到broker 时，会根据Paritition 机制选择将共存储到哪一个 Partition。如果 Partition 机制设置的合理，所有消息都可以均匀分布到不同的Partition 里，这样就实现了数据的负载均衡。如果一个 Topic 对应一个文件，那这个文件所在的机器I/0将会成为这个Topic的性能瓶颈，而有了 Partition后，不同的消息可以并行写入不同 broker 的不同 Partition 里，极大的提高了吞吐率。

consumer消费机制

Kafka 发布消息通常有两种模式:队列模式(queuing)和发布/订阅模式(publish-subscribe)。在队列模式下，只有一个消费组，而这个消费组有多个消费者，一条消息只能被这个消费组中的一个消费者所消费;而在发布/订阅模式下，可有多个消费组，每个消费组只有一个消费者，同一条消息可被多个消费组消费。Kafka 中的 Producer 和 consumer 采用的是 push、pull 的模式,即 producer 向 broker进行 push 消息，comsumer 从 bork 进行 pu11 消息，push 和 pu11 对于消息的生产和消费是异步进行的。pu11模式的一个好处是consumer 可自主控制消费消息的速率，同时
consumer 还可以自己控制消费消息的方式是批量的从 broker 拉取数据还是逐条消费数据。

zookeeper概念介绍

ZooKeeper 是一种分布式协调技术，所谓分布式协调技术主要是用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种共享资源，防止造成资源竞争(脑裂)的后果。脑裂是指在主备切换时,由于切换不彻底或其他原因,导致客户端和 Slave 误以为出现两个 activemaster,最终使得整个集群处于混乱状态
这里首先介绍下什么是分布式系统,所谓分布式系统就是在不同地域分布的多个服务器共同组成的一个应用系统来为用户提供服务，在分布式系统中最重要的是进程的调度，这里假设有一个分布在三个地域的服务器组成的一个应用系统,在第一台机器上挂载了一个资源然后这三个地域分布的应用进程都要竞争这个资源,但我们又不希望多个进程同时进行访问,这个时候就需要一个协调器(锁)，来让它们有序的来访问这个资源。这个协调器就是分布式系统中经常提到的那个“锁”，例如”进程 1“在使用该资源的时候，会先去获得这把锁，”进程 1“获得锁以后会对该资源保持独占，此时其它进程就无法访问该资源,“进程 1”;在用完该资源以后会将该锁释放掉，以便让其它进程来获得锁。由此可见，通过这个“锁”机制，就可以保证分布式系统中多个进程能够有序的访问该共享资源。这里把这个分布式环境下的这个“锁”叫作分布式锁。这个分布式锁就是分布式协调技术实现的核心内容。
目前，在分布式协调技术方面做得比较好的有Google 的 Chubby，还有 Apache 的ZooKeeper，它们都是分布式锁的实现者。ZooKeeper所提供锁服务在分布式领域久经考它的可靠性、可用性都是经过理论和实践验证的。验，
ZooKeeper 是一种为分布式应用所设计的高可用、高性能的开源协调服务，它提供了一项基本服务:分布式锁服务，同时，也提供了数据的维护和管理机制，如:统一命名服务状态同步服务、集群管理、分布式消息队列、分布式应用配置项的管理等等。

zookeeper应用实例

1)什么是单点故障问题呢?
所谓单点故障，就是在一个主从的分布式系统中，主节点负责任务调度分发，从节点负
责任务的处理，而当主节点发生故障时，整个应用系统也就瘫痪了，那么这种故障就称为单点故障。那我们的解决方法就是通过对集群master 角色的选取，来解决分布式系统单点故障的问题。
(2)传统的方式是怎么解决单点故障的?以及有哪些缺点呢?
传统的方式是采用一个各用节点，这个各用节点定期向主节点发送ping包，主节点收到 ping包以后向各用节点发送回复 Ack 信息,当各用节点收到回复的时候就会认为当前主节点运行正常，让它继续提供服务。而当主节点故障时，各用节点就无法收到回复信息了，此时，备用节点就认为主节点宕机，然后接替它成为新的主节点继续提供服务。
这种传统解决单点故障的方法，虽然在一定程度上解决了问题，但是有一个隐患，就是网络问题，可能会存在这样一种情况:主节点并没有出现故障，只是在回复ack 响应的时候网络发生了故障，这样备用节点就无法收到回复，那么它就会认为主节点出现了故障，接着，备用节点将接管主节点的服务，并成为新的主节点，此时，分布式系统中就出现了两个主节点(双Master 节点)的情况，双Master 节点的出现，会导致分布式系统的服务发生混乱。这样的话，整个分布式系统将变得不可用。为了防止出现这种情况，就需要引入ZooKeeper 来解决这种问题。

zookeeper的工作原理是什么

master启动

在分布式系统中引入 Zookeeper 以后，就可以配置多个主节点，这里以配置两个主节点为例,假定它们是 主节点A 和 主节点B,当两个主节点都启动后,它们都会向ZooKeeper中注册节点信息。我们假设 主节点A锁注册的节点信息是 master00001， 主节点B 注册的节点信息是 master00002，注册完以后会进行选举，选举有多种算法，这里以编号最小作为选举算法，那么编号最小的节点将在选举中获胜并获得锁成为主节点，也就是 主节点A 将会获得锁成为主节点，然后 主节点B将被阻塞成为一个各用节点。这样，通过这种方式 Zookeeper 就完成了对两个Master 进程的调度。完成了主、备节点的分配和协作。

master故障

如果 主节点A 发生了故障,这时候它在 ZooKeeper所注册的节点信息会被自动删除,
而 ZooKeeper 会自动感知节点的变化，发现 主节点A 故障后，会再次发出选举，这时候 主节点B 将在选举中获胜，替代主节点A 成为新的主节点，这样就完成了主、被节点的重新选举。

master恢复

如果主节点恢复了，它会再次向 ZooKeeper 注册自身的节点信息，只不过这时候它注册的节点信息将会变成 master00003，而不是原来的信息。ZooKeeper 会感知节点的变化再次发动选举,这时候主节点B在选举中会再次获胜继续担任主节点，主节点A会担任备用节点。
zookeeper 就是通过这样的协调、调度机制如此反复的对集群进行管理和状态同步的。

zookeeper集群架构

zookeeper一般是通过集群架构来提供服务的下面是zookeeper的基本架构图

zookeeper集群主要角色有server和client,其中server 又分为leader、follower和 observer 三个角色，每个角色的含义如下:
Leader:领导者角色，主要负责投票的发起和决议，以及更新系统状态。fo1lower:跟随着角色，用于接收客户端的请求并返回结果给客户端，在选举过程中参与投票。
observer:观察者角色，用户接收客户端的请求，并将写请求转发给1eader，同时同步leader 状态，但是不参与投票。0bserver 目的是扩展系统，提高缩性。client:客户端角色，用于向zookeeper 发起请求。

zookeeper的工作流程

Zookeeper 修改数据的流程:Zookeeper 集群中每个 Server 在内存中存储了一份数据，在 Zookeeper 启动时，将从实例中选举一个Server 作为leader，Leader 负责处理数据更新等操作，当且仅当大多数 server 在内存中成功修改数据，才认为数据修改成功。Zookeeper 写的流程为:客户端Client 首先和一个 Server 或者 Observe 通信，发起写请求，然后 Server 将写请求转发给 Leader，Leader 再将写请求转发给其它 Server，其它 Server 在接收到写请求后写入数据并响应 Leader,Leader 在接收到大多数写成功回应后，认为数据写成功，最后响应client，完成一次写操作过程。

zookeeper在kafka中的作用

1:Broker 注册
Broker是分布式部署并且相互之间相互独立，但是需要有一个注册系统能够将整个集群中的 Broker 管理起来，此时就使用到了 Zookeeper。在 Zookeeper 上会有一个专门用来进行 Broker 服务器列表记录的节点:/brokers/ids
每个 Broker 在启动时，都会到Zookeeper 上进行注册，即到/brokers/ids 下创建属于自己的节点，如/brokers/ids/[0...N]。Kafka 使用了全局唯一的数字来指代每个 Broker 服务器，不同的 Broker 必须使用不同的Broker ID 进行注册，创建完节点后，每个 Broker 就会将自己的 IP 地址和端口信息记录到该节点中去。其中，Broker 创建的节点类型是临时节点，一旦 Broker 宕机，则对应的临时节点也会被自动删除。
2:Topic 注册
在 Kafka 中，同一个 Topic的消息会被分成多个分区并将其分布在多个 Broker 上，这些分区信息及与 Broker 的对应关系也都是由 Zookeeper 在维护，由专门的节点来记录,如:/borkers/topics

Kafka 中每个Topic 都会以/brokers/topics/[topic]的形式被记录，如/brokers/topics/login 和/brokers/topics/search等。Broker 服务器启动后，会到对应 Topic 节点(/brokers/topics)上注册自己的 Broker ID 并写入针对该 Topic 的分区总数,如/brokers/topics/1ogin/3->2,这个节点表示Broker ID为3的一个Broker服务器，对于"login"这个Topic 的消息，提供了2个分区进行消息存储，同样，这个分区节点也是临时节点。
3:生产者负载均衡
由于同一个 Topic 消息会被分区并将其分布在多个 Broker 上，因此，生产者需要将消息合理地发送到这些分布式的 Broker 上，那么如何实现生产者的负载均衡，Kafka 支持传统的四层负载均衡，也支持 Zookeeper方式实现负载均衡。(1)四层负载均衡
根据生产者的 IP 地址和端口来为其确定一个相关联的 Broker。通常，一个生产者只会对应单个 Broker，然后该生产者产生的消息都发往该 Broker。这种方式逻辑简单，每个生产者不需要同其他系统建立额外的 TCP 连接，只需要和 Broker 维护单个 TCP 连接即可。但是，其无法做到真正的负载均衡，因为实际系统中的每个生产者产生的消息量及每个Broker的消息存储量都是不一样的，如果有些生产者产生的消息远多于其他生产者的话那么会导致不同的 Broker 接收到的消息总数差异巨大，同时，生产者也无法实时感知到Broker 的新增和删除。
(2)使用 Zookeeper 进行负载均衡
由于每个 Broker 启动时，都会完成 Broker 注册过程，生产者会通过该节点的变化来动态地感知到 Broker 服务器列表的变更，这样就可以实现动态的负载均衡机制。

4:消费者负载均衡
与生产者类似,Kafka中的消费者同样需要进行负载均衡来实现多个消费者合理地从对应的 Broker 服务器上接收消息，每个消费者分组包含若干消费者，每条消息都只会发送给分组中的一个消费者，不同的消费者分组消费自己特定的Topic 下面的消息，互不干扰。
5:分区 与 消费者 的关系
消费组(ConsumerGroup)下有多个Consumer(消费者)。对于每个消费者组(Consumer Group)，Kafka都会为其分配一个全局唯一的Group ID，Group 内部的所有消费者共享该ID。订阅的topic下的每个分区只能分配给某个group下的一个consumer(当然该分区还可以被分配给其他group)
同时，Kafka为每个消费者分配一个ConsumerID，通常采用"Hostname:UUID"形式表示。
在 Kafka中，规定了每个消息分区 只能被同组的一个消费者进行消费，因此，需要在Zookeeper 上记录消息分区与Consumer 之间的关系,每个消费者一旦确定了对一个消息分区的消费权力，需要将其Consumer ID写入到 Zookeeper 对应消息分区的临时节点上，例如:/consumers/[group_id]/owners/[topic]/[broker_id-partition_id]其中，[broker_id-partition_id]就是一个 消息分区 的标识，节点内容就是该 消息分区上消费者的Consumer ID.

6:消息消费进度 0ffset 记录
在消费者对指定消息分区进行消息消费的过程中，需要定时地将分区消息的消费进度0ffset记录到Zookeeper上,以便在该消费者进行重启或者其他消费者重新接管该消息分区的消息消费后，能够从之前的进度开始继续进行消息消费。0ffset在Zookeeper中由个专门节点进行记录，其节点路径为:/consumers/[group id]/offsets/[topic]/[broker _id-partition_id]节点内容就是 Offset 的值。
7:消费者注册
消费者服务器在初始化启动时加入消费者分组的步如下:
(1)注册到消费者分组
每个消费者服务器启动时，都会到Zookeeper的指定节点下创建一个属于自己的消费者节点，例如/consumers/[group_id]/ids/[consumer_id]，完成节点创建后，消费者就会将自己订阅的 Topic 信息写入该临时节点。
(2)对消费者分组中的消费者的变化注册监听
每个消费者都需要关注所属消费者分组中其他消费者服务器的变化情况，即对
/consumers/[group_id]/ids 节点注册子节点变化的 Watcher 监听，一旦发现消费者新增或减少，就触发消费者的负载均衡。
(3)对 Broker 服务器变化注册监听
消费者需要对/broker/ids/[0-N]中的节点进行监听，如果发现 Broker 服务器列表发生变化，那么就根据具体情况来决定是否需要进行消费者负载均衡。(4)进行消费者负载均衡
为了让同一个Topic下不同分区的消息尽量均衡地被多个 消费者 消费而进行 消费者与消息分区分配的过程，通常，对于一个消费者分组，如果组内的消费者服务器发生变更或Broker 服务器发生变更，会发出消费者负载均衡。

单点部署kafka

安装zookeeper

[root@kafka1 ~]# yum -y install java
[root@kafka1 ~]# tar zxvf apache-zookeeper-3.6.0-bin.tar.gz
[root@kafka1 ~]# mv apache-zookeeper-3.6.0-bin /etc/zookeeper
[root@kafka1 ~]# cd /etc/zookeeper/conf
[root@kafka1 ~]# mv zoo_sample.cfg zoo.cfg
[root@kafka1 ~]# vim zoo.cfg
dataDir=/etc/zookeeper/zookeeper-data
[root@kafka1 ~]# cd /etc/zookeeper/
[root@kafka1 kafka]# mkdir /etc/zookeeper/zookeeper-data/
[root@kafka1 zookeeper]# ./bin/zkserver.sh start
[root@kafka1 zookeeper]# ./bin/zkserver.sh status

安装kafka

[root@kafka1 ~]# tar zxvf kafka_2.13-2.4.1.tgz
[root@kafka1 ~]# mv kafka 2.13-2.4.1 /etc/kafka
[root@kafka1 ~]# cd /etc/kafka/
[root@kafka1 kafka]# vim config/server.propertieslog.dirs=/etc/kafka/kafka-logs
#68 行
[root@kafka1 kafka]# mkdir /etc/kafka/kafka-logs
[root@kafka1 kafka]# bin/kafka-server-start.sh config/server.properties 8
#检查两个端口的开启状态
[root@kafka1 kafka]# netstat -anptgrep 2181
[root@kafka1 kafka]# netstat -anpt | grep 9092

注意:启动时先启动zookeeper，关闭时先关闭kafka如果要关闭 zookeeper
[root@kafka1 zookeeper]# ./bin/zkServer.sh start
如果要关闭 kafka
[root@192 kafka]# bin/kafka-server-stop.sh如果关不了，就 ki11杀死该进程

测试

创建 topic
bin/kafka-topics.sh --create --zookeeper kafka1:2181 --replication-factor1 --partitions 1--topic test
列出 topic
bin/kafka-topics.sh --list --zookeeper kafka1:2181
查看 topic
bin/kafka-topics.sh --describe --zookeeper kafka1:2181 --topic test
生产消息
bin/kafka-console-producer,sh --broker-list kafka1:9092 -topic test
消费消息
bin/kafka-console-consumer,sh --bootstrap-server kafka1:9092 --topic test
删除 topic
bin/kafka-topics,sh --delete --zookeeper kafkal:2181 --topic test

群集部署kafka

主机
kafka1: 192.168.10.101
kafka2: 192.168.10.102
kafka3: 192.168.10.103

zookeeper的部署

这里大部分操作三台机器都是相同的，故而可以将操作同步起来，降低实验的繁琐性

安装zookeeper（3个节点相同）

[root@kafka1 ~]# yum -y install java
[root@kafka1 ~]# tar zxvf apache-zookeeper-3.6.0-bin.tar.gz
[root@kafka1 ~]# mv apache-zookeeper-3.6.0-bin /etc/zookeeper

创建数据保存目录（3个节点相同）

[root@kafka1 ~]# cd /etc/zookeeper/
[root@kafka1 zookeeper]# mkdir zookeeper-data

修改配置文件（3个节点相同）

[root@kafka1 zookeeper]# cd /etc/zookeeper/conf
[root@kafka1 ~]# mv zoo_ sample.cfg zoo.cfg
[root@kafka1 ~]# vim zoo.cfg
dataDir=/etc/zookeeper/zookeeper-dataclientPort=2181
server.1=192.168.10.114:2888:3888
server.2=192.168.10.115:2888:3888
server.3=192.168.10.116:2888:3888

注释:zookeeper只用的端口
2181:对 cline 端提供服务
3888:选举 leader 使用
2888:集群内机器通讯使用(Leader 监听此端口)

创建id文件按照sever编号设置id，三台机器不同

节点 1:
[root@kafka1 conf]# echo'1'>/etc/zookeeper/zookeeper-data/myid

节点 2:
[root@kafka2 conf]# echo'2'>/etc/zookeeper/zookeeper-data/myid

节点 3:
[root@kafka3 conf]# echo'3">/etc/zookeeper/zookeeper-data/myid

三个节点启动 zookeeper 进程

[root@kafka1 conf]# cd /etc/zookeeper/

[root@kafka1 zookeeper]# ./bin/zkserver.sh start

[root@kafka1 zookeeper]#./bin/zkserver.sh status

kafka的部署

kafka的安装（三节点相同）

[root@kafka1 ~]# tar zxvf kafka_2.13-2.4.1.tgz
[root@kafka1 ~]# mv kafka 2.13-2.4.1 /etc/kafka

修改配置文件

注释:
9092 是 kafka 的监听端

创建日志目录（三节点相同）

启动（三节点相同）

测试