【kafka】——Broker

最新推荐文章于 2024-07-29 14:22:26 发布
最新推荐文章于 2024-07-29 14:22:26 发布
阅读量4.1k 收藏 6
点赞数
分类专栏： kafka bigdata 文章标签： kafka java 分布式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_42000631/article/details/127089779
版权

Kfaka Broker

1. Zookeeper 存储的kafka信息

在这里插入图片描述

<1> /kafka/brokers/dis

存储broker的id，记录有哪些服务器
在这里插入图片描述

<2> /kafka/brokers/topics

存储topic 相关信息
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

<3> /kafka/consumers

Kafka 0.9 版本之前 用于保存offset信息
Kafka 0.9 版本之后offser存储在Kafka主题中

<4> /kafka/controller

辅助选举Leader
在这里插入图片描述

2. Broker工作流程

在这里插入图片描述
<1> Broker 启动后在Zookeeper中注册
<2> 每个节点中的Contoller 抢先在Zookeeper中注册，谁抢先注册，谁负责Leader选举
<3> 由选举出来的Controller 监听brokers节点的变化
<4> 选举规则：在ISR中存活为前提，按照AR（Kafka分区中的所有副本统称）中排在前面的优先，例如：AR[1,0,2]，ISR[0,1,2],那么Leader就会按照1，0，2 的顺序轮询
<5> Controller将节点信息上传到ZK
<6> 其他Controller从zk同步相关信息
<7> 生产者发送数据到Leader ，Follower 主动从Leader 拉取信息。
<8> 底层通过Segment存储，一个Segment默认大小1G。.log文件存储信息。.index文件存储索引，加快检索速度。
<9> 如果Ledaer 宕机。Controller监听到brokers节点发生变化，从ZK拉取Leader 和ISR信息，然后重新选举Leader（ISR中存活为前提。按照AR中排在前面的有限）。更新Leader 和ISR

3. 模拟Kafka上下线

<1> 原始状态

  1. 查看/kafka/brokers/ids 路径上的节点。
    在这里插入图片描述

  2. 查看/kafka/controller 路径上的数据。
    在这里插入图片描述

  3. 查看/kafka/brokers/topics/test_topic/partitions/0/state 路径上的数据
    在这里插入图片描述

<2> 停止 Follower节点后状态

   在这里插入图片描述

  1. 再次查看/kafka/brokers/ids 路径上的节点
    在这里插入图片描述

  2. 查看/kafka/controller 路径上的数据。
    在这里插入图片描述

  3. 查看/kafka/brokers/topics/test_topic/partitions/0/state 路径上的数据
    在这里插入图片描述

<3> 停止 Leader节点后状态

 在这里插入图片描述

  1. 再次查看/kafka/brokers/ids 路径上的节点
    在这里插入图片描述

  2. 查看/kafka/controller 路径上的数据。
    在这里插入图片描述

  3. 查看/kafka/brokers/topics/test_topic/partitions/0/state 路径上的数据
    在这里插入图片描述

4. 新增和减少节点

<1> 新节点准备

1. 修改IP 地址和主机名

在这里插入图片描述
在这里插入图片描述

2. 安装JDK和Kakfa

在这里插入图片描述

kafka 需要修改配置文件，brokerid 需要全局唯一
如果是从其他服务器克隆，则需要删除datas目录我logs目录下的内容。

3. 启动新增节点上的Kafka
bin/kafka-server-start.sh - daemon ./config/server.properties

<2> 新增节点

   如果只是作为新topic 使用，则不需要以下操作。如果想要将旧topic 的数据迁移到新增节点上，因为已经创建的topic主题的分区和副本只在旧的节点上，那么需要以下操作。可见 test_topic 的分区和副本都在 0，1，2 三个broker中。
   通过命令，可见 test_topic 的分区和副本都在 0，1，2 三个broker中。
在这里插入图片描述

1. 创建一个要均衡的主题

在Kafka根目录下创建文件 topics-to-move.json

{
    "topics": [
        {
            "topic": "test_topic"
        }
    ],
    "version": 1
}

test_topic 为测试节点，如果是多个topic ，只需要在json串中并列添加。“version”: 1是固定写法

2. 生成一个负载均衡的计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2,3" --generate

3 为新增的节点的brokerID
在这里插入图片描述
Current partition replica assignment（当前的分区和副本规划）

