大数据_Kafka_Kafka自动创建不存在的Topics / 删除已存在的Topics 2016年10月11日 18:22:59 高达一号 阅读数:8655   版权声明:本文为博主原创文章,未经博主允许不得转载. https://blog.csdn.net/u010003835/article/details/52790378 对于Kafka. 可以在配置中配置自动创建Topic, 即对于 consumer , producer  连接的 Topics 达到自动创建的效果,不需要通过命令进行

Kafka发送消息方法如下: Properties properties = new Properties(); properties.put("zookeeper.connect", "server1:2181"); properties.put("serializer.class",StringEncoder.class.getName()); properties.put("metadata.broker.list",&

问题现象 RocketMQ3.2.2版本,测试时尝试发送消息时自动创建Topic,设置了队列数量为8: producer.setDefaultTopicQueueNums(8); 同时设置broker服务器的配置文件broker.properties: defaultTopicQueueNums=16 但实际创建后从控制台及后台打印代码观察到该Topic只创建了4个队列,反复重试确认发送消息时自动创建Topic,最大创建4个队列. 查找原因 服务端与客户端配置对比 阅读源码,在TopicConf

修改分区个数: ./kafka-topics./kafka/<id_of_kafka> --alter --partitions 10 --topic test_topic 上面命令将test_topic对应的分区数目调整为10个,127.0.0.1是zookeeper的地址,2181是zookeeper端口. 删除topic ./kafka-topics./kafka/<id_of_kafka> --delete --topic test_topic 上面命令将主题test_to

转载请注明出处:http://www.cnblogs.com/xiaodf/ 创建kafka topic 查看所有topic列表 查看指定topic信息 控制台向topic生产数据 控制台消费topic的数据 查看topic某分区偏移量最大(小)值 增加topic分区数 删除topic,慎用,只会删除zookeeper中的元数据,消息文件须手动删除 创建kafka topic bin/kafka-topics.sh --zookeeper node01:2181 --create --topic

1. 前言 按照我自己设计的物联网框架,对于MQTT集群中的所有消息,是要持久化到磁盘的,这里采用一个消息队列中间件Kafka作为数据缓冲,缓冲结果存到数据仓库中,以供后续作为数据分析.由于MQTT集群中的消息都是比较分散的,所以使用Kafka来聚合.采集消息. 2. 下载&编译&安装 Kafka依赖ZooKeeper 在这里下载 http://mirrors.shuosc.org/apache/zookeeper/zookeeper-3.4.11/zookeeper-3.4.11.tar

Topic在逻辑上可以被认为是一个queue队列,每条消息都必须指定它的topic,可以简单理解为必须指明把这条消息放进哪个queue里.为 了使得Kafka的吞吐率可以水平扩展,物理上把topic分成一个或多个partition,每个partition在物理上对应一个文件夹,该文件夹 下存储这个partition的所有消息和索引文件. 每个日志文件都是“log entries”序列,每一个log entry包含一个4字节整型数(值为N),其后跟N个字节的消息体.每条消息都有一个当前partit

准备工作 1.安装kafka+zookeeper环境 2.利用命令创建好topic,创建一个topic my-topic 集成步骤 1.配置生产者 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSc

首先说结论,是负载均衡的.也就是说,现在有一个producer,向一个主题下面的三个分区发送message,没有指定具体要发送给哪个partition, 这种情况,如果是负载均衡的,发送的消息应该均匀分布在三个分区的日志文件中. 下面开始验证: 首先创建一个带三个分区的topic, my-partitioned-topic. bin\windows\kafka-topics --create -zookeeper localhost: --replication-factor --partiti

https://bbs.huaweicloud.com/blogs/112956 版权归PUMA项目组所有,转载请声明,多谢. kakfa大规模集群能力在前面已给大家分享过,kafka作为消息总线,在支撑云千万tps上千节点的集群能力非常出色,本文继续对业界关于单机多topic的性能瓶颈点问题(比如:https://yq.aliyun.com/articles/62832?spm=5176.100239.blogcont25379.8.KMUH1L),国内某云使用RocketMQ,性能对比唱衰k

在大数据整个处理流程过程中,数据的流向是一个很重要的问题,本篇博客主要记录数据是怎么从http发送到kafka的. 使用技术点: 1. java的Vert.x框架 (关于java框架Vert.x的使用示例请移步:http://www.programcreek.com/java-api-examples/index.php?api=io.vertx.core.Vertx) 2. KafkaProducer 的使用 (使用示例移步:http://www.programcreek.com/java-a

转自:http://blog.csdn.net/jewes/article/details/42970799 引言 Kafka中的Message是以topic为基本单位组织的,不同的topic之间是相互独立的.每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的),每个partition存储一部分Message.借用官方的一张图,可以直观地看到topic和partition的关系. partition是以文件的形式存储在文件系统中

1. acks=0 意味着生产者能够通过网络吧消息发送出去,那么就认为消息已成功写入Kafka 一定会丢失一些数据 2. acks=1 意味着首领在疏导消息并把它写到分区数据问津是会返回确认或者错误响应,还是可能会丢数据 3. acks=all 意味着首领在返回确认或错误响应之前,会等待所有同步副本都收到消息.如果和min.insync.replicas参数结合起来,,就可以决定在返回确认前至少有多个副本能够收到消息.但是效率较低.可以通过一部模式和更大的批次来加快速度,但这样做会降低吞吐量

原文 https://www.cnblogs.com/dorothychai/p/6181058.html 引言 Kafka中的Message是以topic为基本单位组织的,不同的topic之间是相互独立的.每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的),每个partition存储一部分Message.借用官方的一张图,可以直观地看到topic和partition的关系. partition是以文件的形式存储在文件系统中,

前段时间在Kafka QQ群中有人问及此事——关于Java consumer如何动态修改topic订阅的问题.仔细一想才发现这的确是个好问题,因为如果简单地在另一个线程中直接持有consumer实例然后调用subscribe进行修改,consumer端必然会抛出异常ConcurrentModificationException:KafkaConsumer is not safe for multi-threaded access 和KafkaProducer不同的是,KafkaConsumer不

删除Topic 1. 显示所有Topic信息,testTopic是我们将要删除的Topic 2. 首先确认server.properties下面配置是否已经加上delete.topic.enable=true 3. 我们来验证是否test topic已经被真正的删除了. a. 验证Kafka log: b. 验证Zookeeper 连接Zookeeper zkCli.sh -server hadoop1:2181,hadoop2:2181,hadoop3:2181 ls /brokers/top

最近开发一cdc框架,为了测试极端情况,需要kafka传递100万条数据过去,1个G左右,由于其他环节限制,不便进行拆包(注:测下来,大包走kafka不一定性能更好,甚至可能更低). 测试百万以上的变更数据时,报消息超过kafka broker允许的最大值,因此需要修改如下参数,保证包能够正常发送: socket.request.max.bytes=2147483647    # 设置了socket server接收的最大请求大小log.segment.bytes=2147483647     

1:如果在一个Flume Agent中同时使用Kafka Source和Kafka Sink来处理events,便会遇到Kafka Topic覆盖问题,具体表现为,Kafka Source可以正常从指定的Topic中读取数据,但在Kafka Sink中配置的目标Topic不起作用,数据仍然会被写入到Source中指定的Topic中. 2:Kafka Topic覆盖问题解决方案,利用flume的拦截器 #拦截器处理,topic覆盖问题 agent_log.sources.kafka0.interc

删除topic 首先需要设置server.properties,最后一行添加 delete.topic.enable=true 然后运行> ./kafka-topics.sh --zookeeper node4:2181,node3:2181 --delete --topic topic1

The partition reassignment tool can be used to move some topics off of the current set of brokers to the newly added brokers. This is typically useful while expanding an existing cluster since it is easier to move entire topics to the new set of brok

1. 操作命令 bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 3 --topic test 2. 原理 topic创建主要分为两个部分:命令行部分+后台(controller)逻辑部分,如下图所示. 主要的思想就是后台逻辑会监听zookeeper下对应的目录节点,一旦发起topic创建命令,该命令会创建新的数据节点从而触发后台的创建逻辑. leader选举:简