三节点Kafka(3.9.0-支持jdk8的最高稳定版本)集群部署

详解Kafka 3.0 稳定版新特性 Kafka 2.8.0正式发布了KRaft的先行版,并且支持在KRaft模式下的部署和运行。KRaft模式下的Kafka可以完全脱离Zookeeper运行,使用自己的基于Raft算法实现的quorum来保证分布式Metadata的一致 阅读详情

三节点Kafka(3.9.0-支持jdk8的最高稳定版本)集群部署

一.背景介绍

本次搭建Kafka服务架构为批流一体数仓架构,整体的流程图如下:
在这里插入图片描述

1.项目背景与架构综述 (Project Background & Architecture)

1.1 建设目标

为了满足业务对数据鲜活度日益增长的需求,本项目旨在构建基于 Flink + Paimon 的新一代**流批一体(Stream-Batch Unified)**实时数据仓库。项目核心目标是打通从业务数据库(MySQL)到数据湖(Paimon)的实时同步链路,实现 ODS 层的亚秒级入湖与 DWD 层的实时清洗转换,同时利用 Paimon 的特性统一流式读写与批量查询能力。

1.2 数据链路架构

整体数据流转架构设计如下(参考架构流程图图):
数据源层 (Source):采用 MySQL 5.7.44 搭建一主两从(Master-Slave)的高可用集群,确保业务稳定性。
数据采集层 (Ingestion):部署 Maxwell 1.44.0 监听 Slave1 节点的 Binlog,将变更数据实时解析为 JSON 流。
消息缓冲层 (Buffer):构建 3节点 Kafka 3.9.0 集群(Topic: ods_mysql),作为 CDC 数据的核心缓冲区,承担削峰填谷与高吞吐消息分发的任务。
计算与存储层 (Compute & Storage):
使用 Flink 1.19.3 作为计算引擎,通过 Flink SQL 定义流式任务。
底层存储采用 Apache Paimon(1.1.1),构建无分区的 ODS 表与 DWD 表,实现数据的分层管理与实时更新。

2. 技术选型与环境制约说明 (Technical Selection & Constraints)

2.1 核心环境制约:CDH 6.3.2 与 JDK 8

本项目的计算资源调度强依赖于现有的 CDH 6.3.2 (Cloudera Distribution Hadoop) 大数据平台底座。由于 CDH 6.3.2 生态系统(包括 HDFS、YARN、MapReduce)与 JDK 1.8 (Java 8) 存在深度绑定关系,这对上层组件的选型产生了以下决定性影响:
Flink on YARN 的兼容性:Flink 1.19.3 任务必须提交至 CDH 6.3.2 的 YARN 集群运行。为了保障 Flink Client、YARN Container 以及 Hadoop Classpath 之间的类加载兼容性,避免 UnsupportedClassVersionError 或运行时环境冲突,整个计算链路的运行环境必须严格锁定在 JDK 8。
Kafka 版本选择逻辑:尽管 Kafka 社区在新版本中逐步转向 Java 11+,但为了与 CDH 6.3.2 的 JDK 8 环境保持一致,确保 Flink Kafka Connector 在 YARN 容器中运行的稳定性,我们选用了 Kafka 3.9.0。该版本是在支持 JDK 8 运行环境前提下的高版本稳定发行版,既能提供较新的功能特性与性能优化,又能完美适配基于 JDK 8 的存量生产环境。

3. 组件版本清单 (Component Specifications)

为确保集群搭建的兼容性,各组件具体版本规划如下:

组件名称版本号角色/部署说明备注
JDK1.8.0_412基础运行环境,全节点统一CDH 6.3.2 官方最高支持版本
Kafka3.9.03 节点集群(Broker ×3)支持 JDK 8 的最高稳定版,Scala 2.12 官方二进制包
MySQL5.7.441 Master + 2 Slave 主从架构与 CDH 6.x 认证版本一致,Row-Based Binlog
Maxwell1.44.0单节点 CDC 采集,连接 Slave1末版默认 JDK 8 编译,向下兼容 Kafka 3.9
Flink1.19.3On YARN 模式,流 & 批一体官方提供 JDK 8 二进制包,内置 kafka-client 3.9
Paimon1.1.1数据湖存储,集成 Flink 1.19支持 CDC 高效写入,与 Flink 1.19 官方兼容
HadoopCDH 6.3.2资源调度(YARN)+ 存储(HDFS)整套体系已含 ZooKeeper、HDFS、YARN,无需额外部署

4.Kafka三节点部署(3.9版本)

4.1 JDK 8 安装
#下载jdk8
sudo yum install -y java-1.8.0-openjdk-devel

修改环境变量

vi ~/.bashrc

添加以下:

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk
export PATH=$JAVA_HOME/bin:$PATH
#刷新环境变量
source ~/.bashrc
#查看有没有成功
java -version

如图所示结果则证明安装成功:
在这里插入图片描述