{"version":1,"partitions":[{"topic":"test_topic","partition":0,"replicas":[0,2,1],"log_dirs":["any","any","any"]},{"topic":"test_topic","partition":1,"replicas":[1,2,0],"log_dirs":["any","any"test_topic","partition":2,"replicas":[2,0,1],"log_dirs":["any","any","any"]}]}

Proposed partition reassignment configuration（新提出的分区和副本计划）

{"version":1,"partitions":[{"topic":"test_topic","partition":0,"replicas":[3,0,1],"log_dirs":["any","any","any"]},{"topic":"test_topic","partition":1,"replicas":[0,1,2],"log_dirs":["any","any"test_topic","partition":2,"replicas":[1,2,3],"log_dirs":["any","any","any"]}]}

可见在新提出的分区和副本计划中添加了brokerid=3的新增节点。

3. 创建副本存储计划

在Kafka根目录下创建文件vim increase-replication-factor.json，将新提出的分区和副本计划写入文件。

{
    "version": 1,
    "partitions": [
        {
            "topic": "test_topic",
            "partition": 0,
            "replicas": [
                3,
                0,
                1
            ],
            "log_dirs": [
                "any",
                "any",
                "any"
            ]
        },
        {
            "topic": "test_topic",
            "partition": 1,
            "replicas": [
                0,
                1,
                2
            ],
            "log_dirs": [
                "any",
                "any",
                "any"
            ]
        },
        {
            "topic": "test_topic",
            "partition": 2,
            "replicas": [
                1,
                2,
                3
            ],
            "log_dirs": [
                "any",
                "any",
                "any"
            ]
        }
    ]
}
4. 执行副本存储计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --reassignment-json-file increase-replication-factor.json --execute

在这里插入图片描述

5. 验证副本存储计划

<1> 方式一

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --reassignment-json-file increase-replication-factor.json --verify

在这里插入图片描述

<2> 方式二

bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --topic test_topic --describe

在这里插入图片描述

<3> 减少节点

当减少一个kafka集群节点的时候，不能简单粗暴的将节点停止，因为有的topic的分区和副本在节点上，如果直接停止会造成数据丢失，需要进行以下操作。

1. 创建一个要均衡的主题

在Kafka根目录下创建文件 topics-to-move.json

{
    "topics": [
        {
            "topic": "test_topic"
        }
    ],
    "version": 1
}

test_topic 为测试节点，如果是多个topic ，只需要在json串中并列添加。“version”: 1是固定写法

2. 生成一个负载均衡的计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2" --generate

broker-list只保留要留存的节点
在这里插入图片描述

Current partition replica assignment（当前的分区和副本规划）

{"version":1,"partitions":[{"topic":"test_topic","partition":0,"replicas":[3,0,1],"log_dirs":["any","any","any"]},{"topic":"test_topic","partition":1,"replicas":[0,1,2],"log_dirs":["any","any","any"]},{"topic":"test_topic","partition":2,"replicas":[1,2,3],"log_dirs":["any","any","any"]}]}

Proposed partition reassignment configuration（新提出的分区和副本计划）

{"version":1,"partitions":[{"topic":"test_topic","partition":0,"replicas":[0,1,2],"log_dirs":["any","any","any"]},{"topic":"test_topic","partition":1,"replicas":[1,2,0],"log_dirs":["any","any","any"]},{"topic":"test_topic","partition":2,"replicas":[2,0,1],"log_dirs":["any","any","any"]}]}

可见在新提出的分区和副本计划中 只保留要留存的节点。

3. 创建副本存储计划

在Kafka根目录下创建文件vim increase-replication-factor.json，将新提出的分区和副本计划写入文件。

{
    "version": 1,
    "partitions": [
        {
            "topic": "test_topic",
            "partition": 0,
            "replicas": [
                0,
                1,
                2
            ],
            "log_dirs": [
                "any",
                "any",
                "any"
            ]
        },
        {
            "topic": "test_topic",
            "partition": 1,
            "replicas": [
                1,
                2,
                0
            ],
            "log_dirs": [
                "any",
                "any",
                "any"
            ]
        },
        {
            "topic": "test_topic",
            "partition": 2,
            "replicas": [
                2,
                0,
                1
            ],
            "log_dirs": [
                "any",
                "any",
                "any"
            ]
        }
    ]
}
4. 执行副本存储计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --reassignment-json-file increase-replication-factor.json --execute

在这里插入图片描述

5. 验证副本存储计划

<1> 方式一

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --reassignment-json-file increase-replication-factor.json --verify

在这里插入图片描述

<2> 方式二

bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --topic test_topic --describe

在这里插入图片描述
在这里插入图片描述

6. 停止节点
bin/kafka-server-stop.sh

5. Kafka副本

<1> 基本信息

  1. 作用：提高数据可靠性
  2. 默认一个副本，生产环境一般配置2个。保证数据可靠性；太多副本会增加磁盘空间，增加网络上数据传输，降低效率。
  3. 分为Leader 和Follower。kafka生产者只会把数据发送给Leader。饭后Follower找Leader进行同步数据。
  4. ISR：标识和Leader保持同步的Follower集合，如果长时间未向Leader发送通讯请求或同步数据，则Follower将被提出ISR。该时间阈值由replica.time.max.ms 参数设定，默认30s。Leader发生故障之后，就会从ISR中选举新的Leader。
  5. SR：表示Follower与Leader副本同步时，延迟过多
  6. AR：Kafka分区中所有副本的统称 O的副本。

<2> Leader选举流程

Kafka集群中有个一broker的Controller 会被选举为Controller Leader。负责管理集群broker的上下线，所有topic的分区副本分配和Leader选举等工作。Controller的信息同步工作是依赖于Zookeeper的。
在这里插入图片描述

  1. Broker 启动后在Zookeeper中注册
  2. 每个节点中的Contoller 抢先在Zookeeper中注册，谁抢先注册，谁负责Leader选举
  3. 由选举出来的Controller 监听brokers节点的变化
  4. 选举规则：在ISR中存活为前提，按照AR（Kafka分区中的所有副本统称）中排在前面的优先，例如：AR[1,0,2]，ISR[0,1,2],那么Leader就会按照1，0，2 的顺序轮询
  5. 如果Ledaer 宕机。Controller监听到brokers节点发生变化，从ZK拉取Leader 和ISR信息，然后重新选举Leader（ISR中存活为前提，按照AR中排在前面的有限）。

<3> Leader 和Follower 故障处理细节

1. LEO（Log End Offset）

每个副本的最后一个offset ，LEO其实就是最新的offset +1 。

2. HW（High Watermark）

所有副本中最小的LEO。

3. Follower 故障

在这里插入图片描述
<1> Follower 发生故障后，会被临时踢出ISR。
<2> 这个期间Leader和Follower继续接受数据。
<3> 待该Follower恢复后，Follower 会读取本地磁盘记录的上次的HW。并将log文件高于HW的部分截取掉，从HW开始向Leader进行同步。
<4> 待该Follower的LEO大于等于该Partition的HW。即Follower追上Leader之后，就可以重新加入ISR了。

4. Leader故障

<1> Leader发生故障后，会被临时踢出ISR。
<2> 从ISR 中选出一个新的Leader。
<3> 为保证多个副本之间的数据一致性，其余的Follower会先将各自的log 文件高于HW的部分接截掉，然后从新的Leader同步数据。（只能保证副本之间的数据一致的，并不能保证数据不丢失或者不重复）

<4> 分区副本分配

1. 默认分配

如果kafka分区数大于服务器台数默认情况下， kafka分区分配时候，底层实现是尽量均匀分布的。

2. 手动分配

在生产环境中，每台服务器的配置和性能不一致，但是Kafka只会根据自己的代码规则创建对应的分区副本，就会导致个别服务器存储压力较大。所有需要手动调整分区副本的存储。

3. 实例

创建一个新的主题，4个分区，每个分区2个副本。默认情况下分区和副本会分布在四个节点上，再手动改为broker0 和broker1上。

<1> 创建主题
bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --topic test_assign_topic --create --partitions 4 --replication-factor 2
<2> 查看分区和副本分布情况
bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092  --topic test_assign_topic --describe

在这里插入图片描述

<3> 创建副本存储计划

在Kafka根目录下创建文件vim increase-replication-factor.json，将新提出的分区和副本计划写入文件。

 {
    "version": 1,
    "partitions": [
        {
            "topic": "test_assign_topic",
            "partition": 0,
            "replicas": [
                1,
                0
            ],
            "log_dirs": [
                "any",
                "any"
            ]
        },
        {
            "topic": "test_assign_topic",
            "partition": 1,
            "replicas": [
                0,
                1
            ],
            "log_dirs": [
                "any",
                "any"
            ]
        },
        {
            "topic": "test_assign_topic",
            "partition": 2,
            "replicas": [
                1,
                0
            ],
            "log_dirs": [
                "any",
                "any"
            ]
        },
        {
            "topic": "test_assign_topic",
            "partition": 3,
            "replicas": [
                0,
                1
            ],
            "log_dirs": [
                "any",
                "any"
            ]
        }
    ]
}
<4> 执行副本存储计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --reassignment-json-file increase-replication-factor.json --execute

在这里插入图片描述

<5> 验证副本存储计划

<1> 方式一

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --reassignment-json-file increase-replication-factor.json --verify

在这里插入图片描述
<2> 方式二

bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --topic test_topic --describe

在这里插入图片描述

<5> Leader Partition 负载平衡

  正常情况下，Kafka本身会自动把Leader Partition均匀分散在各个机器上，来保证每台机器的读写吞吐量都是均匀的。但是如果某些broker宕机，会导致Leader Partition过于集中在其他少部分几台broker上，这会导致少数几台broker的读写请求压力过高，其他宕机的broker重启之后都是follower partition，读写请求很低，造成集群负载不均衡。

1. 自动平衡

<1> auto.leader.rebalance.enable
默认是true。自动Leader Partition平衡
<2> leader.imbalance.per.broker.percentage
默认是10%。每个broker允许的不平衡的leader的比率。如果每个broker超过了这个值，控制器会触发leader的平衡。
<3> leader.imbalance.check.interval.seconds
默认值300秒。检查leader负载是否平衡的间隔时间。

<6> 增加副本

1. 创建主题
bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092, hadoop105:9092 --topic test_add_replication_topic --create --partitions 4 --replication-factor 1
2. 查看分区和副本分布情况
bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092  --topic test_add_replication_topic --describe

在这里插入图片描述

3. 创建副本存储计划

在Kafka根目录下创建文件vim increase-replication-factor.json，将新提出的分区和副本计划写入文件。

{
    "version": 1,
    "partitions": [
        {
            "topic": "test_add_replication_topic",
            "partition": 0,
            "replicas": [
                1,
                0
            ],
            "log_dirs": [
                "any",
                "any"
            ]
        },
        {
            "topic": "test_add_replication_topic",
            "partition": 1,
            "replicas": [
                0,
                1
            ],
            "log_dirs": [
                "any",
                "any"
            ]
        },
        {
            "topic": "test_add_replication_topic",
            "partition": 2,
            "replicas": [
                2,
                3
            ],
            "log_dirs": [
                "any",
                "any"
            ]
        },
        {
            "topic": "test_add_replication_topic",
            "partition": 3,
            "replicas": [
                3,
                2
            ],
            "log_dirs": [
                "any",
                "any"
            ]
        }
    ]
}
4. 执行副本存储计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --reassignment-json-file increase-replication-factor.json --execute

在这里插入图片描述

5. 验证副本存储计划

<1> 方式一

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --reassignment-json-file increase-replication-factor.json --verify

在这里插入图片描述

<2> 方式二

bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --topic test_add_replication_topic --describe

在这里插入图片描述

6. 文件存储机制

<1> 概述

在这里插入图片描述

  1. Topic是逻辑上的概念，而partition是物理上的概念。
  2. 每个partition对应一个log文件(log文件也是虚拟概念)，该log文件中存储的就是Producer生产的数据。Producer生产的数据会被不断追加到该log文件末端。
  3. 为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个partition分为多个segment。log.segment.bytes 指定segment的大小，默认值 1G。
  4. 每个segment包括:.index文件、.log文件和.timeindex等文件。位于同一目录下。
  5. 该文件夹的命名规则为：topic名称+分区序号，例如test_topic-0。
  6. Kafka 中的消息默认保存7天。

<2> 查看文件内容

通过工具查看 index 和 log 信息。

kafka-run-class.sh kafka.tools.DumpLogSegments --files ./00000000000000000000.index

kafka-run-class.sh kafka.tools.DumpLogSegments --files ./00000000000000000000.logs

<3> index 文件和 log 文件详解

  1. index为稀疏索引，大约每往log 文件中写入4kb数据，会往index文件中写入一条索引，参数log.index.interval.bytes 默认4kb
  2. index文件中保存的offset为相对offset，这样能保证offset的值所占空间不会过大，因此能将offset 的值控制在固定大小。

<4> 查找过程

在这里插入图片描述

  1. 根据目标offset定位segment文件。
  2. 找到小于或等于目标offset的最大offset对那个的索引项。
  3. 定位到log文件。
  4. 向下遍历找到目标record。

7. 文件清理策略

<1> 概述

Kafka 中默认的日志保存时间为 7 天，
可以通过调整如下参数修改保存时间。

  1. log.retention.hours，最低优先级，小时，默认 7 天。
  2. log.retention.minutes，分钟。 高于小时优先级
  3. log.retention.ms，最高优先级，毫秒。
  4. log.retention.check.interval.ms，负责设置检查周期，默认 5 分钟

<2> 日志清理策略

1. delete

<1> log.cleanup.policy = delete 所有数据启用删除策略
<2> 基于时间：默认打开。以 segment 中所有记录中的最大时间戳作为该文件时间戳。
<3> 基于大小(log.retention.bytes)：默认关闭。超过设置的所有日志总大小，删除最早的 segment。
<4> log.retention.bytes，默认等于-1，表示无穷大。

2. compact

在这里插入图片描述
<1> log.cleanup.policy = compact 所有数据启用压缩策略
<2> compact日志压缩：对于相同key的不同value值，只保留最后一个版本。
<3> 压缩后的offset可能是不连续的，比如上图中没有6，当从这些offset消费消息时，将会拿到比这个offset大 的offset对应的消息，实际上会拿到offset为7的消息，并从这个位置开始消费。
<4> 这种策略只适合特殊场景，比如消息的key是用户ID，value是用户的资料，通过这种压缩策略，整个消息 集里就保存了所有用户最新的资料。

8. 高效读写数据

<1> kafka 本省是分布式集群，可以采用分区奇数，并行度高。
<2> 读数据采用稀疏索引，可以快速定位到要消费的数据。
<3> 顺序写磁盘
  Kafka 的 producer 生产数据，要写入到 log文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。
 在这里插入图片描述
<4> 页缓存 + 零拷贝技术
 在这里插入图片描述
  零拷贝：Kafka的数据加工处理操作交由Kafka生产者和Kafka消费者处理。Kafka Broker应用层不关心存储的数据，所以就不用 走应用层，传输效率高。
  PageCache页缓存：Kafka重度依赖底层操作系统提供的PageCache功能。当上层有写操作时，操作系统只是将数据写入 PageCache。当读操作发生时，先从PageCache中查找，如果找不到，再去磁盘中读取。实际上PageCache是把尽可能多的空闲内存都当做了磁盘缓存来使用。
 在这里插入图片描述

那时的样子_
关注
  • 0
    点赞
  • 踩
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
大数据-消息队列-Kafka(六)：Kafka Broker（集群）
u013250861的博客
04-04 352
follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉（HW之前每个节点都有，故安全），从HW开始向leader进行同步。leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件。Kafka中log日志是分成一块块存储的，此配置是指log日志划分 成块的大小，默认值1G。每隔多久，刷数据到磁盘，默认是null。
Kafka-Broker
萝卜头柯克船长的博客
06-21 785
1. 集群成员 Kafka使用Zookeeper来管理集群成员（Broker），Broker启动时通过创建临时节点将自己注册到在Zookeeper，Zookeeper会将Broker的变动信息通知给控制器。 1.1 控制器 控制器是一个Kafka集群中的一个Broker，其作用是在Zookeeper的帮助下管理和协调整个Kafka集群。 Zookeeper概述 Zookeeper是一个高可靠性的分布式协调框架，核心功能是提供了：文件系统+通知机制。 ZK在内存中以树状目录结构存储数据，保证了高吞吐量和低延
java——spring boot集成kafka——broker、主题、分区、副本——概念理解
小白龙白龙马的博客
03-26 1277
一、代理商Broker 在之前我们已经为大家介绍了生产者向消息队列中投递消息，消费者从消息队列中拉取数据。 在kafka消息队列中有一个非常重要的概念就是代理Broker，大家可以想象生活中的商品代理商是做什么的？进货、存货、销货。 kafka的代理Broker也承担着同样的作用：接收消息、保存消息、为消费者提供消息。 具体到kafka架构层面，我们可以认为一个Broker代理就是一个kaf...
Kafka - Broker 详解
Trollz的博客
10-17 9835
Kafka - Broker Details
Kafka——windows安装
胡汉三
07-06 761
下载地址：Apache Kafka下载完毕后解压tar包，目录结构如下： 配置下载完成后，需要配置一下才能启动。在config目录的server.properties文件中调整一下日志的存放目录 先启动zookeeper在bin/windows目录下的执行启动命令（最好命令行执行，因为这样才能看到错误信息，不然报错了的话就会一闪而逝...） 这是什么鬼...命令提示符行字符串限制 - Windows Client | Microsoft Docs很奇妙的限制，我们把文件的路径往前移动一下吧... 我
Kafka3.0.0版本——Broker（服役新节点）示例
小志的博客
08-09 386
Kafka3.0.0版本——Broker（服役新节点）示例
Kafka源码分析（十三）——Broker：整体架构
smart_an的专栏
06-07 678
本章，我对Broker的整体架构以及启动流程进行了讲解，Kafka Broker从整体上分为四个模块：Network Layer（网络层）、API Layer（API层）、Log Subsystem（日志子系统）、Replication SubSystem（副本子系统）。下一章开始，我将先对Network Layer（网络层）的底层源码进行分析。
Kafka3.0.0版本——Broker（Zookeeper服务端存储的Kafka相关信息）
小志的博客
08-01 1522
Kafka3.0.0版本——Broker（Zookeeper服务端存储的Kafka相关信息）
Kafka学习笔记（2）——Kafka Broker及消费者
weixin_36040866的博客
10-05 2098
记录Kafka Broker及消费者学习笔记
Kafka——性能逆天的存在
02-25
（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）。每个Topic包含一个或多个Parition;Parition是物理...
基于JAVA API方式使用Kafka——编写生产者客户端.docx
06-11
- `"batch.size"`：设置一批消息的大小（以字节为单位），达到这个大小后才会发送到 broker。 - `"linger.ms"`：指定生产者等待新消息加入批次的延迟时间，如果在此时间内有更多消息到达，则会组成更大的批次发送...
关于Kafka学习视频对照文档.zip
02-06
Kafka的核心是Producer（生产者）、Broker（代理服务器）和Consumer（消费者）。生产者负责将数据发布到特定的主题（Topic），每个主题可以分为多个分区（Partition），保证了数据的有序性和可扩展性。Broker作为...
kafka动态新增分区
07-23
- **Broker服务器地址**：对于较新版本的Kafka（如0.11.x及以上），则需要提供Broker集群的地址。 - **目标主题名称**：即您希望对其增加分区的主题名称。 - **新的分区总数**：您计划将主题分区扩展到的总数量。 #...
kafka使用教程.rar
04-02
Kafka提供了一个轻量级的流处理库——Kafka Streams，可以直接在Kafka集群上进行实时数据处理，无需额外的计算集群，简化了实时分析和应用开发。 7. **Kafka Connect** Kafka Connect是一个用于将外部系统（如...
kafka架构+原理+源码
JavaCoder_juejue的博客
07-21 1158
1.kafka架构图 2.kafka producer
Python 消费Kafka手动提交 批量存入Elasticsearch
ytp552200ytp的博客
07-25 312
Python 消费Kafka手动提交 批量存入Elasticsearch
使用hutool工具判断字符串是否全部是字母(包括大小写)，java判断字符串是否全部是字母(包括大小写)
最新发布
qq_43700885的博客
07-29 310
1.导入hutool的maven依赖。2.复制一下代码执行。
golang 接口
m0_70982551的博客
07-24 1094
接口定义了一组方法，这些方法没有具体的实现。接口类型的变量可以存储任何实现了这些方法的类型的值。// 更多方法...在Go语言中，接口值是指存储了实现某个接口的具体类型值的变量。接口值由两部分组成：1.动态类型：这是接口值当前存储的实际类型。2.动态值：这是实际存储的值，该值必须实现了接口中定义的所有方法。
Kafka 加broker
06-09
您好，这是一个IT类问题。如果您要向Kafka集群中添加broker，需要进行以下步骤： 1. 在新的服务器上安装Kafka，可以使用之前版本的相同Kafka版本。 2. 确保新服务器与Kafka集群中的其他服务器可以相互访问。 3. 在新服务器上配置Kafka Broker，包括broker.id、listeners、log.dirs等参数。可以将这些参数写入Kafka的配置文件中。 4. 将Kafka集群中的Zookeeper集群中的每个节点的zookeeper.connect参数更新为包含新服务器的地址。 5. 启动新的Kafka Broker，它将加入Kafka集群并开始接收和处理消息。 希望这可以帮助您。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值