网站与网页之间的区别是什么意思,东台建设企业网站,手机做广告设计用什么软件,seo 网站文章一般要多少字这一部分主要是接触 Kafka #xff0c;并熟悉 Kafka 的使用方式。快速熟练的搭建 kafka 服务#xff0c;对于快速验证一些基于Kafka 的解决方案#xff0c;也是非常有用的。 一、 Kafka 介绍 ChatGPT 对于 Apache Kafka 的介绍#xff1a; 1 、 MQ 的作用 MQ #xff1a;… 这一部分主要是接触 Kafka 并熟悉 Kafka 的使用方式。快速熟练的搭建 kafka 服务对于快速验证一些基于Kafka 的解决方案也是非常有用的。 一、 Kafka 介绍 ChatGPT 对于 Apache Kafka 的介绍 1 、 MQ 的作用 MQ MessageQueue 消息队列。 队列是一种 FIFO 先进先出的数据结构。消息则是跨进程传递的数据。一个典型的MQ 系统会将消息由生产者发送到 MQ 进行排队然后根据一定的顺序交由消息的消费者进行处理 MQ 的作用主要有以下三个方面 · 异步 例子快递员发快递直接到客户家效率会很低。引入菜鸟驿站后快递员只需要把快递放到菜鸟驿站就可以继续发其他快递去了。客户再按自己的时间安排去菜鸟驿站取快递。 作用异步能提高系统的响应速度、吞吐量。 · 解耦 例子《 Thinking in JAVA 》很经典但是都是英文我们看不懂所以需要编辑社将文章翻译成其他语言这样就可以完成英语与其他语言的交流。 作用 1 、服务之间进行解耦才可以减少服务之间的影响。提高系统整体的稳定性以及可扩展性。 2 、另外解耦后可以实现数据分发。生产者发送一个消息后可以由一个或者多个消费者进行消费并且消费者的增加或者减少对生产者没有影响。 · 削峰 例子长江每年都会涨水但是下游出水口的速度是基本稳定的所以会涨水。引入三峡大坝后可以把水储存起来下游慢慢排水。 作用以稳定的系统资源应对突发的流量冲击。 2 、为什么要用 Kafka 一个典型的日志聚合的应用场景 业务场景决定了产品的特点。 1 、数据吞吐量很大 需要能够快速收集各个渠道的海量日志 2 、集群容错性高允许集群中少量节点崩溃 3 、功能不需要太复杂 Kafka 的设计目标是高吞吐、低延迟和可扩展主要关注消息传递而不是消息处理。所以Kafka 并没有支持死信队列、顺序消息等高级功能。 4 、允许少量数据丢失 Kafka 本身也在不断优化数据安全问题目前基本上可以认为 Kafka 可以做到不会丢数据。 二、 Kafka 快速上手 1 、实验环境 准备了三台虚拟机 192.168.232.128~130 预备搭建三台机器的集群。 三台机器均预装 CentOS7 操作系统。分别配置机器名 worker1 worker2 worker3 。 然后需要关闭防火墙 ( 实验环境建议关闭 ) 。 然后三台机器上都需要安装 JAVA 。 JAVA 的安装过程就不多说了。实验中采用目前用得最多的 JAVA 8 版本就可以了。 下载 kafka 选择当前最新的 3.2.0 版本。下载地址 https://kafka.apache.org/downloads 选择 kafka_2.13-3.4.0.tgz 进行下载。 下载 Zookeeper 下载地址 https://zookeeper.apache.org/releases.html Zookeeper 的版本并没有强制要求这里我们选择比较新的3.6.1 版本。 下载完成后将这两个工具包上传到三台服务器上解压后分别放到 /app/kafka 和 /app/zookeeper 目录下。并将部署目录下的bin 目录路径配置到 path 环境变量中。 2 、单机服务体验 下载下来的 Kafka 安装包不需要做任何的配置就可以直接单击运行。这通常是快速了解 Kafka 的第一步。 1 、启动 Kafka 之前需要先启动 Zookeeper 。 这里就用 Kafka 自带的 Zookeeper 。启动脚本在 bin 目录下。 从 nohup.out 中可以看到 zookeeper 默认会在 2181 端口启动。通过 jps 指令看到一个 QuorumPeerMain 进程确定服务启动成功。 2 、启动 Kafka 。 启动完成后使用 jps 指令看到一个 kafka 进程确定服务启动成功。服务会默认在 9092 端口启动。 3 、简单收发消息 Kafka 的基础工作机制是消息发送者可以将消息发送到 kafka 上指定的 topic 而消息消费者可以从指定的topic上消费消息。 首先可以使用 Kafka 提供的客户端脚本创建 Topic 然后启动一个消息发送者端。往一个名为 test 的 Topic 发送消息。 当命令行出现 符号后随意输入一些字符。 CtrlC 退出命令行。这样就完成了往 kafka 发消息的操作。 然后启动一个消息消费端从名为 test 的 Topic 上接收消息。 这样就完成了一个基础的交互。这其中生产者和消费者并不需要同时启动。他们之间可以进行数据交互但是又并不依赖于对方。没有生产者消费者依然可以正常工作反过来没有消费者生产者也依然可以正常工作。这也体现出了生产者和消费者之间的解耦。 4 、其他消费模式 之前我们通过 kafka 提供的生产者和消费者脚本启动了一个简单的消息生产者以及消息消费者实际上kafka还提供了丰富的消息消费方式。 指定消费进度 通过 kafka-console.consumer.sh 启动的控制台消费者会将获取到的内容在命令行中输出。如果想要消费之前发送的消息可以通过添加--from-begining 参数指定。 如果需要更精确的消费消息甚至可以指定从哪一条消息开始消费。 这表示从第 0 号 Partition 上的第四个消息开始读起。 Partition 和 Offset 是什么呢可以用以下指令查看。 分组消费 对于每个消费者可以指定一个消费者组。 kafka 中的同一条消息只能被同一个消费者组下的某一个消费者消费。而不属于同一个消费者组的其他消费者也可以消费到这一条消息。在kafka-console-consumer.sh脚本中可以通过 --consumer-property group.idtestGroup 来指定所属的消费者组。例如可以启动三个消费者组来验证一下分组消费机制 查看消费者组的偏移量 接下来还可以使用 kafka-consumer-groups.sh 观测消费者组的情况。包括他们的消费进度。 从这里可以看到虽然业务上是通过 Topic 来分发消息的但是实际上消息是保存在 Partition 这样一个数据结构上的。 3 、理解 Kakfa 的消息传递机制 从之前的实验可以看到 Kafka 的消息发送者和消息消费者通过 Topic 这样一个逻辑概念来进行业务沟通。但是实际上所有的消息是存在服务端的Partition 这样一个数据结构当中的。 在 Kafka 的技术体系中有以下一些概念需要先熟悉起来 · 客户端 Client 包括消息生产者 和 消息消费者。之前简单接触过。 · 消费者组每个消费者可以指定一个所属的消费者组相同消费者组的消费者共同构成一个逻辑消费者组。每一个消息会被多个感兴趣的消费者组消费但是在每一个消费者组内部一个消息只会被消费一 次。 · 服务端 Broker 一个 Kafka 服务器就是一个 Broker 。 · 话题 Topic 这是一个逻辑概念一个 Topic 被认为是业务含义相同的一组消息。客户端都通过绑定Topic来生产或者消费自己感兴趣的话题。 · 分区 Partition Topic 只是一个逻辑概念而 Partition 就是实际存储消息的组件。每个 Partiton 就是一个queue 队列结构。所有消息以 FIFO 先进先出的顺序保存在这些 Partition 分区中。 4 、 Kafka 集群服务 为什么要用集群 单机服务下 Kafka 已经具备了非常高的性能。 TPS 能够达到百万级别。但是在实际工作中使用时单机搭建的Kafka 会有很大的局限性。 一方面消息太多需要分开保存。 Kafka 是面向海量消息设计的一个 Topic 下的消息会非常多单机服务很难存得下来。这些消息就需要分成不同的Partition 分布到多个不同的 Broker 上。这样每个 Broker 就只需要保存一部分数据。这些分区的个数就称为分区数。 另一方面服务不稳定数据容易丢失。单机服务下如果服务崩溃数据就丢失了。为了保证数据安全就需要给每个Partition 配置一个或多个备份保证数据不丢失。 Kafka 的集群模式下每个 Partition 都有一个或多个备份。Kafka 会通过一个统一的 Zookeeper 集群作为选举中心给每个 Partition 选举出一个主节点Leader 其他节点就是从节点 Follower 。主节点负责响应客户端的具体业务请求并保存消息。而从节点则负责同步主节点的数据。当主节点发生故障时Kafka 会选举出一个从节点成为新的主节点。 最后 Kafka 集群中的这些 Broker 信息包括 Partition 的选举信息都会保存在额外部署的 Zookeeper 集群当中这样kafka 集群就不会因为某一些 Broker 服务崩溃而中断。 Kafka 的集群架构大体是这样的 接下来我们就动手部署一个 Kafka 集群来体验一下 Kafka 是如何面向海量数据进行横向扩展的。 我们先来部署一个基于 Zookeeper 的 Kafka 集群。其中选举中心部分 Zookeeper 是一种多数同意的选举机制允许集群中少数节点出现故障。因此在搭建集群时通常都是采用3 5 7 这样的奇数节点这样可以最大化集群的高可用特性。 在后续的实验过程中我们会在三台服务器上都部署Zookeeper 和Kafka。 1 、部署 Zookeeper 集群 这里采用之前单独下载的 Zookeeper 来部署集群。 Zookeeper 是一种多数同意的选举机制允许集群中少半数节点出现故障。因此在搭建集群时通常采用奇数节点这样可以最大化集群的高可用特性。在后续的实现过程中我们会在三台服务器上都部署Zookeeper 。 先将下载下来的 Zookeeper 解压到 /app/zookeeper 目录。 然后进入 conf 目录修改配置文件。在 conf 目录中提供了一个 zoo_sample.cfg 文件这是一个示例文件。我们只需要将这个文件复制一份zoo.cfg(cp zoo_sample.cfg zoo.cfg) 修改下其中的关键配置就可以了。其中比较关键的修改参数如下 接下来将整个 Zookeeper 的应用目录分发到另外两台机器上。就可以在三台机器上都启动 Zookeeper 服务了。 启动完成后使用 jps 指令可以看到一个 QuorumPeerMain 进程就表示服务启动成功。 三台机器都启动完成后可以查看下集群状态。 2 、部署 Kafka 集群 kafka 服务并不需要进行选举因此也没有奇数台服务的建议。 部署 Kafka 的方式跟部署 Zookeeper 差不多就是解压、配置、启服务三板斧。 首先将 Kafka 解压到 /app/kafka 目录下。 然后进入 config 目录修改 server.properties 。这个配置文件里面的配置项非常多下面列出几个要重点关注的配置。 接下来就可以启动 kafka 服务了。启动服务时需要指定配置文件。 通过 jps 指令可以查看 Kafka 的进程。 5 、理解服务端的 Topic 、 Partition 和 Broker 接下来可以对比一下之前的单机服务快速理解 Kafka 的集群当中核心的 Topic 、 Partition 、 Broker 。 从这里可以看到 1 、 --create 创建集群可以指定一些补充的参数。大部分的参数都可以在配置文件中指定默认值。 · partitons 参数表示分区数这个 Topic 下的消息会分别存入这些不同的分区中。示例中创建的 disTopic 指定了四个分区也就是说这个 Topic 下的消息会划分为四个部分。 · replication-factor 表示每个分区有几个备份。示例中创建的 disTopic 指定了每个 partition 有两个备份。 2 、 --describe 查看 Topic 信息。 · partiton 参数列出了四个 partition 后面带有分区编号用来标识这些分区。 · Leader 表示这一组 partiton 中的 Leader 节点是哪一个。这个 Leader 节点就是负责响应客户端请求的主节点。从这里可以看到Kafka 中的每一个 Partition 都会分配 Leader 也就是说每个 Partition 都有不同的节点来负责响应客户端的请求。这样就可以将客户端的请求做到尽量的分散。 · Replicas 参数表示这个 partition 的多个备份是分配在哪些 Broker 上的。也称为 AR 。这里的 0,1,2 就对应配置集群时指定的broker.id 。但是 Replicas 列出的只是一个逻辑上的分配情况并不关心数据实际是不是按照这个分配。甚至有些节点服务挂了之后Replicas 中也依然会列出节点的 ID 。 · ISR 参数表示 partition 的实际分配情况。他是 AR 的一个子集只列出那些当前还存活能够正常同步数据的那些Broker 节点。 接下来我们还可以查看 Topic 下的 Partition 分布情况。在 Broker 上与消息联系最为紧密的其实就是Partition 了。之前在配置 Kafka 集群时指定了一个 log.dirs 属性指向了一个服务器上的日志目录。进入这个目录就能看到每个Broker 的实际数据承载情况。 从这里可以看到 Broker 上的一个 Partition 对应了日志目录中的一个目录。而这个 Partition 上的所有消息就保存在这个对应的目录当中。 从整个过程可以看到 Kafka 当中 Topic 是一个数据集合的逻辑单元 。同一个 Topic 下的数据实际上是存储在Partition 分区中的 Partition 就是数据存储的物理单元 。而 Broker 是 Partition 的物理载体 这些Partition分区会尽量均匀的分配到不同的 Broker 机器上。而之前接触到的 offset 就是每个消息在 partition上的偏移量。 Kafka 为何要这样来设计 Topic 、 Partition 和 Broker 的关系呢 1 、 Kafka 设计需要支持海量的数据而这样庞大的数据量一个 Broker 是存不下的。那就拆分成多个Partition每个 Broker 只存一部分数据。这样 极大的扩展了集群的吞吐量 。 2 、每个 Partition 保留了一部分的消息副本如果放到一个 Broker 上就容易出现单点故障。所以就给每个Partition设计 Follower 节点进行数据备份从而保证数据安全。另外多备份的 Partition 设计也 提高了读 取消息时的并发度 。 3 、在同一个 Topic 的多个 Partition 中会产生一个 Partition 作为 Leader 。这个 Leader Partition 会负责响应客户端的请求并将数据往其他Partition 分发。 6 、章节总结 Kafka 集群的整体结构 经过上面的实验我们接触到了很多 Kafka 中的概念。将这些基础概念整合起来就形成了 Kafka 集群的整体结构。这次我们先把这个整体结构梳理清楚后续再一点点去了解其中的细节。 1 、 Topic 是一个逻辑概念 Producer 和 Consumer 通过 Topic 进行业务沟通。 2 、 Topic 并不存储数据 Topic 下的数据分为多组 Partition 尽量平均的分散到各个 Broker 上。每组 Partition 包含 Topic 下一部分的消息。每组 Partition 包含一个 Leader Partition 以及若干个 Follower Partition进行备份每组Partition 的个数称为备份因子 replica factor 。 3 、 Producer 将消息发送到对应的 Partition 上然后 Consumer 通过 Partition 上的 Offset 偏移量记录自己所属消费者组Group 在当前 Partition 上消费消息的进度。 4 、 Producer 发送给一个 Topic 的消息会由 Kafka 推送给所有订阅了这个 Topic 的消费者组进行处理。但是在每个消费者组内部只会有一个消费者实例处理这一条消息。 5 、最后 Kafka 的 Broker 通过 Zookeeper 组成集群。然后在这些 Broker 中需要选举产生一个担任 Controller 角色的 Broker 。这个 Controller 的主要任务就是负责 Topic 的分配以及后续管理工作。在我们实验的集群中这个Controller 实际上是通过 ZooKeeper 产生的。 三、 Kraft 集群 -- 了解 1 、 Kraft 集群简介 Kraft 是 Kafka 从 2.8.0 版本开始支持的一种新的集群架构方式。其目的主要是为了摆脱 Kafka 对 Zookeeper的依赖。因为以往基于Zookeeper 搭建的集群增加了 Kafka 演进与运维的难度逐渐开始成为 Kakfa 拥抱云原生的一种障碍。使用Kraft 集群后 Kafka 集群就不再需要依赖 Zookeeper 将之前基于 Zookeeper 管理的集群数据转为由Kafka 集群自己管理。 传统的 Kafka 集群会将每个节点的状态信息统一保存在 Zookeeper 中并通过 Zookeeper 动态选举产生一个Controller 节点通过 Controller 节点来管理 Kafka 集群比如触发 Partition 的选举。而在 Kraft 集群中会固定配置几台Broker 节点来共同担任 Controller 的角色各组 Partition 的 Leader 节点就会由这些Controller选举产生。原本保存在 Zookeeper 中的元数据也转而保存到 Controller 节点中。 新的 Kraft 集群相比传统基于 Zookeeper 的集群有一些很明显的好处 · Kafka 可以不依赖于外部框架独立运行。这样减少 Zookeeper 性能抖动对 Kafka 集群性能的影响同时Kafka产品的版本迭代也更自由。 · Controller 不再由 Zookeeper 动态选举产生而是由配置文件进行固定。这样比较适合配合一些高可用工具来保持集群的稳定性。 · Zookeeper 的产品特性决定了他不适合存储大量的数据这对 Kafka 的集群规模 ( 确切的说应该是 Partition 规模 ) 是极大的限制。摆脱 Zookeeper 后集群扩展时元数据的读写能力得到增强。 不过由于分布式算法的复杂性。 Kraft 集群和同样基于 Raft 协议定制的 RocketMQ 的 Dledger 集群一样都还在不太稳定在真实企业开发中用得相对还是比较少。 2 、配置 Kraft 集群 在 Kafka 的 config 目录下提供了一个 kraft 的文件夹在这里面就是 Kraft 协议的参考配置文件。在这个文件夹中有三个配置文件broker.properties,controller.properties,server.properties 分别给出了 Kraft 中三种不同角色的示例配置。 · broker.properties: 数据节点 · controller.properties: Controller 控制节点 · server.properties: 即可以是数据节点又可以是 Controller 控制节点。 这里同样列出几个比较关键的配置项按照自己的环境进行定制即可。 将配置文件分发并修改每个服务器上的 node.id 属性和 advertised.listeners 属性。 由于 Kafka 的 Kraft 集群对数据格式有另外的要求所以在启动 Kraft 集群前还需要对日志目录进行格式化。 接下来就可以指定配置文件启动 Kafka 的服务了。 例如在 Worker1 上启动 Broker 和 Controller 服务。 等三个服务都启动完成后就可以像普通集群一样去创建 Topic 并维护 Topic 的信息了。