4.2 kafka三节点部署(xx.xx.xx.xx1,xx.xx.xx.xx2,xx.xx.xx.xx3)
4.2.1下载压缩包并创建日志存放文件
#下载 & 解压 3.9.0(三台同时)
wget -c https://archive.apache.org/dist/kafka/3.9.0/kafka_2.13-3.9.0.tgz
tar -zxvf kafka_2.13-3.9.0.tgz
#创建日志存放文件
mkdir -p /home/bigdata/kafka-data
4.2.2修改配置文件
#进入目录
cd /home/bigdata/kafka_2.13-3.9.0/config/kraft/

复制默认配置文件,备份(所有节点):

#节点一
cp config/kraft/server.properties config/kraft/server1.properties
#节点二
cp config/kraft/server.properties config/kraft/server2.properties
#节点三
cp config/kraft/server.properties config/kraft/server3.properties

修改配置文件节点一(xx.xx.xx.xx1):
修改server1.properties文件:

process.roles=broker,controller
node.id=1
controller.quorum.voters=1@xx.xx.xx.xx1:9093,2@xx.xx.xx.xx2:9093,3@xx.xx.xx.xx3:9093
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
inter.broker.listener.name=PLAINTEXT
advertised.listeners=PLAINTEXT://xx.xx.xx.xx1:9092,CONTROLLER://xx.xx.xx.xx1:9093
controller.listener.names=CONTROLLER
log.dirs=/home/bigdata/kafka-data
num.partitions=3
off-sets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2

修改配置文件节点一(xx.xx.xx.xx2):
修改server2.properties文件:

bash
process.roles=broker,controller
node.id=2
controller.quorum.voters=1@xx.xx.xx.xx1:9093,2@xx.xx.xx.xx2:9093,3@xx.xx.xx.xx3:9093
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
inter.broker.listener.name=PLAINTEXT
advertised.listeners=PLAINTEXT://xx.xx.xx.xx2:9092,CONTROLLER://xx.xx.xx.xx2:9093
controller.listener.names=CONTROLLER
log.dirs=/home/bigdata/kafka-data
num.partitions=3
off-sets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2

修改配置文件节点一(xx.xx.xx.xx3):
修改server3.properties文件:

bash
process.roles=broker,controller
node.id=2
controller.quorum.voters=1@xx.xx.xx.xx1:9093,2@xx.xx.xx.xx2:9093,3@xx.xx.xx.xx3:9093
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
inter.broker.listener.name=PLAINTEXT
advertised.listeners=PLAINTEXT://xx.xx.xx.xx3:9092,CONTROLLER://xx.xx.xx.xx3:9093
controller.listener.names=CONTROLLER
log.dirs=/home/bigdata/kafka-data
num.partitions=3
off-sets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2

参数解释:

参数示例值含义/作用备注
process.rolesbroker,controller该节点同时承担「代理」与「控制器」角色3 节点集群推荐全设为 broker,controller,形成合并模式
node.id1集群内唯一数字 ID,替代原来的 broker.id每台分别写 1/2/3,与 voters 列表对应
controller.quorum.voters1@ip1:9093,2@ip2:9093,3@ip3:9093构成控制仲裁的节点与端口必须列出全部 3 个;格式 id@host:port
listenersPLAINTEXT://:9092,CONTROLLER://:9093本机监听的所有接口与端口0.0.0.0 表示绑定任意地址;生产可改为内网 IP
inter.broker.listener.namePLAINTEXTBroker 之间通信使用的监听器名字必须与 listeners 里某一项名字一致
advertised.listenersPLAINTEXT://ip1:9092,CONTROLLER://ip1:9093对外公布的地址,供客户端和其他节点连接写客户端能解析的 IP 或主机名
controller.listener.namesCONTROLLER控制器仲裁使用的监听器名字只能选一个,与 voters 里的端口对应
log.dirs/home/bigdata/kafka-data存储段文件(.log/.index/.timeindex)的目录多块盘可逗号分隔;需保证读写性能
num.partitions3自动创建 Topic 时的默认分区数后期可通过 kafka-topics.sh 动态扩容
offsets.topic.replication.factor3__consumer_offsets 副本数必须 ≤ 存活 broker 数,建议 =3
transaction.state.log.replication.factor3__transaction_state 副本数使用 EOS/Flink 精确一次时必须 =3
transaction.state.log.min.isr2事务 Topic 最小可用副本设为 replication.factor-1,兼顾高可用与一致性
4.2.3格式化存储 (仅需生成一次 UUID)

三台机器必须使用同一个 Cluster ID 进行初始化。
在主节点(xx.xx.xx.xx1)上生成 UUID:

cd /home/bigdata/kafka_2.13-3.9.0

bin/kafka-storage.sh random-uuid

结果如下:
在这里插入图片描述
在节点 1 (xx.xx.xx.xx1) 上格式化:

bin/kafka-storage.sh format -t "A9LsS6bwQ1Spwmxdnk6vFg" -c config/kraft/server1.properties

在节点 2 (xx.xx.xx.xx2) 上格式化 (使用同一个 UUID):

