当前位置： 首页 > wzjs >正文

网站域名是不是网址营口规划建设局网站

wzjs 2025/9/3 21:28:45
网站域名是不是网址,营口规划建设局网站,贵阳网站建设有限公司,企业信息信用信息公示网官网Kafka Broker Broker实际上就是kafka实例，每一个节点都是独立的Kafka服务器。 Zookeeper中存储的Kafka信息 节点的服役以及退役 服役 首先要重新建立一台全新的服务器105，并且在服务器中安装JDK、Zookeeper、以及Kafka。配置好基础的信息之后&#x…

Kafka Broker

Broker实际上就是kafka实例，每一个节点都是独立的Kafka服务器。

Zookeeper中存储的Kafka信息

在这里插入图片描述

节点的服役以及退役

服役

首先要重新建立一台全新的服务器105，并且在服务器中安装JDK、Zookeeper、以及Kafka。配置好基础的信息之后，再将节点加入到kafka集群之中。如果是直接拷贝配置好的主机一定要先修改主机的ip地址以及主机名，那么一定要移除kafka的broker.id并且要删除kafka安装目录下的datas以及logs下的所有文件，不然复制的主机和被复制的主机会产生冲突。

rm -rf datas/ logs/

将节点加入到kafka集群之中，只需要在105机器中的kafka安装目录下执行启动命令

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

启动之后，kafka就会将自己的broker.id注册到zookeeper中，这样就加入了kafka集群。此时虽然加入了集群，但是并没有跟101、102、103之间同步数据，相当于没有起到作用。此时需要执行负载均衡操作，让105能够和其他三台主机一起共同工作。

首先在安装目录下创建一个新文件（直接操作101主机即可）

vim topics-to-move.json

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

执行生成负载均衡计划命令，为0，1，2，3生成负载均衡计划，系统会生产一个负载均衡计划

bin/kafka-reassign-partitions.sh --bootstrap-server 192.168.27.101:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2,3" --generate

查看计划如果满足要求，那么复制计划，并新建一个文件将复制的计划粘贴到文件中

vim increase-replication-factor.json

执行副本存储计划

bin/kafka-reassign-partitions.sh --bootstrap-server 192.168.27.101:9092 --reassignment-json-file increase-replication-factor.json --execute

验证副本执行计划

bin/kafka-reassign-partitions.sh --bootstrap-server 192.168.27.101:9092 --reassignment-json-file increase-replication-factor.json --verify

此时105主机就承担了一部分的副本存储压力，此时才正式服役。

退役旧节点

退役一台节点时，直接再执行一次负载均衡计划，比如退役105主机，105的broker.id=3

首先创建文件

vim topics-to-move.json

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

执行生成负载均衡计划命令，只为0，1，2生成负载均衡计划，系统会生产一个负载均衡计划

bin/kafka-reassign-partitions.sh --bootstrap-server 192.168.27.101:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2" --generate

查看生成的计划，如果满足要求，那么复制计划，并将复制的计划粘贴到文件increase-replication-factor.json中

vim increase-replication-factor.json

执行副本存储计划

bin/kafka-reassign-partitions.sh --bootstrap-server 192.168.27.101:9092 --reassignment-json-file increase-replication-factor.json --execute

验证副本执行计划

bin/kafka-reassign-partitions.sh --bootstrap-server 192.168.27.101:9092 --reassignment-json-file increase-replication-factor.json --verify

此时105主机就可以直接停止进行退役。

副本

Kafka使用副本来提高数据可靠性，kafka默认使用一个副本，但是在生产环境中一般配置两个，保证数据可靠性。副本不是越多越好，会增加磁盘存储空间，增加网络中的数据传输，降低效率。

Kafka副本中分为Leader和Follower，Kafka生产者只会把数据发往Leader，然后Follower主动找Leader同步数据。

Kafka分区中的所有副本统称为AR(Assigned Repllicas)

AR=ISR+OSR

ISR：能够和Leader保持同步的Follower集合，ISR包含Leader本身，如果Follower长时间未向Leader发送通信请求或者同步数据，那么该Follower就会被踢出ISR。该时间阈值由replica.lag.time.max.ms参数设定，默认30s，Leader发生故障之后就会从ISR中选举新的Leader。

OSR：表示在Follower与Leader同步时，延迟过多的副本。

Leader的选举流程

在这里插入图片描述

如图所示，Leader的选举由AR中的顺序以及是否在ISR存活决定。

Follower故障处理

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

HW：所有副本中最小的LEO

实际上HW就是记录一个消息的偏移量，在这个消息之前的所有消息是Leader以及所有正常的Follower都有的消息。

在这里插入图片描述

当Followers故障时：

  1. Followers会被临时踢出ISR
  2. 这个期间Leeder和Follower会继续接收数据
  3. 当Follower恢复之后，Follower会读取本地磁盘记录的上次HW，并且将文件高于HW的部分截取掉，然后从HW开始向Leader进行同步
  4. 当重新恢复的Follower的LEO大于等于该Partiton的HW时，就代表Follower已经基本同步了Leader的数据，可以重新加入ISR
