环境 本文中的操作均基于kafka_1.3.3.0,且所有命令经过实际验证. 常用工具 新建Topic ./kafka-topics --zookeeper 166.188.xx.xx --create --topic flink_source --partitions 1 --replication-factor 1 replication-factor: 指定副本数量 partitions:指定分区 删除Topic ./kafka-topics --zookeeper 166.188.xx.

启动zookeeper和Kafka之后,进入kafka目录(安装/启动kafka参考前面一章:https://www.cnblogs.com/cici20166/p/9425613.html) 1.创建Topic 1)运行命令: ./bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test1 2181 是zookeeper 端口 图示为创建成

前言:删除kafka topic及其数据,严格来说并不是很难的操作.但是,往往给kafka 使用者带来诸多问题.项目组之前接触过多个开发者,发现都会偶然出现无法彻底删除kafka的情况.本文总结多个删除kafka topic的应用场景,总结一套删除kafka topic的标准操作方法. step1:如果需要被删除topic 此时正在被程序 produce和consume,则这些生产和消费程序需要停止.因为如果有程序正在生产或者消费该topic,则该topic的offset信息一致会在broker

消费者要从头开始消费某个topic的全量数据,需要满足2个条件(spring-kafka): (1)使用一个全新的"group.id"(就是之前没有被任何消费者使用过); (2)指定"auto.offset.reset"参数的值为earliest: 对应的spring-kafka消费者客户端配置参数为: <!-- 指定消费组名 --> <entry key="group.id" value="fg11"/&g

转载自 huxihx,原文链接 Kafka 如何读取offset topic内容 (__consumer_offsets) 众所周知,由于Zookeeper并不适合大批量的频繁写入操作,新版Kafka已推荐将consumer的位移信息保存在Kafka内部的topic中,即__consumer_offsets topic,并且默认提供了kafka_consumer_groups.sh脚本供用户查看consumer信息. 不过依然有很多用户希望了解__consumer_offsets topic内部

Topic 的配置与组成 之前我们仅主要介绍了Kafka Producer与Kafka Consumer 的相关配置,而未详细介绍过有关topic的配置.Topic的配置在Kafka 使用中也至关重要,因为它的参数足以影响集群性能以及topic 的行为. 在一个topic被创建后,会有它默认的参数,不过有些topic的参数可能仍需要根据实际情况进行一些调整,例如: Replication Factor Partition数目 Message Size Compression level Log

该博文方法有问题,正确方案在http://www.cnblogs.com/dplearning/p/7992994.html 背景: 搭建了一个kafka集群,建立了topic test,用group_id  ttt 消耗topic. 但问题是,我消费的处理太慢了,导致了上百万数据的挤压,即offset滞后上百万 现在,想放弃上一次的任务,执行新的任务.但是topic名称和group_id不能变化. 想了几个方案,觉得重置offset是最符合我需求的. import os from conflu

需求: 目前kafka的topic上有一批数据,这些数据被分配到9个不同的partition中(就是发布时key:{m1,m2,m3,m4...m9},value:{records items}),mx(m1,m2...m9)这些数据的唯一键值:int_id+start_time,其中int_id和start_time是topic record中的记录.这9组数据按照唯一键值可以拼接(m1.primarykey1,m2.primarykey1,m3.primarykey1.....m9.prim

阿里太注重原理了:阿里问kafka如何实现高并发存储-如何找到一条需要消费的数据,kafka用了稀疏索引的方式,使用了二分查找法,其实很多索引都是二分查找法  二分查找法的时间复杂度:O(logn) redis,kafka,B+树的底层都采用了二分查找法 参考:二分查找法 redis的索引底层的 跳表原理 实现 聊聊Mysql索引和redis跳表 ---redis的跳表原理 时间复杂度O(logn)(阿里) 参考:二分查找法 mysql索引原理:一步步分析为什么B+树适合作为索引的结构 以及索引

Linux是cat.tail.head查看文件任意几行的数据 一.使用cat.tail.head组合 1.查看最后100行的数据 cat filename | tail -n 100 2.查看100到300行的数据 cat filename | head -n 300 | tail -n +100 1.cat filename 打印文件所有内容 2.tail -n 100 打印文件最后100行的数据 cat filename tail -n 100 3.tail -n +100 打印文件第100

一.JDB调试        在预发环境下进行debug时,时常因为工具和环境的限制,导致debug体验非常差,那么有什么方法能够简化我们进行debug的体验吗?JDB就是一种.        JDB是 The Java Debugger 的简称,它可以用来debug一个Java程序,同时它是 JPDA 的一个参考实现,只是这个实现是基于命令行的. 使用JDB的目的是,更细节的诊断和操控代码,如果只是观察值,可以使用arthas之类的工具 1.1.JPDA JPDA将调试过程分为两部分:被调试的

众所周知,由于Zookeeper并不适合大批量的频繁写入操作,新版Kafka已推荐将consumer的位移信息保存在Kafka内部的topic中,即__consumer_offsets topic,并且默认提供了kafka_consumer_groups.sh脚本供用户查看consumer信息. 不过依然有很多用户希望了解__consumer_offsets topic内部到底保存了什么信息,特别是想查询某些consumer group的位移是如何在该topic中保存的.针对这些问题,本文将结合

是指手动写扩充replicas的配置文件,然后使用工具进行操作. 参考官网site:http://kafka.apache.org/documentation.html#basic_ops_automigrate 1.首先创建一个三分区一副本的topic,并查看详细信息:    2.修改配置文件 将原有replicas为[0]扩充为[0,1], [1]扩充为[1,2],[2]扩充为[2,0,1] > cat partitions-to-move.json 3.执行操作,并检查修改情况 > bi

原文  https://www.cnblogs.com/huxi2b/p/6061110.html 众所周知,由于Zookeeper并不适合大批量的频繁写入操作,新版Kafka已推荐将consumer的位移信息保存在Kafka内部的topic中,即__consumer_offsets topic,并且默认提供了kafka_consumer_groups.sh脚本供用户查看consumer信息. 不过依然有很多用户希望了解__consumer_offsets topic内部到底保存了什么信息,特别

我现在使用的是librdkafka 的C/C++ 的客户端来生产消息,用flume来辅助处理异常的数据,,, 但是在前段时间,单独使用flume测试的时候发现,flume不能对分区进行负载均衡!同一个集群中,一个broker的一个分区已经有10亿条数据,另外一台的另一个分区只有8亿条数据: 因此,我对flume参照别人的做法,增加了拦截器: 即在flume配置文件中 增加以下字段: ----- stage_nginx.sources.tailSource.interceptors = i2sta

前言 kafka集群扩容后,新的broker上面不会数据进入这些节点,也就是说,这些节点是空闲的:它只有在创建新的topic时才会参与工作.除非将已有的partition迁移到新的服务器上面:所以需要将一些topic的分区迁移到新的broker上.另外一种情况就是集群减少broker节点,对原有的topic信息进行迁移,重新分配broker节点. 简单案例 本次案例将原本存在于两个borker节点(86,87)上的topic:test01(两副本),转移到87,88两个broker上(重新分配)

引言 上期我们对比了RocketMQ和Kafka在多Topic场景下,收发消息的对比测试,RocketMQ表现稳定,而Kafka的TPS在64个Topic时可以保持13万,到了128个Topic就跌至0.85万,导致无法完成测试.我们不禁要问: 为什么看不到Kafka性能暴跌的趋势呢? 今天的测试,就来排查一下这个问题,然后验证一下两个系统对外服务的稳定性.本次测试,要引入"稳定性测试"这个概念,那什么是稳定性测试呢?我们先来看一下定义: 稳定性测试:测试系统的长期稳定运行能力.在系统

之前写过如何用服务器端的API代码来获取订阅某topic的所有consumer group,参见这里.使用服务器端的API需要用到kafka.admin.AdminClient类,但是这个类在0.11.0.0版本已经被标记为不推荐使用了,故目前最合适的方式还是通过客户端API:org.apache.kafka.clients.admin.AdminClient.今天碰到有人问这个问题,我就尝试写了一个.使用之前你需要引入kafka client包依赖(以2.2.0版本为例) Maven: <de

引言 上期我们对比了RocketMQ和Kafka在多Topic场景下,收发消息的对比测试,RocketMQ表现稳定,而Kafka的TPS在64个Topic时可以保持13万,到了128个Topic就跌至0.85万,导致无法完成测试.我们不禁要问: 为什么看不到Kafka性能暴跌的趋势呢? 今天的测试,就来排查一下这个问题,然后验证一下两个系统对外服务的稳定性.本次测试,要引入“稳定性测试”这个概念,那什么是稳定性测试呢?我们先来看一下定义: 稳定性测试:测试系统的长期稳定运行能力.在系统运行过程中

Kafka官方提供了两个脚本来管理topic,包括topic的增删改查.其中kafka-topics.sh负责topic的创建与删除:kafka-configs.sh脚本负责topic的修改和查询,但很多用户都更加倾向于使用程序API的方式对topic进行操作.   上一篇文章中提到了如何使用客户端协议(client protocol)来创建topic,本文则使用服务器端的Java API对topic进行增删改查.开始之前,需要明确的是,下面的代码需要引入kafka-core的依赖,以kafka

1.获取所有topic package com.example.demo; import java.io.IOException; import java.util.List; import org.apache.zookeeper.KeeperException; import org.apache.zookeeper.WatchedEvent; import org.apache.zookeeper.Watcher; import org.apache.zookeeper.ZooKeeper