bin/kafka-storage.sh format -t "A9LsS6bwQ1Spwmxdnk6vFg" -c config/kraft/server2.properties

在节点 3 (xx.xx.xx.xx3) 上格式化 (使用同一个 UUID):

bin/kafka-storage.sh format -t "A9LsS6bwQ1Spwmxdnk6vFg" -c config/kraft/server3.properties
4.2.3启动三节点Kafka,并进行测试

启动命令:

cd /home/bigdata/kafka_2.13-3.9.0

然后在节点1上执行:

bin/kafka-server-start.sh -daemon config/kraft/server1.properties

然后在节点2上执行:

bin/kafka-server-start.sh -daemon config/kraft/server2.properties

然后在节点3上执行:

bin/kafka-server-start.sh -daemon config/kraft/server3.properties

然后查看集群状态:

bin/kafka-metadata-quorum.sh --bootstrap-server xx.xx.xx.xx1:9092 describe --status

在这里插入图片描述
创建topic:

bin/kafka-topics.sh --create \
  --bootstrap-server xx.xx.xx.xx1:9092 \
  --topic test-topic \
  --partitions 3 \
  --replication-factor 3

在这里插入图片描述
然后验证分区分布情况(关键)
创建后,我们需要看下这个 Topic 的分区是否均匀分布在了三台机器上。

bin/kafka-topics.sh --describe \
  --bootstrap-server xx.xx.xx.xx1:9092 \
  --topic test-topic

在这里插入图片描述
模拟发送消息(生产者)
启动控制台生产者,向集群发送几条消息。

bin/kafka-console-producer.sh \
  --bootstrap-server xx.xx.xx.xx1:9092 \
  --topic test-topic

出现 > 符号后,随意输入几行文字,按回车发送:
hello word
在这里插入图片描述
模拟接收消息(消费者)
启动控制台消费者,看看能否读到刚才发的消息。

bin/kafka-console-consumer.sh \
  --bootstrap-server xx.xx.xx.xx1:9092 \
  --topic test-topic \
  --from-beginning

在这里插入图片描述

4.3总流程测试代码
from kafka import KafkaProducer, KafkaConsumer, KafkaAdminClient
from kafka.admin import NewTopic
from kafka.errors import KafkaError, TopicAlreadyExistsError
import json
import time
import random
import threading

# 配置信息
BOOTSTRAP_SERVERS = ['xx.xx.xx.xx1:9092', 'xx.xx.xx.xx2:9092', 'xx.xx.xx.xx3:9092']
TEST_TOPIC = 'performance_test'
TEST_GROUP = 'test_consumer_group'


def create_test_topic():
    """创建测试主题(如果不存在)"""
    admin = KafkaAdminClient(bootstrap_servers=BOOTSTRAP_SERVERS)

    try:
        topic = NewTopic(
            name=TEST_TOPIC,
            num_partitions=6,
            replication_factor=3,
            topic_configs={'retention.ms': '172800000'}  # 保留2天
        )
        admin.create_topics([topic])
        print(f"主题 {TEST_TOPIC} 创建成功")
    except TopicAlreadyExistsError:
        print(f"主题 {TEST_TOPIC} 已存在")
    finally:
        admin.close()


def producer_performance_test():
    """生产者性能测试"""
    producer = KafkaProducer(
        bootstrap_servers=BOOTSTRAP_SERVERS,
        value_serializer=lambda v: json.dumps(v).encode('utf-8'),
        acks='all',
        compression_type='gzip',
        retries=5
    )

    start_time = time.time()
    msg_count = 0

    for i in range(1000):
        payload = {
            "id": i,
            "timestamp": time.time(),
            "metric": random.uniform(0, 100),
            "source": f"server-{random.randint(1, 10)}",
            "is_alert": random.random() > 0.9
        }

        future = producer.send(
            TEST_TOPIC,
            value=payload,
            key=str(i % 10).encode()  # 按key分区
        )

        # 异步处理发送结果
        future.add_callback(
            lambda metadata: print(f"发送成功: 分区={metadata.partition} 偏移量={metadata.offset}")
        ).add_errback(
            lambda exc: print(f"发送失败: {exc}")
        )

        msg_count += 1

        # 每100条刷新一次
        if i % 100 == 0:
            producer.flush()

    producer.flush()
    elapsed = time.time() - start_time
    print(f"\n生产者测试完成: 发送 {msg_count} 条消息, 耗时 {elapsed:.2f} 秒, "
          f"吞吐量 {msg_count / elapsed:.2f} msg/s")


