大数据-78 Kafka 集群模式 集群的应用场景与Kafka集群的搭建 三台云服务器

点一下关注吧！！！非常感谢！！持续更新！！！

目前已经更新到了：

• Hadoop（已更完）
• HDFS（已更完）
• MapReduce（已更完）
• Hive（已更完）
• Flume（已更完）
• Sqoop（已更完）
• Zookeeper（已更完）
• HBase（已更完）
• Redis （已更完）
• Kafka（正在更新…）

章节内容

上节我们完成了如下的内容：

• Kafka 延时队列
• Kafka 重试队列
• Kafka JavaAPI 实现 重试队列的操作

应用场景

消息传递

Kafka可以很好的替代传统的邮件代理，消息代理的使用有很多种原因（将处理与数据生产者分离，缓冲未处理消息等）。与大多数邮件系统相比，Kafka具有更好的吞吐量，内置的分区，复制和容错功能，这使其成为大规模邮件处理应用程序的理想解决方案。

网站活动路由

Kafka最初的用例是能够将用户活动跟踪管道重建为一组实时的发布-订阅。这意味着将网站活动（页面浏览、搜索、其他操作等）发布到主题中心，每种活动类型只有一个主题。这些可用于一系列的用例的订阅，包括实时处理，实时监控，以及加载到Hadoop或脱机数据仓库系统中以进行脱机处理和报告。
活动跟踪通常量很大，因为每个用户页面视图都会生成许多活动消息。

监控指标

Kafka通常用于操作监控数据，这涉及汇总来自分布式应用程序的统计信息，以生成操作数据的集中。

日志汇总

许多人使用Kafka代替日志聚合解决方案，日志聚合通常从服务器收集物理日志文件，并将它们放在中央位置（也许是文件服务器或HDFS）以进行处理。Kafka提取文件的详细信息，并以日志的形式更清晰的抽象日志或事件数据，这允许较低的延迟的处理，并更容易支持多个数据源和分布式数据消耗。以日志为中心的系统（例如Scribe或Flume）相比，Kafka具有同样出色的性能，由于复制而提供的更强的耐用性保证以及更低的端到端的延迟。

流处理

Kafka的需要用户在由多个阶段组成的处理管道中处理数据，其中原始输入数据从Kafka主题中使用，然后进行汇总，充实或以其他方式转换为新主题，以供进一步使用或后续处理。例如，用于推荐新闻文章的处理管道可能会从RSS提要中检索文章内容，并将其发布到文章主题中。进一步的处理可能会使该内容规范化或重复数据删除，并将清晰后的文章内容发布到新主题中。最后的处理阶段可能会尝试向用户推荐此内容。这样的处理管道基于各个主题创建实时数据流的图形。
从0.10.0.0开始，一个轻量但功能强大的流处理库成为KafkaStreams可以在ApacheKafka中使用来执行上述数据处理。除了KafkaStreams之外，其他开源流处理工具还包括ApacheStorm和Apache Samza。

活动采集

事件源是一种应用程序，其中状态更改以时间顺序记录记录。Kafka对大量存储的日志数据的支持使其成为以这种样式构建的应用程序的绝佳后端。

提交日志

Kafka可以用作分布式系统的一种外部提交日志，该日志有助于在节点之间复制数据，并充当故障节点恢复其数据的重新同步机制。Kafka中的日志压缩功能有助于支持此用法。

集群搭建

集群设计

由于之前我们已经搭建过单机的Kafka，同时我们为了做之前的实验，一共搭建了两台Kafka的小集群（用作Broker宕机之后的分区、副本等内容的测试），这里我们将对一些部分进行简化。

机器详情

目前我们有三台云服务：

• h121.wzk.icu
• h122.wzk.icu
• h123.wzk.icu

我们已经搭建好了，ZooKeeper的集群，如果你还没有搭建，需要回到之前的章节：ZooKeeper集群搭建。

这里开始，我们直接搭建Kafka的集群环境。

在 h121.wzk.icu 中，我我们已经有了：kafka_2.12-2.7.2 且是配置好的。

我们借助之前Hadoop中编写的Shell工具来完成Kafka文件的分发（你也可以使用别的方法，比如压缩包等等）

登录后复制

rsync-script kafka_2.12-2.7.2/

• 1.

h121

h122

h123

环境变量

我们在三台节点上，尽量配置好环境变量：

• JDK
• ZooKeeper
• Kafka

修改配置

h121

登录后复制

vim /opt/servers/kafka_2.12-2.7.2/config/server.properties

• 1.

修改如下内容：

登录后复制

# h121是0、h122是1、h123是2
broker.id=0

# 数据的存储目录
log.dirs=/opt/kafka-logs

# ZooKeeper 地址
zookeeper.connect=h121.wzk.icu:2181,h122.wzk.icu:2181,h123.wzk.icu:2181

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.

对应的内容截图如下所示：

h122

登录后复制

# h121是0、h122是1、h123是2
broker.id=1

# 数据的存储目录
log.dirs=/opt/kafka-logs

# ZooKeeper 地址
zookeeper.connect=h121.wzk.icu:2181,h122.wzk.icu:2181,h123.wzk.icu:2181

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.

h123

登录后复制

# h121是0、h122是1、h123是2
broker.id=3

# 数据的存储目录
log.dirs=/opt/kafka-logs

# ZooKeeper 地址
zookeeper.connect=h121.wzk.icu:2181,h122.wzk.icu:2181,h123.wzk.icu:2181

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.

对应的截图如下图所示：

启动集群

在每台节点上都执行：

登录后复制

kafka-server-start.sh /opt/servers/kafka_2.12-2.7.2/config/server.properties

• 1.

查看集群

我们需要进入ZooKeeper来启动服务：

登录后复制

zkCli.sh
# 进入ZK后，我们查看当中的信息
ls /brokers/ids

• 1.
• 2.
• 3.

执行结果如下图所示：

第一次执行的时候，我的第三台没有配置好环境变量，启动失败了，第二次可以看到：【0,1,2】

h121

登录后复制

[zk: localhost:2181(CONNECTED) 2] get /brokers/ids/0
{"listener_security_protocol_map":{"PLAINTEXT":"PLAINTEXT"},"endpoints":["PLAINTEXT://h121.wzk.icu:9092"],"jmx_port":-1,"features":{},"host":"h121.wzk.icu","timestamp":"1722931444209","port":9092,"version":5}
[zk: localhost:2181(CONNECTED) 3]

• 1.
• 2.
• 3.

h122

登录后复制

[zk: localhost:2181(CONNECTED) 3] get /brokers/ids/1
{"listener_security_protocol_map":{"PLAINTEXT":"PLAINTEXT"},"endpoints":["PLAINTEXT://h122.wzk.icu:9092"],"jmx_port":-1,"features":{},"host":"h122.wzk.icu","timestamp":"1722931447944","port":9092,"version":5}

• 1.
• 2.

h123

登录后复制

[zk: localhost:2181(CONNECTED) 4] get /brokers/ids/2
{"listener_security_protocol_map":{"PLAINTEXT":"PLAINTEXT"},"endpoints":["PLAINTEXT://h123.wzk.icu:9092"],"jmx_port":-1,"features":{},"host":"h123.wzk.icu","timestamp":"1722931584357","port":9092,"version":5}

• 1.
• 2.

如下所示：

原创作者: u_16814091 转载于: https://blog.51cto.com/u_16814091/11792961