目录一、主题topic命令行操作1.查看操作主题的命令参数2.连接kafka地址，创建名为kaf的主题，指定分区和副本数量3.查看所有主题的名称4.查看主题的详细信息5.修改主题（修改分区数）二、生产者命令行操作1.查看操作生产者的命令参数：kafka-console-produce.sh2.生产一个数据，放到topickaf中3.消费者使用数据slave2slave3都可一、主题topic命令行操作1.查看操作主题的命令参数：kafka-topic.sh参数 说明--bootstrap-server 设置连接kafka的主机名和端口号--topic设置操作主题的名称--create创建主题
Kafka是LinkedIn公司使用Scala语言开发，后来捐献给apache的项目。官网地址是http://kafka.apache.org。是常用的以高吞吐、可持久化、可水平扩展、支持流处理的分布式消息系统。简单架构图：生产端：逻辑层生产者将消息发到指定的topic中，物理层，生产者先找到相应的集群和对应的leaderpartition建立连接发送消息。消费端：逻辑层消费组接收此topic的所有消息，物理层消费组的消费者连接到固定的partition来消费消息。在物理层上包装逻辑层也是一个比较常见的解耦方法：比如很多公司都是多地域多中心的多活容灾架构。在物理层北京亦庄数据中心、上海桂桥数据
一、Kafka介绍Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多生产者、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。主要应用场景是：日志收集系统和消息系统。Kafka主要设计目标如下：以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。 支持KafkaServer间的消息分区，及
前言现在假定这么一个业务场景，从kafka中的topic获取消息数据，经过一定加工处理后，发送到另外一个topic中，要求整个过程消息不能丢失，也不能重复发送，即实现端到端的Exactly-Once精确一次消息投递。这该如何实现呢？kafka事务介绍针对上面的业务场景，kafka已经替我们想到了，在kafka0.11版本以后，引入了一个重大的特性：幂等性和事务。幂等性这里提到幂等性的原因，主要是因为事务的启用必须要先开启幂等性，那么什么是幂等性呢？幂等性是指生产者无论向kafkabroker发送多少次重复的数据，broker 端只会持久化一条，保证数据不会重复。幂等性通过生产者配置项enabl
创建kafka我们需要分两步走：前沿：请大家注意在云服务器上部署任何新的服务一定要注意在对应云安全配置上开放此端口号 1、使用docker先拉取 zookeeper，因为kafka对zookeeper是强依赖命令：dockerpullzookeeper:3.4.14创建容器指令：dockerrun-d--namezookeeper-p2181:2181zookeeper:3.4.14docker安装kafka命令：dockerpullwurstmeister/kafka:2.12-2.3.1创建容器：dockerrun-d--namekafka\--envKAFKA_ADVERTISED_HO
消费者分区分配策略分区分配策略一个consumergroup中有个多个topic，一个topic有多个partition，所以必然会涉及到partition的分配问题，即确定哪个partition由哪个消费者进行消费。kafka有两种分配策略，RoundRobin和RangeRoundRobin策略按消费者组来分配多个分区会以轮询的方式，分配给多个消费者，因此消费者之间相差的最大分区数为1。如果是消费者组订阅了多个主题，首先kafka将多个主题中的分区当做一个整体，然后根据TopicAndPartition方法将主题中的分区对象通过hash值的方式重新排个序，然后生成一个新的整体出来，再轮询到
问题描述12月28日，公司测试环境Kafka的task.build.metadata.flow这个topic突然无法消费。其他topic都正常使用，这个topic只有一个分区，并且只有一个消费者查找问题原因首先登录服务器，运行kafka的cli命令，查看消费者组的详情。#进入kafka安装目录下的bin目录执行./kafka-consumer-groups.sh--bootstrap-server127.0.0.1:9092--describe--group消费者组名称由上图可以发现，task.build.metadata.flow这个topic，最新offset是2，但是当前offset只到
问题描述12月28日，公司测试环境Kafka的task.build.metadata.flow这个topic突然无法消费。其他topic都正常使用，这个topic只有一个分区，并且只有一个消费者查找问题原因首先登录服务器，运行kafka的cli命令，查看消费者组的详情。#进入kafka安装目录下的bin目录执行./kafka-consumer-groups.sh--bootstrap-server127.0.0.1:9092--describe--group消费者组名称由上图可以发现，task.build.metadata.flow这个topic，最新offset是2，但是当前offset只到
前言天下武功，唯快不破。同样的，kafka在消息队列领域，也是非常快的，这里的块指的是kafka在单位时间搬运的数据量大小，也就是吞吐量，下图是搬运网上的一个性能测试结果，在同步发送场景下，单机Kafka的吞吐量高达17.3w/s，不愧是高吞吐量消息中间件的行业老大。那究竟是什么原因让kafka如此之快呢？这也是面试官非常喜欢问的问题。四个原因原因一：磁盘顺序读写生产者发送数据到kafka集群中，最终会写入到磁盘中，会采用顺序写入的方式。消费者从kafka集群中获取数据时，也是采用顺序读的方式。无论是机械磁盘还是固态硬盘SSD，顺序读写的速度都是远大于随机读写的。因为对于机械磁盘顺序读写省去了
大纲Kafka支持的消息压缩类型什么是Kafka的消息压缩消息压缩类型何时需要压缩如何开启压缩在Broker端开启压缩compression.type属性broker和topic两个级别broker级别topic级别在Producer端压缩compression.type属性开启压缩的方式压缩和解压的位置何处会压缩producer端broker端何处会解压consumer端broker端压缩和解压原理CompressionTypeCompressionCodecCompressionType源码MemoryRecordsBuilderDefaultRecordBatchAbstractLega