def consumer_group_test():
    """消费者组测试"""

    def start_consumer(consumer_id):
        consumer = KafkaConsumer(
            TEST_TOPIC,
            bootstrap_servers=BOOTSTRAP_SERVERS,
            group_id=TEST_GROUP,
            auto_offset_reset='earliest',
            enable_auto_commit=False,
            value_deserializer=lambda x: json.loads(x.decode('utf-8')),
            consumer_timeout_ms=10000
        )

        print(f"消费者 {consumer_id} 启动...")
        try:
            for message in consumer:
                print(f"消费者 {consumer_id} [分区 {message.partition}]: "
                      f"偏移量={message.offset} 值={message.value}")
                # 模拟处理时间
                time.sleep(random.uniform(0.01, 0.1))
                consumer.commit()
        finally:
            consumer.close()
            print(f"消费者 {consumer_id} 关闭")

    # 启动3个消费者线程
    threads = []
    for i in range(3):
        t = threading.Thread(target=start_consumer, args=(i,))
        t.start()
        threads.append(t)
        time.sleep(1)  # 错开启动时间

    for t in threads:
        t.join()


def transaction_test():
    """事务消息测试(精确一次语义)"""
    try:
        producer = KafkaProducer(
            bootstrap_servers=BOOTSTRAP_SERVERS,
            value_serializer=lambda v: json.dumps(v).encode('utf-8'),
            transactional_id='test_transaction',
            # 添加安全协议配置(如果集群需要)
            # security_protocol='SASL_PLAINTEXT',
            # sasl_mechanism='PLAIN',
            # sasl_plain_username='admin',
            # sasl_plain_password='admin-secret',
            # 增加超时时间
            request_timeout_ms=15000,
            retries=5
        )

        # 初始化事务 - 关键步骤!
        producer.init_transactions()
        print("事务初始化成功")

        try:
            print("开始事务...")
            producer.begin_transaction()

            # 发送业务消息
            for i in range(5):
                msg = {"tx_id": i, "data": f"transaction_{i}"}
                producer.send(TEST_TOPIC, value=msg)
                print(f"事务消息发送: {msg}")

            # 提交事务
            print("提交事务...")
            producer.commit_transaction()
            print("事务提交成功")

        except KafkaError as e:
            print(f"事务操作失败: {e}")
            # 尝试中止事务
            try:
                producer.abort_transaction()
                print("事务已中止")
            except Exception as abort_err:
                print(f"中止事务失败: {abort_err}")
        finally:
            producer.close()

    except Exception as init_err:
        print(f"事务初始化失败: {init_err}")


def get_topic_metadata():
    """获取主题元数据"""
    admin = KafkaAdminClient(bootstrap_servers=BOOTSTRAP_SERVERS)

    # 获取所有主题
    topics = admin.list_topics()
    print("\n集群主题列表:")
    for topic in topics:
        print(f" - {topic}")

    # 获取特定主题详情
    if TEST_TOPIC in topics:
        partitions = admin.describe_topics([TEST_TOPIC])
        print(f"\n主题 {TEST_TOPIC} 详情:")
        for p in partitions[0]['partitions']:
            print(f"分区 {p['partition']}: 领导者={p['leader']} 副本={p['replicas']} ISR={p['isr']}")

    admin.close()


def monitor_consumer_group():
    """监控消费者组"""
    admin = KafkaAdminClient(bootstrap_servers=BOOTSTRAP_SERVERS)

    # 获取消费者组列表
    groups = admin.list_consumer_groups()
    print("\n消费者组列表:")
    for group in groups:
        print(f" - {group[0]} ({group[1]})")

    # 获取特定消费者组详情
    if any(TEST_GROUP in g for g in groups):
        group_details = admin.describe_consumer_groups([TEST_GROUP])
        print(f"\n消费者组 {TEST_GROUP} 详情:")
        for member in group_details[0].members:
            print(f"成员 {member.member_id}:")
            print(f"  客户端ID: {member.client_id}")
            print(f"  主机: {member.client_host}")
            print(f"  分配分区: {member.assignment}")

    admin.close()


if __name__ == "__main__":
    print("=" * 50)
    print("开始 Kafka 综合测试")
    print("=" * 50)

    create_test_topic()

    print("\n[阶段1] 生产者性能测试")
    producer_performance_test()

    print("\n[阶段2] 消费者组测试")
    consumer_group_test()

    print("\n[阶段3] 事务消息测试")
    transaction_test()

    print("\n[阶段4] 元数据检查")
    get_topic_metadata()

    print("\n[阶段5] 消费者组监控")
    monitor_consumer_group()

    print("\n测试完成!")
5.kafka全流程测试脚本介绍
(1)脚本名称

kafka_full_test.py

(2) 运行环境
  • 执行路径: D:\pycharm\PyCharm 2024.2.4\pythonProject1\kafka\kafka_full_test.py
  • 解释器:Python 3.8(位于 D:\pycharm\PyCharm 2024.2.4\python3.8.venv\Scripts\python.exe )
  • 测试对象:Kafka 集群(主题 performance_test )
(3)核心功能

该脚本用于对 Kafka 集群的核心功能与性能进行全面测试,涵盖 5 个关键阶段:

  • 生产者性能测试:验证消息发送效率与分区分发能力;
  • 消费者组测试:验证多消费者协同消费、分区分配与消息解析能力;
  • 事务消息测试:验证事务消息的初始化、发送与提交功能;
  • 元数据检查:验证集群主题、分区及副本配置的正确性;
  • 消费者组监控:查看集群中活跃的消费者组信息。