Leader故障处理

故障处理也跟LEO、HW相关

当Leader故障时：

  1. 首先将Leader踢出ISR队列，并从ISR队列选出一个新的Leader
  2. 为了保证数据在各个副本中一致（数据可能会丢失或者重复），其余的Follower各自将高于HW的部分截掉，然后从新的Leader处同步数据。
分区副本分配

Kafka会为尽量均匀的分配副本在节点上，增强数据的安全性、可靠性。但是我们可以跟之前服役和退役一样，来手动设置分区副本的分配。

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

文件存储机制

Topic是逻辑上的概念，而Partiton是物理上的概念，每个Partition对应一个log文件，该log文件中存储的是Producer生产的数据。Producer生产的数据会不断的追加到log文件末端，为防止log文件过大导致数据定位效率低下，因此Kafka采取了分片和索引机制，将每个Partition分为多个Segment。每个Segment包括，“.index"偏移量索引文件、”.log"日志文件和".timeindex"时间戳索引文件等文件，这些文件位于一个以topic名称+分区序号为命名规则的文件夹下。

在这里插入图片描述

在这里插入图片描述

如果需要查看文件内容，那么可以通过kafka的命令进行查看。

[root@centos101 first-0]# kafka-run-class.sh kafka.tools.DumpLogSegments --files ./00000000000000000000.index
Dumping ./00000000000000000000.index
offset: 0 position: 0

index为稀疏索引，大约每往log文件写入4kb数据，会往index文件写入一条索引。参数log.index.interval.bytes默认为4kb

index文件中保存的offset为相对offset，这样能确保offset的值所占空间不会过大，因此能将offset的值控制在固定大小

Kafka文件清除策略

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

  1. log.retention.hour （最低优先级）小时，默认七天
  2. log.retention.minutes 分钟
  3. log.retention.ms (最高优先级)毫秒
  4. log.retention.check.interval.ms 负责设置检查周期，隔一段时间检测是否过期，默认5分钟

日志保存时间和检查周期要进行搭配配置，不然检查周期过长就起不到效果。

Kafka提供的日志清理策略log.cleanup.policy有两种：delete以及compact两种

Delete
  1. 基于时间：默认开启，以segment中所有记录的最大时间戳作为该文件的过期时间戳，也就是segment中最晚过期的记录过期，才会清除这个segment
  2. 基于大小：默认关闭，超过设置的所有日志总大小，删除最早的segment。log.retention.bytes，默认为-1，表示无穷大
Compact

compact日志压缩：对于相同的key的不同value值，只保留最后一个版本。开启该策略只需修改log.cleanup.policy = compact.

在这里插入图片描述

Kafka高效读写数据

  • Kafka本身是分布式集群，采用分区技术，并行度高

  • 读数据采用稀疏索引，可以快速定位要消费的数据

  • 顺序写磁盘，写入log文件时是一直追加到文件的末端，使用顺序写，减少了大量磁头寻址的时间

  • 页缓存+零拷贝技术

在这里插入图片描述

http://www.dtcms.com/wzjs/564623.html

相关文章：

  • 前端网站论文广东深圳天气预报
  • 餐饮网站程序购物国外网站的建立
  • 加快建设企业门户网站建网站建设费用明细报告
  • 网站建设教程参加苏州久远网络网站的建站流程
  • 效果图网站有哪些优秀电商设计网站
  • 2345浏览器官方网站新乐市做网站
  • 宁波网站排名优化报价flash网站带后台
  • 网站产品管理模块襄阳做网站比较有实力的公司
  • 市场上网站开发价格招聘网站可以做两份简历吗
  • 网站建设需要哪些信息商城网站建设好么
  • 网站安装部署网络营销的四大要素
  • 只做传统嫁衣网站泸州高端网站建设公司
  • 网站建设的英语怎么说重庆网站建设最大
  • 太原网站建设公司排名不相关的网站做单项链接可以吗
  • 免费注册域名网站知乎wordpress修改地址
  • 桐城做网站的公司请问聊城做网站
  • 网站解析后怎么解决方法网上开店能赚钱吗
  • 建站系统源码岳阳建设银行网站
  • flash源文件网站网站更换目录名如何做301跳转
  • 网站备案依据央视新闻的新闻
  • 静态网站后台管理系统视频号下载器手机版
  • 成都做整站优化深圳龙华租房
  • 网站建站教程宁波网站建设那家好
  • wordpress主页美化做网站怎么优化
  • 如何在电商平台做好企业网站推广深圳专业网站制作公司排名
  • 西宁做网站seo品牌价值
  • 邯郸市住房和城建设局网站怎样将wordpress导出
  • 网站建设报告模板园林景观设计公司有丙级吗
  • 温州微网站公司创建一个网站要钱吗
  • 网站建设四川wordpress大改动