| |
|
开发:
C++知识库
Java知识库
JavaScript
Python
PHP知识库
人工智能
区块链
大数据
移动开发
嵌入式
开发工具
数据结构与算法
开发测试
游戏开发
网络协议
系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程 数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁 |
-> 大数据 -> kafka测试方案 -> 正文阅读 |
|
[大数据]kafka测试方案 |
1引言数据中台因业务需要将要引入开源框架kafka。 本文主要内容为kafka接入数据中台的技术验证预案和实施建设预案。 2验证预案2.1性能验证验证kafka的高吞吐率,主要验证producer和consumer的发送和消费吞吐率。 使用kafka manager 监控。 发送量测试测试环境设定:broker集群(3节点),topic(1个),partition(3节点*2),replication(3)。 1、在borker不变的情况下,producer数量变化,测试多个producer发送消息的吞吐性能。 2、在borker不变的情况下,producer数量不变,消息数量变化,测试多个producer发送消息的吞吐性能。 3、在borker不变的情况下,producer数量不变,消息大小变化,测试多个producer发送消息的吞吐性能。 4、在borker不变的情况下,producer数量不变,partition数量变化,测试多个producer发送消息的吞吐性能。 5、在borker不变的情况下,producer数量不变,replication变化,测试多个producer发送消息的吞吐性能。 6、同时挂载producer和consumer,测试发送消息和消费消息的吞吐性能 7、在borker数量变化的情况下,测试发送消息和消费消息的吞吐性能。 结论预设:随着producer数量的增加,每秒总的消息量会增加。随着消息变大,每秒总的消息量会增加。partition越多,在某阈值范围内,吞吐率提高。replication越大,吞吐率下降。 消费量测试测试环境设定:broker集群(3节点),topic(1个),partition(3节点*2),replication(3)????? 。 1、在borker不变的情况下,consumer数量变化,测试多个consumer接收消息的消费性能。 2、在borker不变的情况下,consumer数量不变,消息数量变化,测试多个consumer接收消息的吞吐性能。 3、在borker不变的情况下,consumer数量不变,消息大小变化,测试多个consumer接收消息的吞吐性能。 4、在borker不变的情况下,consumer数量不变,partition数量变化,测试多个consumer接收消息的吞吐性能。 5、在borker不变的情况下,consumer数量不变,replication变化,测试多个consumer接收消息的吞吐性能。 6、同时挂载producer和consumer,测试发送消息和消费消息的吞吐性能 7、在borker数量变化的情况下,测试发送消息和消费消息的吞吐性能。 结论预设:随着consumer数量的增加,消息消费的速度会越快。 broker容量测试关闭consumer,通过producer发送海量数据到broker,测试broker的容量承载能力。 异步消息测试配置消息异步发送,按照吞吐率测试方案测试producer和consumer的吞吐性能。 配置消息异步发送,查看数据丢失情况。 同步消息测试配置消息同步发送,按照吞吐率测试方案测试producer和consumer的吞吐性能。 配置消息同步发送,查看数据丢失情况。 消息重发测试测试broker进程异常状态下,producer和consumer的消息重发机制。 offset相关测试修改offset后,会产生消息重复、丢失、乱序等情况,具体进行测试。 partition方式测试设定partition分配的方式,随机或者hash,来测试具体情况 压缩比测试分别设定不同的压缩算法,GZIP, Snappy, LZ4,再次进行上述吞吐率的测试。 zookeeper下线测试zookeeper节点下线后,测试kafka集群的稳定情况。 网络带宽占用测试容错测试满负荷测试加大producer和consumer的数量及数据量,直至主机资源消耗的70%以上,观察运行时间长度。 崩溃测试加大producer和consumer的数量及数据量,直至主机资源耗尽。 断网断电测试断网断电测试broker的数据丢失情况。 2.2功能验证验证kafka提供的各种功能。 生产消息编写producer发送消息。 消费消息编写consumer消费消息。 主题管理测试topic的创建、更新、删除等管理功能。 分区管理测试partition的添加、删除等管理功能。 测试topic与多个partition关联后的管理功能。 日志管理测试集群报错后,kafka提供的日志报错功能。 集群监控测试kafka manager对集群metrics的监控功能,集群状态、topic、partition、replica、consumer group、log等。 2.3集群验证对kafka集群进行架构验证 新增节点新增节点后,kafka集群的运行情况。 删除节点删除节点后,kafka集群的运行情况。 zookeeper下线删除zookeeper节点后,kafka集群的运行情况。 断网测试断网后,kafka集群的运行情况。 断网再接入网络后,kafka集群的运行情况。 断电测试断电重启后,kafka集群的运行情况。 3实施预案kafka接入数据中台,需要从如下方面准备: 架构设计? 如上图所示,kafka按分布式集群方案部署后,需要在应用系统端定制producer来采集数据,在数据中台端定制consumer来往中台写入数据。 容量规划从数据流转、存储的角度,搞清楚数据采集端的数据容量、broker集群的数据容量、数据消费端的数据容量。 首先需要搞清楚如下情况: 有哪些数据要接入 数据所在物理位置 数据存储的应用软件 每个producer的部署位置 每个producer的部署环境 每个producer采集数据的安全权限 每个producer采集数据的频度 每个producer的资源消耗(主机、带宽) 每个consumer group个数 每个consumer group中consumer的个数 每个consumer连接中台的技术接口 每个consumer访问中台的权限 每个consumer的部署位置 每个consumer对中台资源的消耗 其他 总之要汇总得出如下结论: producer的数量 producer的位置 producer的日数据总量 producer的并发量 producer的并发数据量 producer资源配置(cpu、内存、硬盘、带宽) borker集群个数 broker集群资源配置(cpu、内存、硬盘、带宽) broker日数据量峰值 broker日存储最大数据量 topic数量 topic配置 topic关联partition的数量 replica配置量 consumer group的数量 每个consumer group中consumer的数量 每个consumer对接中台的接口 每个consumer对接中台权限 consumer日消费数据总量 consumer消费数据的并发量 consumer消费数据的并发数据量 consumer资源配置(cpu、内存、硬盘、带宽) 其他 数据采集在应用系统端,定制并部署producer,用来采集数据。 producer对接应用系统。 producer采集应用数据到broker。 producer在应用系统测部署运维。 broker部署依据容量规划,规划broker集群的部署位置、资源配置、主机规划、带宽要求等。 写入中台在数据中台端,定制并部署consumer,往中台写入数据。 consumer对接数据中台。 consumer消费数据到数据中台。 consumer在数据中台测部署运维。 技术培训需要协调应用系统开发商和数据中台开发商,共同分析需求,定制producer和consumer。 对接应用系统开发商,编写producer。 对接数据中台开发商,编写consumer。 日常运维运维团队通过kafka manager运维kafka集群,改造manager,能够自动预警、报警。 运维团队直接运维producer。 运维团队直接运维consumer。 附:产品分析概念分析产品定义Kafka是一种高吞吐量、分布式、基于发布/订阅的消息系统,最初由LinkedIn公司开发,使用Scala 语言编写。目前是Apache组织的开源项目。 kafka主要概念组件如下: 1、 broker:Kafka服务器,负责消息存储和转发。 2、 topic:消息主题,Kafka按照topic来分类消息。 3、 partition:topic的分区,一个topic可以包含多个partition,topic消息保存在各个partition 上。 4、 offset:消息在日志中的位置,可以理解是消息在partition 上的偏移量,也是代表该消息的唯一序号。 5、 Producer:消息生产者。 6、 Consumer:消息消费者。 7、 Consumer Group:消费者分组,每个Consumer 必须属于一个group。 8、 Zookeeper:保存着集群broker、topic、partition 等meta 数据;另外还负责broker 故障发现,partition leader 选举,负载均衡等功能。 工作机制Kafka基于分布式高可用的borker提供强大的数据缓冲能力,producer对接数据源采集数据,并将数据发送到broker上,数据就在borker上缓存下来,直到consumer消费完数据为止。 Kafka基于分布式架构提供高容错功能,基于offset记录已经处理过的数据,消息写入topic有顺序,consumer记录自己的offset,topic数据存储在分区上,分区有副本,分布在不同节点上。 Kafka使用producer写入数据时,启用批次写入,这样可以避免在网络上频繁传输单个消息带来的延迟和带宽开销。假设网络带宽为10MB/S,一次性传输10MB的消息比传输1KB的消息10000万次显然要快得多。 Kafka提供consumer group概念。某些topic拥有数百万甚至数千万的消息量,如果仅仅靠单个消费者消费,那么消费速度会非常慢,所以我们需要使用消费组功能,同一个消费组的多个消费者就能分布到多个物理机器上以加速消费。每个消费者组都会有一个独一无二的消费者组id来标记自己。每一个消费者group可能有一个或者多个消费者,对于当前消费组来说,topic中每条数据只要被消费组内任何一个消费者消费一次,那么这条数据就可以认定被当前消费组消费成功。 Kafka虽然是基于磁盘做的数据存储,但却具有高性能、高吞吐、低延时的特点,其吞吐量动辄几万、几十上百万。Kafka是将消息记录持久化到本地磁盘中的,一般人会认为磁盘读写性能差,可能会对Kafka性能如何保证提出质疑。实际上不管是内存还是磁盘,快或慢关键在于寻址的方式,磁盘分为顺序读写与随机读写,内存也一样分为顺序读写与随机读写。基于磁盘的随机读写确实很慢,但磁盘的顺序读写性能却很高,一般而言要高出磁盘随机读写三个数量级,一些情况下磁盘顺序读写性能甚至要高于内存随机读写。 磁盘的顺序读写是磁盘使用模式中最有规律的,并且操作系统也对这种模式做了大量优化,Kafka就是使用了磁盘顺序读写来提升的性能。Kafka的message是不断追加到本地磁盘文件末尾的,而不是随机的写入,这使得Kafka写入吞吐量得到了显著提升 。 Kafka的message是按topic分类存储的,topic中的数据又是按照一个一个的partition即分区存储到不同broker节点。每个partition对应了操作系统上的一个文件夹,partition实际上又是按照segment分段存储的。这也非常符合分布式系统分区分桶的设计思想。 ?通过这种分区分段的设计,Kafka的message消息实际上是分布式存储在一个一个小的segment中的,每次文件操作也是直接操作的segment。为了进一步的查询优化,Kafka又默认为分段后数据文件建立了索引文件,就是文件系统上index文件。这种分区分段+索引的设计,不仅提升了数据读取的效率,同时也提高了数据操作并行度。 消费组有如下三个特征: 1、每个消费组有一个或者多个消费者。 2、每个消费组拥有一个唯一性的标识id。 3、消费组在消费topic的时候,topic的每个partition只能分配给一个消费者。 Kafka的producer和consumer通常需要定制,所以对接各种数据源不灵活、不方便。 Kafka利用了操作系统本身的Page Cache,就是利用操作系统自身的内存而不是JVM空间内存。相比于使用JVM或in-memory cache等数据结构,利用操作系统的Page Cache更加简单可靠。首先,操作系统层面的缓存利用率会更高,因为存储的都是紧凑的字节结构而不是独立的对象。其次,操作系统本身也对于Page Cache做了大量优化,提供了 write-behind、read-ahead以及flush等多种机制。再者即使服务进程重启,系统缓存依然不会消失,避免了in-process cache重建缓存的过程。 ? ? ? 通过操作系统的Page Cache,Kafka的读写操作基本上是基于内存的,读写速度得到了极大的提升。?linux操作系统 “零拷贝” 机制使用了sendfile方法,允许操作系统将数据从Page Cache 直接发送到网络,只需要最后一步的copy操作将数据复制到 NIC 缓冲区,这样避免重新复制数据 。通过这种 “零拷贝” 的机制,Page Cache 结合 sendfile 方法,Kafka消费端的性能也大幅提升。这也是为什么有时候消费端在不断消费数据时,我们并没有看到磁盘io比较高,此刻正是操作系统缓存在提供数据。零拷贝并非指一次拷贝都没有,而是避免了在内核空间和用户空间之间的拷贝。 Kafka数据读写是批量的而不是单条的。除了利用底层的技术外,Kafka还在应用程序层面提供了一些手段来提升性能。最明显的就是使用批次。在向Kafka写入数据时,可以启用批次写入,这样可以避免在网络上频繁传输单个消息带来的延迟和带宽开销。 ?? ?? 在很多情况下,系统的瓶颈不是CPU或磁盘,而是网络IO,对于需要在广域网上数据中心之间发送消息的数据流水线尤其如此。进行数据压缩会消耗少量CPU资源,不过对于kafka而言,网络IO更应该需要考虑。如果每个消息都压缩,但是压缩率相对很低,所以Kafka使用了批量压缩,即将多个消息一起压缩而不是单个消息压缩 Kafka允许使用递归的消息集合,批量的消息可以通过压缩的形式传输并且在日志中也可以保持压缩格式,直到被消费者解压缩。Kafka支持多种压缩协议,包括Gzip和Snappy压缩协议。Kafka速度的秘诀在于,它把所有的消息都变成一个批量的文件,并且进行合理的批量压缩,减少网络IO损耗,通过mmap提高I/O速度,写入数据的时候由于单个Partion是末尾添加所以速度最优;读取数据的时候配合sendfile直接暴力输出。 数据存储partition 的数据文件(offset,MessageSize,data) partition 中的每条Message 包含了以下三个属性:offset,MessageSize,data,其中offset 表示Message 在这个partition 中的偏移量,offset 不是该Message 在partition 数据文件中的实际存储位置,而是逻辑上一个值,它唯一确定了partition 中的一条Message,可以认为offset 是partition 中Message 的id;MessageSize 表示消息内容data 的大小;data 为Message 的具体内容。 数据文件分段segment(顺序读写、分段命令、二分查找) partition 物理上由多个segment 文件组成,每个segment 大小相等,顺序读写。每个segment数据文件以该段中最小的offset 命名,文件扩展名为。log。这样在查找指定offset 的Message 的时候,用二分查找就可以定位到该Message 在哪个segment 数据文件中。 数据文件索引(分段索引、稀疏存储) Kafka为每个分段后的数据文件建立了索引文件,文件名与数据文件的名字是一样的,只是文件扩展名为。index。index 文件中并没有为数据文件中的每条Message 建立索引,而是采用了稀疏存储的方式,每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间,从而可以将索引文件保留在内存中。 生产者负载均衡(partition 会均衡分布到不同broker 上) 由于消息topic由多个partition 组成,且partition 会均衡分布到不同broker 上,因此,为了有效利用broker 集群的性能,提高消息的吞吐量,producer 可以通过随机或者hash 等方式,将消息平均发送到多个partition 上,以实现负载均衡。 批量发送 是提高消息吞吐量重要的方式,Producer 端可以在内存中合并多条消息后,以一次请求的方式发送了批量的消息给broker,从而大大减少broker 存储消息的IO 操作次数。但也一定程度上影响了消息的实时性,相当于以时延代价,换取更好的吞吐量。 压缩(GZIP 或Snappy) Producer 端可以通过GZIP 或Snappy 格式对消息集合进行压缩。Producer 端进行压缩之后,在Consumer 端需进行解压。压缩的好处就是减少传输的数据量,减轻对网络传输的压力,在对大数据处理上,瓶颈往往体现在网络上而不是CPU(压缩和解压会耗掉部分CPU 资源)。 消费者Consumer Group 同一Consumer Group 中的多个Consumer 实例,不同时消费同一个partition,等效于队列模式。partition 内消息是有序的,Consumer 通过pull 方式消费消息。Kafka不删除已消费的消息对于partition,顺序读写磁盘数据,以时间复杂度O(1)方式提供消息持久化能力。 与flume在生产环境中,一般将Flume和Kafka搭配使用,Flume采集kafka缓冲,来完成实时流式的数据处理。 1、生产环境中,往往是读取日志进行分析,而这往往是多数据源的,如果Kafka构建多个生产者使用文件流的方式向主题写入数据再供消费者消费的话,无疑非常的不方便。 ?????? 2、如果Flume直接对接实时计算框架,当数据采集速度大于数据处理速度,很容易发生数据堆积或者数据丢失,而kafka可以当做一个消息缓存队列,从广义上理解,把它当做一个数据库,可以存放一段时间的数据。 ?????? 3、Kafka属于中间件,一个明显的优势就是使各层解耦,使得出错时不会干扰其他组件。 ?????? 4、Kafka与Flume都可以通过配置保证数据不丢失。但是,Flume不会复制消息,因此即使使用可靠的文件渠道,当Flume进程宕机后,你就无法访问这些消息了。当然Flume进程重启,从磁盘上恢复之前状态后,可以继续对消息进行处理。因此如果对 HA高可用性具有很高要求,建议使用Kafka; ?????? 另外Flume常用的场景是:直接将数据写入存储,如hadoop或habase中。Flume对HDFS/HBase具有更好的优化,同时它也集成了Hadoop安全组件。如果数据需要被多个应用程序处理,建议Kafka;如果数据主要是用于Hadoop,建议Flume; ?????? 另外如果希望将Kafka上的数据导入Hadoop,可以启动一个内置Kafka源与Hadoop槽的Flume进程。这样就不需要去实现自定义的消费者,同时还可以得到Flume对HDFS/HBase优化带来的好处。 集群安装规划: cancer01 ????? 1 cancer02 ????? 2 cancer03 ????? 3 说明1:在cancer01主机上配置好kafka目录后,复制到其他主机再修改下即可。 说明2:每台主机上都要安装zookeeper,配置好zookeeper集群。 解压: tar -xzvf kafka_2.13-2.7.0.tgz mv kafka_2.13-2.7.0 /usr/local/kafka 更改所有者 chown -R hadoop:hadoop /usr/local/kafka 配置环境 vim /etc/profile export KAFKA_HOME=/usr/local/kafka export PATH=$PATH:$KAFKA_HOME/bin source /etc/profile 修改配置文件 (broker.id和host.name每台主机不相同) vim /usr/local/kafka/conf/server.properties
说明:listeners一定要配置成为IP地址;如果配置为localhost或服务器的hostname,在使用java发送数据时就会抛出异常.因为在没有配置advertised.host.name的情况下,Kafka并没有像官方文档宣称的那样改为广播我们配置的host.name,而是广播了主机配置的hostname。远端的客户端并没有配置hosts,所以自然是连接不上这个hostname的。当使用java客户端访问远程的kafka时,一定要把集群中所有的端口打开,否则会连接超时 vim /usr/local/kafka/conf/producer.properties
vim /usr/local/kafka/conf/consumer.properties
分发到其他主机 scp -r /usr/local/kafka cancer02:/usr/local/ scp -r /usr/local/kafka cancer03:/usr/local/ 修改其他主机配置 vim /etc/profile vim /usr/local/kafka/conf/server.properties 启动zookeeper zkServer.sh start zkServer.sh status 启动kafka kafka-server-start.sh $KAFKA_HOME/config/server.properties 1>/dev/null 2>&1 & kafka-server-start.sh ../config/server.properties 1>/dev/null 2>&1 & 或者 kafka-server-start.sh -daemon $KAFKA_HOME/config/server.properties 1>/dev/null 2>&1 & kafka-server-start.sh -daemon ../config/server.properties 1>/dev/null 2>&1 & 或者 nohup kafka-server-start.sh ../config/server.properties &>> /usr/local/kafka/kafka.log & 验证 创建topic kafka-topics.sh --create --zookeeper cancer01:2181 --replication-factor 1 --partitions 1 --topictest 查看topic是否创建成功 kafka-topics.sh --list -zookeeper cancer01:2181 产品使用创建一个名为“test”的Topic,只有一个分区和备份 kafka-topics.sh --create --zookeeper cancer01:2181,cancer02:2181,cancer03:2181 --config max.message.bytes=12800000 --config flush.messages=1 --replication-factor 1 --partitions 1 --topictest kafka-topics.sh --create --zookeeper cancer01:2181,cancer02:2181,cancer03:2181 --replication-factor 3 --partitions 3 --topictest 命令解析: --create: ????????? 指定创建topic动作 --topic: ?????????? 指定新建topic的名称 --zookeeper: ??? 指定kafka连接zk的连接url,该值和server.properties文件中的配置项{zookeeper.connect}一样 --config: ????????? 指定当前topic上有效的参数值 --partitions:指定当前创建的kafka分区数量,默认为1个 --replication-factor:指定每个分区的复制因子个数,默认1个 查看已创建的topic信息 kafka-topics.sh --list --zookeeper localhost:2181 查看topic描述信息 kafka-topics.sh --describe –zookeeper localhost:2181 --topictest 命令解析: --describe: 指定是展示详细信息命令 --zookeeper: 指定kafka连接zk的连接url,该值和server.properties文件中的配置项{zookeeper.connect}一样 --topic:指定需要展示数据的topic名称 为topic增加副本 kafka-reassign-partitions.sh -zookeeper cancer01:2181,cancer02:2181,cancer03:2181 -reassignment-json-file json/partitions-to-move.json -execute? 为topic增加partition kafka-topics.sh –zookeeper cancer01:2181,cancer02:2181,cancer03:2181 –alter –partitions 20 –topictest 修改Topic信息 kafka-topics.sh --zookeeper cancer01:2181,cancer02:2181,cancer03:2181 --alter --topictest --config max.message.bytes=128000 kafka-topics.sh --zookeeper cancer01:2181,cancer02:2181,cancer03:2181 --alter --topictest --delete-config max.message.bytes kafka-topics.sh --zookeeper cancer01:2181,cancer02:2181,cancer03:2181 --alter --topictest --partitions 10 kafka-topics.sh --zookeeper cancer01:2181,cancer02:2181,cancer03:2181 --alter --topictest --partitions 3 ## Kafka分区数量只允许增加,不允许减少 删除Topic 默认情况下Kafka的Topic是没法直接删除的,删除是标记删除,没有实际删除这个Topic;如果运行删除Topic,两种方式: ?????? 方式一:通过delete命令删除后,手动将本地磁盘以及zk上的相关topic的信息删除即可 ????? 方式二:配置server.properties文件,给定参数delete.topic.enable=true,重启kafka服务,此时执行delete命令表示允许进行Topic的删除 kafka-topics.sh --delete --topictest --zookeeper cancer01:2181,cancer02:2181,cancer03:2181 kafka-run-class.sh kafka.admin.DeleteTopicCommand --topictest --zookeeper cancer01:2181,cancer02:2181,cancer03:2181 你可以通过命令:./bin/kafka-topics --zookeeper 【zookeeper server】 --list ??来查看所有topic 此时你若想真正删除它,可以如下操作: (1)登录zookeeper客户端:命令:./bin/zookeeper-client (2)找到topic所在的目录:ls /brokers/topics (3)找到要删除的topic,执行命令:rmr /brokers/topics/【topicname】即可,此时topic被彻底删除. 另外被标记为marked for deletion的topic你可以在zookeeper客户端中通过命令获得:ls /admin/delete_topics/【topicname】, 如果你删除了此处的topic,那么marked for deletion 标记消失 发送消息 Kafka提供了一个命令行的工具,可以从输入文件或者命令行中读取消息并发送给Kafka集群.每一行是一条消息. kafka-console-producer.sh --broker-list cancer01:9092,cancer02:9092,cancer03:9092 --topictest 消费消息 Kafka也提供了一个消费消息的命令行工具,将存储的信息输出出来. kafka-console-consumer.sh --bootstrap-server cancer01:9092,cancer02:9092,cancer03:9092 --topictest --from-beginning (--from-beginning如果去掉不会出现消费者启动之前的消息) 下线broker kafka-run-class.sh kafka.admin.ShutdownBroker --zookeeper cancer01:2181,cancer02:2181,cancer03:2181 --broker #brokerId# --num.retries 3 --retry.interval.ms 60 shutdown broker 查看consumer组内消费的offset kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --zookeeper cancer01:2181,cancer02:2181,cancer03:2181 --group test --topic test 创建topic,备份3份 kafka-topics.sh --create --zookeeper cancer01:2181,cancer02:2181,cancer03:2181 --replication-factor 3 --partitions 1 --topicmy-replicated-topic 查看topic运行情况 kafka-topics.sh --describe --zookeeper localhost:2181 --topicmy-replicated-topic //所有分区的摘要 Topic:my-replicated-topic?? PartitionCount:1??? ReplicationFactor:3??? Configs: #提供一个分区信息,因为我们只有一个分区,所以只有一行. Topic: my-replicated-topic?? Partition: 0??? Leader: 1??? Replicas: 1,2,0??? Isr: 1,2,0 #“leader”:该节点负责该分区的所有的读和写,每个节点的leader都是随机选择的. #“replicas”:备份的节点列表,无论该节点是否是leader或者目前是否还活着,只是显示. #“isr”:“同步备份”的节点列表,也就是活着的节点并且正在同步leader 其中Replicas和Isr中的1,2,0就对应着3个broker他们的broker.id属性 干掉leader,测试集群容错 ??首先查询谁是leader kafka-topics.sh --describe --zookeeper localhost:2181 --topicmy-replicated-topic //所有分区的摘要 Topic:my-replicated-topic?? PartitionCount:1??? ReplicationFactor:3??? Configs: //提供一个分区信息,因为我们只有一个分区,所以只有一行. Topic: my-replicated-topic?? Partition: 0??? Leader: 1??? Replicas: 1,2,0??? Isr: 1,2,0 可以看到Leader的broker.id为1,找到对应的Broker [root@administrator bin]# jps -m 5130 Kafka../config/server.properties 4861 QuorumPeerMain ../config/zookeeper.properties 1231 Bootstrap start start 7420 Kafka../config/server-2.properties 7111 Kafka../config/server-1.properties 9139 Jps -m 查询到Leader的PID(Kafka../config/server-1.properties)为7111,杀掉该进程 //杀掉该进程 kill -9 7111 //再查询一下,确认新的Leader已经产生,新的Leader为broker.id=0 ./kafka-topics.sh --describe --zookeeper localhost:2181 --topicmy-replicated-topic Topic:my-replicated-topic????? PartitionCount:1??????? ReplicationFactor:3??? Configs: //备份节点之一成为新的leader,而broker1已经不在同步备份集合里了 Topic: my-replicated-topic???? Partition: 0??? Leader: 0?????? Replicas: 1,0,2 Isr: 0,2 再次消费消息,确认消息没有丢失 ./kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topicmy-replicated-topic cluster message 1 cluster message 2 消息依然存在,故障转移成功!! Producer生产者 发送消息的方式,只管发送,不管结果:只调用接口发送消息到 Kafka服务器,但不管成功写入与否.由于 Kafka是高可用的,因此大部分情况下消息都会写入,但在异常情况下会丢消息 同步发送:调用 send() 方法返回一个 Future 对象,我们可以使用它的 get() 方法来判断消息发送成功与否 异步发送:调用 send() 时提供一个回调方法,当接收到 broker 结果后回调此方法
自定义分区分配器:决定消息存放在哪个分区..默认分配器使用轮询存放,轮到已满分区将会写入失败.
Kafka消费者(组) * 自动提交位移 * 手动同步提交当前位移 * 手动异步提交当前位移 * 手动异步提交当前位移带回调 * 混合同步与异步提交位移
|
|
|
上一篇文章 下一篇文章 查看所有文章 |
|
开发:
C++知识库
Java知识库
JavaScript
Python
PHP知识库
人工智能
区块链
大数据
移动开发
嵌入式
开发工具
数据结构与算法
开发测试
游戏开发
网络协议
系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程 数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁 |
360图书馆 购物 三丰科技 阅读网 日历 万年历 2024年11日历 | -2024/11/22 23:31:06- |
|
网站联系: qq:121756557 email:121756557@qq.com IT数码 |