(4)测试结果总结
  1. 阶段 1:生产者性能测试
  • 测试内容:向主题 performance_test 发送消息,验证生产者吞吐量与分区分发逻辑。

  • 关键结果:

    • 共发送 1000 条消息,耗时 0.22 秒,吞吐量达4569.43 msg/s;(第一次测试为耗时 2.06 秒,吞吐量达485.81 msg/s)
      在这里插入图片描述
    • 消息均匀分发至 6 个分区(分区 0-5),各分区偏移量连续递增(例如分区 3 偏移量从 302 增至 601,分区 5 从 200 增至 399),说明分区负载均衡正常。
  1. 阶段 2:消费者组测试
  • 测试内容:启动 3 个消费者组成消费组,验证分区分配、消息消费完整性与内容解析能力。

  • 关键结果:
    在这里插入图片描述

    • 消费者分区分配:消费者 0 负责分区 5、4;消费者 1 负责分区 3、2;消费者 2 负责分区 0、1,分配逻辑合理;

    • 消息消费完整:所有发送的消息均被正确消费,包含事务消息(如 {‘tx_data’: ‘transaction_0’} )和业务消息(含 id 、 timestamp 、 metric 、 source 、 is_alert 等字段);

      • 事务消息:如

        {‘tx_data’: ‘transaction_0’}

        • tx_data :事务数据字段,存储事务相关的标识信息(如事务 ID)。
      • 业务消息:如

        {‘id’: 1, ‘timestamp’: 1752463717.3170567, ‘metric’: 75.68237032259279, ‘source’: ‘server-10’, ‘is_alert’: False}

        • id :消息唯一标识,用于区分不同消息。
        • timestamp :消息生成的时间戳(Unix 时间戳,精确到毫秒),记录消息产生的时间。
        • metric :指标值,通常为数值型数据(如服务器性能指标)。
        • source :消息来源,如 “server-10” 表示消息来自编号为 10 的服务器。
        • is_alert :告警标识(布尔值), True 表示该消息触发告警, False 表示正常消息。
    • 消费状态正常:消费者均成功启动并关闭,无消息丢失或重复消费。

  1. 阶段 3:事务消息测试
  • 测试内容:验证 Kafka 事务消息的初始化、发送与提交机制。

  • 关键结果:
    在这里插入图片描述

    • 事务初始化成功,发送 5 条事务消息( tx_id 0-4,数据为 transaction_0 至 transaction_4 );
    • tx_id :事务唯一标识,用于关联同一事务中的多条消息。
    • data :事务具体数据内容。
    • 事务提交成功,无异常报错,说明事务功能正常。
  1. 阶段 4:元数据检查
  • 测试内容:验证 Kafka 集群主题、分区及副本配置的正确性。

  • 关键结果:

    在这里插入图片描述

    • 集群主题列表:包含 test-topic1 、 performance_test 、 __consumer_offsets 等 10 个主题,符合预期;

    • 主题

      performance_test

      详情:

      • 共 6 个分区(0-5);
      • 每个分区均配置 3 个副本,领导者(Leader)分布在不同节点,ISR(同步副本)包含所有副本(如分区 5:领导者 = 1,副本 =[1,2,3],ISR=[1,2,3]),集群副本同步正常。
  1. 阶段 5:消费者组监控
  • 测试内容:查看集群中活跃的消费者组信息。

  • 关键结果:

    在这里插入图片描述

    • 消费者组列表:包含 test_consumer_group 和 test-group ,均为 consumer 类型,与测试配置一致。
Java中间件集群篇10 : Kafka多Broker集群搭建|生产级分区副本调优、高可用消息集群完整版 文章摘要: 本文详细讲解Kafka三节点高可用集群的生产级部署,涵盖核心概念(Broker/Topic/分区/副本)、集群架构原理及高可用机制。提供从环境准备、安装配置到参数调优的全流程操作指南,包括生产级副本配比(2副本)、分区规划、故障容错策略及开机自启配置。适配Kafka 3.x内置ZK模式,强调单机严禁上生产的风险,并给出三节点集群的黄金配置公式(16分区+2副本),适用于微服务解耦、日志削峰等高吞吐场景。 阅读详情

相关推荐

KRaft多节点集群搭建:告别ZooKeeper的Kafka云原生实践

Kafka元数据管理正从依赖外部协调服务(如ZooKeeper)转向内建Raft共识协议,这一演进本质是分布式系统控制平面的重构。KRaft通过将元数据日志与消息日志分离、在broker进程内嵌Raft副本,实现了强一致、低延迟、高可用的元数据服务。其技术价值在于消除单点依赖、简化运维拓扑、统一安全栈,并为跨地域元数据复制等云原生能力奠基。典型应用场景包括实时风控、高SLA消息中台及自动化运维平台——尤其在三节点及以上奇数quorum集群中,KRaft展现出远超ZooKeeper模式的故障恢复速度与稳定性。

weixin_33739646的博客 372

【单机上部署kafka3.5版本】

第二步,修改config目录下的server.properties文件,主要是配置broker.id、listeners、log.dirs等参数。broker.id是每个kafka节点的唯一标识,listeners是kafka监听的端口,log.dirs是kafka存储消息的目录。kafka是一个分布式的消息队列,可以实现高效的数据传输和处理。kafka3.5是最新的稳定版本,带来了一些新的特性和优化。这样就启动了一个生产者和一个消费者,分别在不同的终端输入和输出消息。

univers1的博客 938

Debian 10 手动安装 Kafka 2.8.1 完整实践指南

Apache Kafka 是一种高吞吐、分布式、持久化的消息队列系统,其核心原理基于发布-订阅模型与分区日志(Partitioned Log)机制,通过 ZooKeeper(或 KRaft)协调元数据,实现水平扩展与容错。在 Linux 服务器环境中,Kafka 的稳定运行高度依赖底层 Java 环境、用户权限隔离、systemd 服务管理及网络配置等工程细节。尤其在 Debian 10 这类长期支持(LTS)发行版中,因官方源缺失 Kafka 包、默认 JDK 版本过低、systemd 行为严格等特点,‘

chuanzhuanxian8669的博客 420

Kafka 版本该怎么选择总结

买了极客时间胡夕老师的课,上面讲到kafka各版本之间的差异,在这里总结一下,时机应用的时候该如何去选择kafka版本。 Kafka 版本命名 kafka版本已经更新到2.5了 我们看下kafka版本号的组成kafka_2.12-2.5.0.tgz前面的2.12表示的是kafka开发语言Scala的版本,后面的2.5.0才是kafka版本。 作为Javaer Scala我们都熟悉,JVM系的语言。设计上很有优势,以至于java的很多新特性都跟Scala靠拢,比如Lambda表达式,函数式编程等。

轩1024的博客 6352

Kafka Docker部署避坑指南:KRaft模式与双监听器实战

Apache Kafka 是分布式流处理的核心中间件,其容器化部署涉及网络、存储、元数据管理等多层技术协同。理解 Kafka 的监听器机制(LISTENERS/ADVERTISED_LISTENERS)与地址解析逻辑,是解决‘本地连得上、容器连不上’问题的关键;而 KRaft 模式通过移除 ZooKeeper 依赖,显著简化了 Docker 环境下的集群启动与故障恢复流程。结合命名卷挂载策略可规避权限与跨平台兼容性风险,双监听器配置则精准分离容器内/外网络访问路径,支撑 Spring Boot 应用集成、C

weixin_33859844的博客 432

Kafka 之 ZooKeeper —— 稳定版本、弃用、操作

ZooKeeper 是一个分布式的协调服务,主要用于维护集群的元数据信息和配置信息。Kafka 集群依赖于 ZooKeeper 来存储和管理 Kafka 的元数据信息和配置信息。注:以上这些都低版本 Kafka 依赖 ZooKeeper 实现的,在高版本 Kafka 中,已经摆脱了对 ZooKeeper 的强依赖。

流华追梦的专栏 2455

在CDH 6.3.2的JDK 8环境中部署Kafka 3.9.0三节点集群:一次面向流批一体架构的兼容性实践

本文详细介绍了在CDH 6.3.2的JDK 8环境中部署Kafka 3.9.0三节点集群的完整实践。针对流批一体架构的兼容性需求,文章阐述了选择Kafka 3.9.0作为支持JDK 8的最高稳定版本的原因,并提供了从环境准备、KRaft模式集群搭建、配置详解到生产级功能验证的全流程指南,确保与现有大数据生态的稳定集成。

a3b4c5的博客 89

Kafka 安装与启动

1. 下载代码 下载 2.3.0 版本并解压缩: tar -zxvf kafka_2.12-2.3.0.tgz -C . 创建软连接便于升级: ln -s kafka_2.12-2.3.0/ kafka 配置环境变量: # Kafka export KAFKA_HOME=/opt/kafka export PATH=${KAFKA_HOME}/bin:$PATH 2. 安装ZooKeeper Kafka 依赖 ZooKeeper,如果你还没有 ZooKeeper 服务器,你需要先启动一个 ZooKee

SmartSi 936

基于CDH 6.3.2与JDK 8环境约束下的Kafka 3.9.0三节点集群部署实战

本文详细介绍了在CDH 6.3.2与JDK 8的固定环境下,部署Kafka 3.9.0三节点集群的完整实战过程。文章重点阐述了版本选型、KRaft模式配置、集群部署步骤,并提供了生产级压力测试与Flink、Paimon集成的验证方案,为在老旧平台升级消息中间件提供了可靠参考。

vscode6remote的博客 429

八戒留档之宝塔部署edusoho

1.安装好基础的服务 2.上传你下载的代码到www/wwwroot文件3、配置网站 4.编辑创建的网站修改nginx文件 NGINX配置如下 server { listen 80; server_name 你的域名; root /www/wwwroot/项目文件名称/web/; location / { try_files $uri /app_dev.php$is_args$args; } ...

wolf23151269的博客 2541

【Matlab/Unity】跨平台UDP通信实战:从数据发送到实时可视化

本文详细介绍了Matlab与Unity之间通过UDP协议实现跨平台通信的实战方法,涵盖数据发送、接收和实时可视化全流程。针对科研仿真和工业设计场景,提供优化代码示例和性能对比数据,帮助开发者解决低延迟传输、线程安全等关键问题,显著提升跨平台协作效率。

weixin_29044713的博客 153

从MySQL到Paimon:一个真实流批一体数仓项目中,Kafka 3.9.0集群的配置与避坑实录

本文详细介绍了在金融风控系统升级项目中,如何基于JDK8环境配置Kafka 3.9.0集群以支持流批一体数仓架构。从技术选型、KRaft模式下的关键参数配置,到与Flink和Paimon的集成优化,提供了实战经验与避坑指南,帮助读者构建高可靠、高性能的数据管道。

weixin_30955617的博客 419

自动驾驶预测决策规划八股

预测规划八股个人总结。

dawushixiange的博客 479

Kafka 3.6.1部署实战:单机集群、命令行与可视化工具全攻略

Kafka作为分布式消息队列的核心组件,承载着数据管道和流处理的关键任务。理解其底层原理,如ZooKeeper与KRaft两种元数据管理模式,是搭建高可用Kafka集群的前提。Kafka通过分区、副本机制实现水平扩展与容错,广泛用于日志采集、实时计算等场景。Kafka 3.6.1作为一个稳定且兼容性佳的版本,既支持传统ZooKeeper,也支持新KRaft模式,适合作为部署实践的基础。从单机环境起步,逐步扩展至三节点集群,使用命令行完成Topic生产消费与消费组监控,借助可视化工具Offset Explor

weixin_34341117的博客 253

【电路设计】带阻滤波器实战:从理论到Twin-T陷波电路实现

本文详细介绍了带阻滤波器的原理与Twin-T陷波电路的实战应用,从基础概念到工程实现全面解析。通过具体案例展示如何设计高Q值滤波器,解决电源噪声等实际问题,并分享PCB布局和元件选型的实用技巧,助力工程师提升电路设计能力。

gg901的博客 1022

ROS从入门到精通2-1:机器人3D可视化工具——Rviz

本文详细介绍了Rviz是什么?为什么要使用这个工具?清晰地列出了Rviz的安装流程和界面的基本功能元素;讲解了Rviz基本数据类型与话题,并用两个实例深入理解Rviz数据可视化的过程

FRIGIDWINTER的博客 5348

Kafka与ZooKeeper集群搭建实战:从0到1的完整指南

分布式系统离不开元数据协调与一致性管理,ZooKeeper作为老牌协调组件,为Kafka提供broker注册、分区选主等关键能力。理解二者分工是搭建稳定消息队列的基础。在生产环境中,Kafka集群的高可用依赖合理的副本因子、ISR机制和ZooKeeper的奇数节点部署。从架构原理到环境准备,本文以三节点为例,详解Kafka与ZooKeeper集群的配置、启动验证、故障演练及常见问题排查,并针对版本兼容、参数调优、多磁盘规划等易错点给出工程实践建议,适合运维与开发人员作为从零搭建高可用消息队列的实操参考。

weixin_33985507的博客 368

【华为OD机试真题】18、喊7的次数重排 | 机试真题+思路参考+代码解析(C++、Java、Py)

题目描述 >喊7是一个传统的聚会游戏,N个人围成一圈,按顺时针从1到N编号。   编号为1的人从1开始喊数,下一个人喊的数字为上一个人的数字加1,但是当将要喊出来的数字是7的倍数或者数字本身含有7的话,不能把这个数字直接喊出来,而是要喊”过”。   假定玩这个游戏的N个人都没有失误地在正确的时机喊了”过”,当喊到数字K时,可以统计每个人喊”过”的次数。   现给定一个长度为N的数组,存储了打乱顺序的每个人喊”过”的次数,请把它还原成正确的顺序,即数组的第i个元素存储编号i的人喊

KJ.JK 4168

Kafka入门集群搭建:从架构原理到实战排错全指南

在分布式系统与消息队列的工程实践中,Kafka凭借高吞吐、持久化、水平扩展等特性,成为异步解耦与削峰填谷的核心组件。理解Broker、Topic、Partition、Replica之间的协作关系,是掌握集群部署的基础。本文从Kafka基础架构出发,面向入门开发者,系统讲解三节点集群的环境准备、版本选型、核心参数配置、启动验证流程,并结合生产者消费者测试观察分区副本的分布与ISR机制。针对初学者最常见的网络连接超时、broker.id冲突、ZooKeeper协调异常等问题,给出了具体排查思路与配置建议,帮助读

weixin_29051245的博客 208

Ceph入门到精通-更换osd、扩容osd

【代码】Ceph入门到精通-更换osd、扩容osd。

隔壁老瓦的专栏 1548

机器学习笔记:估算模型训练所需的样本量的方法

相反,如果训练得分高而交叉验证得分低,那么模型可能存在过拟合问题,需要更多的样本来提高泛化能力。本文将介绍一些常用的方法来估算模型训练所需的样本量,并提供相应的源代码。除了经验法则和学习曲线法,还有一些统计学方法可以用于估算模型训练所需的样本量。学习曲线是一种通过绘制模型性能与样本量之间的关系曲线来估算样本量的方法。需要注意的是,这些方法仅提供了估算样本量的指导,具体的样本量仍然需要根据实际情况进行调整和优化。通过合理估算样本量,可以提高机器学习模型的性能和泛化能力,从而更好地应用于实际问题中。

HnrzLinux的博客 2733

Kafka高可用集群搭建实战:Zookeeper与故障切换

消息队列是大数据与分布式系统中的核心组件,承担着削峰填谷、异步解耦的关键作用。而Kafka作为高性能的分布式消息中间件,其生产级部署必须依赖Zookeeper集群完成元数据管理与控制器选举。然而,单机Kafka存在单点故障、数据安全风险与性能瓶颈,无法支撑真实业务流量。本文从Kafka与Zookeeper的协作原理出发,介绍三节点集群的部署规划、核心参数配置及副本机制,强调高可用架构的设计要点。结合故障演练场景,演示broker宕机后的自动切换与数据恢复流程,帮助读者理解副本因子、ISR列表等关键概念在保障

weixin_34409357的博客 470

Probability and Statistics - 4th edition

Probability and Statistics - 4th edition

ZooKeeper安装配置与集群搭建实战:从单机到三节点调优排错

分布式协调服务是分布式系统实现一致性、选主和元数据管理的基础设施。ZooKeeper 借助内存数据树、ZAB 协议和过半选举机制,把小容量配置与状态数据做成强一致的共享存储,并在多数节点存活时持续提供高可用协调能力。它常被用于 Hadoop HA 自动故障切换、HBase 元数据入口、HiveServer2 服务发现,以及分布式锁、命名服务和配置中心等场景。落到工程实践,zoo.cfg、myid、server.x、会话超时与四字命令监控决定了集群能否稳定运行;从单机、伪集群到三节点真集群的安装配置,再结合

weixin_34055787的博客 394

IMSL CNL 7.0.0 (x86-64)Crack

IMSL CNL 7.0.0 (x86-64)Crack intel的算法库破解文件,这是C++版本的破解文件

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

DigitalOcean上稳定部署Kafka Schema Registry实战指南

Kafka Schema Registry是保障Avro/Protobuf等结构化数据在消息系统中一致演化的关键组件,其核心原理是通过集中式schema存储与版本化管理,实现生产者与消费者间的契约约束。技术价值在于避免因字段变更导致的反序列化失败、数据解析错乱等线上故障,显著提升微服务间数据交互的可靠性与可维护性。典型应用场景包括实时数仓建设、IoT设备数据标准化、金融交易事件溯源等强schema依赖架构。本文聚焦在DigitalOcean Droplet环境下的手动部署实践,覆盖JDK调优、ZooKeep

weixin_34245749的博客 381

大数据分布式集群部署与运维实战:从HDFS到高可用

分布式架构是应对海量数据存储与计算的通用工程思想,其核心原理是将数据和任务拆分到多台机器上并行处理,从而突破单机硬件在存储和计算上的物理极限。在大数据场景下,以Hadoop生态为代表的分布式集群,通过HDFS实现存储横向扩容,借助YARN完成资源统一调度,并利用ZooKeeper等协调组件保障集群高可用。这种架构支撑着离线批处理、实时流计算、交互式查询等典型应用,成为企业数据平台的基础设施。本文围绕集群搭建全流程,梳理了从基础环境准备、核心组件选型与配置、高可用设计,到任务调度、消息队列及日常运维巡检的关键

weixin_34389926的博客 307

Ubuntu 18.04 安装 Apache Kafka 实操指南:从系统准备到生产就绪

Apache Kafka 是一种高吞吐、低延迟的分布式流处理平台,其核心原理基于发布-订阅模型与持久化日志存储,通过分区(Partition)、副本(Replica)和 ISR 机制保障可扩展性与容错性。技术价值在于解耦微服务、统一实时数据管道、支撑事件驱动架构,广泛应用于 IoT 数据接入、订单库存解耦、用户行为埋点等场景。在 Ubuntu 18.04 这类长期支持但已停止标准维护的系统上部署 Kafka,需特别关注 JDK 11 兼容性、systemd 服务管理、磁盘 I/O 规划及 ZooKeeper

weixin_30493401的博客 459
上一篇: Paimon底层存储数据结构和架构原理以及tag功能和paimon入门实例
下一篇: maxwell(1.44.0)暂停监听某些表的测试
wangyutian5u
博客等级 码龄4年 94粉丝 15原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值