鸭梨的博客

在0.9版本之前，Kafka集群是没有安全机制的。首先，客户端获取Zookeeper系统连接地址后，通过访问Zookeeper系统中的元数据信息来获取Kafka集群地址；然后，客户端可以直接连接到Kafka集群，访问Kafka集群上的所有主题，并对主题进行管理员操作。由于没有限制，一些重要的业务主题就会存在安全性问题。例如泄露敏感数据、删除主题、修改分区等。基于这类场景考虑，在0.9版本之后，Kafka系统新增了两种安全机制——身份验证和权限控制，来确保存储数据的安全性。身份验证在Kafka系统中，

概念就是follwer同步leader的信息过程怎么同步?1 生产者写入消息,leader更新LEO2 leader通知follwer来取消息,follwer开始fetch数据3 follwer同步的速度是不一样的,有的快,有的慢,以所以follwer最小的offset为准,leader会更新HW值4 所有的follwer都跟上了leader,leader会再次更新HW5 leader负责读写,follwer阻塞以等待新的消息follwer跟不上节奏怎么办?如果follower“落后

谁来实施分区leader副本的选举由Kafka Controller 负责具体实施。选举时间leader挂掉时broker挂掉时,然后broker上可能有某些leader选举资格Kafka在Zookeeper中为每一个partition动态的维护了一个ISR，这个ISR里的所有replica都跟上了leader，只有ISR里的成员才能有被选为leader的可能（unclean.leader.election.enable=false）如果ISR为空怎么办?在ISR中至少有一个foll

概念在Kafka在0.8以前的版本中，是没有Replication的，一旦某一个Broker宕机，则其上所有的Partition数据都不可被消费，这与Kafka数据持久性及Delivery Guarantee的设计目标相悖;所以,0.8 以后就引入了副本机制;引入副本机制后带来的问题引入Replication之后，同一个Partition可能会有多个Replica，而这时需要在这些Replica中选出一个Leader，Producer和Consumer只与这个Leader交互，其它Replica作为

分区器分区器是生产者层面的负载均衡。Kafka 生产者生产消息时，根据分区器将消息投递到指定的分区中，所以 Kafka 的负载均衡很大程度上依赖于分区器。Kafka 默认的分区器是 Kafka 提供的 DefaultPartitioner。它的分区策略是根据 Key 值进行分区分配的：如果 key 不为 null：对 Key 值进行 Hash 计算，从所有分区中根据 Key 的 Hash 值计算出一个分区号；拥有相同 Key 值的消息被写入同一个分区；如果 key 为 null：消息将以轮询的方式

spark.streaming.backpressure.initialRatespark2.0版本以上这是启用背压机制时每个接收器将接收第一批数据的初始最大接收速率。限制第一次批处理应该消费的数据，因为程序冷启动 队列里面有大量积压，防止第一次全部读取，造成系统阻塞This is the initial maximum receiving rate at which each receiver will receive data for the first batch when the backp

auto.commit.interval.mskafka自动提交offset的频率,默认是5000ms,就是5s如果将enable.auto.commit设置为true，则消费者偏移量自动提交给Kafka的频率（以毫秒为单位）。The frequency in milliseconds that the consumer offsets areauto-committed to Kafka if enable.auto.commit is set to true.自动提交是调用poll方法的时

原因根本原因：已经消费了数据，但是offset没提交。原因1：强行kill线程，导致消费后的数据，offset没有提交。原因2：设置offset为自动提交，关闭kafka时，如果在close之前，调用 consumer.unsubscribe() 则有可能部分offset没提交，下次重启会重复消费。原因3（重复消费最常见的原因）：消费后的数据，当offset还没有提交时，partition就断开连接。比如，通常会遇到消费的数据，处理很耗时，导致超过了Kafka的session timeout时间（0

概念consumer 向 broker 发送心跳,表明自己还活着,不用被踢出消费者组参数session.timeout.ms表示 consumer 向 broker 发送心跳的超时时间。例如 session.timeout.ms = 180000 表示在最长 180 秒内 broker 没收到 consumer 的心跳，那么 broker 就认为该 consumer 死亡了，会启动 rebalance。The timeout used to detect worker failures. The

概念Rebalance 本质上是一种协议，规定了一个 Consumer Group 下的所有 consumer 如何达成一致，来分配订阅 Topic 的每个分区。例如：某 Group 下有 20 个 consumer 实例，它订阅了一个具有 100 个 partition 的 Topic 。正常情况下，kafka 会为每个 Consumer 平均的分配 5 个分区。这个分配的过程就是 Rebalance。触发 Rebalance 的时机Rebalance 的触发条件有3个。组成员个数发生变化。例

kafka消息堆积,可以调节如下两个参数max.poll.records一次调用poll（）返回的最大记录数。默认值500 就是一次最多拉取500条记录max.poll.interval.msmax.poll.interval.ms参数用于指定consumer两次poll的最大时间间隔（默认5分钟），如果超过了该间隔consumer client会主动向coordinator发起LeaveGroup请求，触发rebalance；然后consumer重新发送JoinGroup请求The maxi

如何设置 Heap Size 的问题，其实和 Kafka 关系不大，它是一类非常通用的面试题目。一旦你应对不当，面试方向很有可能被引到 JVM 和 GC 上去，那样的话，你被问住的几率就会增大。因此，我建议你简单地介绍一下 Heap Size 的设置方法，并把重点放在 Kafka Broker 堆小设置的最佳实践上。比如，你可以这样回复：任何 Java 进程 JVM 堆大小的设置都需要仔细地进行考量和测试。一个常见的做法是，以默认的初始 JVM 堆大小运行程序，当系统达到稳定状态后，手动触发一次

安装Burrow$ git clone https://hub.fastgit.org/linkedin/Burrow.git$ cd Burrow/$ go mod tidy$ go install 参考Kafka 消费迟滞监控工具 Burrow_weixin_34259159的博客-优快云博客linkedin/Burrow: Kafka Consumer Lag Checkinghttps://github.com/linkedin/Burrow...

Kafka的日志实际上是开始是在缓存中的，然后根据策略定期一批一批写入到日志文件中去，以提高吞吐率。属性名 含义 默认值log.flush.interval.messages 消息达到多少条时将数据写入到日志文件 10000log.flush.interval.ms 当达到该时间时，强制执行一次flush nulllog.flush.scheduler.interval.ms 周期性检查，是否需要将信息flush 很大的值...

日志清除策略根据消息的保留时间，当消息在 kafka 中保存的时间超过了指定的时间，就会触发清理过程根据 topic 存储的数据大小，当 topic 所占的日志文件大小大于一定的阀值，则可以开始删除最旧的消息。kafka 会启动一个后台线程，定期检查是否存在可以删除的消息，通过 log.retention.bytes 和 log.retention.hours 这两个参数来设置，当其中任意一个达到要求，都会执行删除。日志压缩策略Kafka 还提供了日志压缩（Log Compaction）功能，通

max.in.flight.requests.per.connection该参数指定了生产者在收到服务器晌应之前可以发送多少个消息。它的值越高，就会占用越多的内存，不过也会提升吞吐量。把它设为1可以保证消息是按照发送的顺序写入服务器的，即使发生了重试。因为如果将两个批次发送到单个分区，并且第一个批次失败并被重试，但是，接着第二个批次写入成功，则第二个批次中的记录可能会首先出现，这样就会发生乱序。如果没有启用幂等功能，但仍然希望按顺序发送消息，则应将此设置配置为1。但是，如果已经启用了幂等，则无需显式

生产者从服务器收到的错误有可能是临时性的错误（比如分区找不到首领）。在这种情况下， retries参数的值决定了生产者可以重发消息的次数，如果达到这个次数，生产者会放弃重试并返回错误。默认情况下，生产者会在每次重试之间等待100ms ，可以通过retry.backoff.ms 参数来配置时间间隔。比如，设置了acks=all和min.insync.replicas=2。由于某种原因，所有follower都挂了，由于min.insync.replicas=2，所以生产者无法收到来自Broker端的ack。

就可靠性而言，基本没有任何东西可以保证做到百分之百的可靠。只能是通过一些策略来最大程度的保证可靠性。1.增大副本数。副本数越多，越能够保证数据的可靠性。但是副本数越多也会引起磁盘，网络带宽的浪费，还有性能的下降。所以，一般设置为3即可满足大多数的场景对可靠性的要求，部分银行之类的可能会设置成5.2.生产端对于一些由于网络故障等造成发送失败的可重试异常，可以通过设置重试次数（retries）来增加可靠性。3.生产者设置ack机制，为-1.但是也可能出现某个分区的数据的follower同步速度太慢都被踢

LEO 全程Log End Offset,就是log最后一条记录下一条的offset值.log对象初始化的时候，需要创建一个新的LEO对象，并对其进行初始化。写入新消息的时候，当不断向Log对象插入消息时，LEO会向指针一样，不断的增加。Log对象发生日志切分的时候，当前日志段对象已满的时候，会关闭当前写入的日志段对象，创建一个全新的日志段对象，一旦日志发生切分，LEO中的起始位移值和段大小数据都要被更新，所以需要更新LEO对象Log截断的时候，日志中的部分消息被删除了，自然可能导致LEO值发生变化

producer是线程安全的。两个线程生产者客户端由两条线程协调运行，分别是主线程和sender线程（发送线程）。主线程通过KafkaProducer创建消息 （ProducerRecord） ，然后通过拦截器，序列化器，分区器的作用之后将消息缓存到消息累加器中.分区器的作用默认DefaultPartitioner，默认进行hash%分区数求分区，如果key为null,就通过每条数据进行通过计数器累加，最大值是可用分区个数，轮询方式取余数发往可用的分区中RecordAccumulat

全局顺序就目前的应用范围来讲，可以列举出来的也就限于binlog日志传输，如mysql binlog日志传输要求全局的顺序，不能有任何的乱序。这种的解决办法通常是最为保守的方式：全局使用一个生产者全局使用一个消费者（并严格到一个消费线程）全局使用一个分区（当然不同的表可以使用不同的分区或者topic实现隔离与扩展）...

./bin/spark-submit \ --master spark://192.168.1.1:7077 \ --num-executors 100 \ --executor-memory 6G \ --executor-cores 4 \　--total-executor-cores 400 \ ##standalone default all cores --driver-memory 1G \ --conf spark.default.parallelism=1000

与任何技术一样，Kafka 也有其局限性 - 其中之一是 1 MB 的最大封装大小。这只是默认设置，但不应轻易更改。有三种可能性：调整默认设置某些较大的消息 （10 MB） 也会影响群集的性能，因此不建议这样做。将数据集划分为较小的单元这是可能的，但会显著增加复杂性，同时增加使用者对内存的需求。 仅向 Kafka 群集发送对数据的引用，并存储在另一个容器中的数据包这是大多数应用程序的建议方法。它只是稍微增加了应用程序的复杂性，并保留了所有使Kafka如此有趣的功能。在下面，我将详细介绍不同的方法

buffer.memoryKafka的客户端发送数据到服务器，不是来一条就发一条，而是经过缓冲的，也就是说，通过KafkaProducer发送出去的消息都是先进入到客户端本地的内存缓冲里，然后把很多消息收集成一个一个的Batch，再发送到Broker上去的，这样性能才可能高。buffer.memory的本质就是用来约束Kafka Producer能够使用的内存缓冲的大小的，默认值32MB。如果buffer.memory设置的太小，可能导致的问题是：消息快速的写入内存缓冲里，但Sender线程来不及把R

HWHW （High Watermark）俗称高水位，它标识了一个特定的消息偏移量（offset），消费者只能拉取到这个offset之前的消息。LEOLEO （Log End Offset），标识当前日志文件中下一条待写入的消息的offset。上图中offset为9的位置即为当前日志文件的 LEO，LEO 的大小相当于当前日志分区中最后一条消息的offset值加1.分区 ISR 集合中的每个副本都会维护自身的 LEO ，而 ISR 集合中最小的 LEO 即为分区的 HW，对消费者而言只能消费 HW

在kafka中，实现副本的目的就是冗余备份，且仅仅是冗余备份，所有的读写请求都是由leader副本进行处理的。follower副本仅有一个功能，那就是从leader副本拉取消息，尽量让自己跟leader副本的内容一致。这个问题本质上是对性能和一致性的取舍。试想一下，如果follower副本也对外提供服务那会怎么样呢？首先，性能是肯定会有所提升的。但同时，会出现一系列问题。类似数据库事务中的幻读，脏读。比如你现在写入一条数据到kafka主题a，消费者b从主题a消费数据，却发现消费不到，因为消费者b去读取的

Kafka需要在吞吐量和延迟之间取得平衡,可以通过下面两个参数控制.batch.size当多个消息发送到相同分区时,生产者会将消息打包到一起,以减少请求交互. 而不是一条条发送批次的大小可以通过batch.size 参数设置.默认是16KB较小的批次大小有可能降低吞吐量（批次大小为0则完全禁用批处理）。一个非常大的批次大小可能会浪费内存。因为我们会预先分配这个资源。例子比如说发送消息的频率就是每秒300条，那么如果比如batch.size调节到了32KB，或者64KB，是否可以提升发送消息

当我们谈论 Kafka 性能调优时，需要考虑很少的配置参数。因此，为了提高性能，最重要的配置是控制磁盘刷新速率的配置。此外，我们可以根据组件划分这些配置。因此，让我们先谈谈Producer。因此，在生产者方面需要注意的最重要的配置是CompressionBatch sizeSync or Async而且，在消费者方面，重要的配置是Fetch size虽然，当我们考虑批处理大小时，总是会困惑多大batch size是最佳的。我们可以说，大批量大小可能是伟大的高吞吐量，它伴随着延迟问题。这意味

Kakfa使用方式CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]( name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1], name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2], ...) ENGINE = Kafka()SETTINGS kafka_broker_list = 'host:por

kafka sink添加依赖<dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-connector-kafka-0.11_2.11</artifactId> <version>1.7.2</version></dependency>将数据写入kafka,然后启动命令行消费者可以看下结果import

从集合构建import org.apache.flink.streaming.api.scala.{DataStream, StreamExecutionEnvironment}object Sensor extends App {//创建环境 private val env: StreamExecutionEnvironment = StreamExecutionEnvironment.getExecutionEnvironment //导入隐式转换 import org.apache

[root@mypc01 /]# free -h total used free shared buff/cache availableMem: 1.8G 1.6G 94M 1.5M 110M 75MSwap: 2.0G 1.8G 183Mcat kafka-server-start.sh

用于 Kafka 0.10 的结构化流式处理集成，用于从 Kafka 读取数据和写入数据。从kafka读取数据// Subscribe to 1 topicval df = spark .readStream .format("kafka") .option("kafka.bootstrap.servers", "host1:port1,host2:port2") .option("subscribe", "topic1") .load()df.selectExpr("CAST(

用kafka-consumer-groups.sh 命令可以查看消费者组,其中console-consumer-89657是消费的时候如果不设置消费者组自动生成的默认组[root@mypc01 config]# kafka-consumer-groups.sh \> --new-consumer \> --bootstrap-server mypc01:9092,mypc02:9092,mypc03:9092 \> --listThe [new-consumer] option

使用kafka-consumer-groups.sh 命令,必须指定消费者组,否则报错.如下可以看出cat topic目前的offset位置是在5219[mypc01 config]# kafka-consumer-groups.sh \> --bootstrap-server mypc01:9092,mypc02:9092,mypc03:9092 \> --describe \> --group g2Note: This will not show information a

代码如下 val df: DataFrame = spark.readStream .format("kafka") .option("kafka.bootstrap.servers", "mypc01:9092,mypc02:9092,mypc03:9092") .option("subscribe", "cat") // 从头消费 .option("staringOffsets", "earliest") // 设置消费者组

命令行1 group id换成新的2 offset参数设为earliestkafka-console-consumer.sh \--bootstrap-server mypc01:9092,mypc02:9092,mypc03:9092 \--topic cat \--partition 0 \--group group1 \--offset earliest代码seekToBeginning方法可以让从头开始消费//从头开始消费 def ConsumerTest3(): Un

删除topic一般是下面这样的,但是这样是删不掉的,只是标记为删除,再次创建同名topic还是会报错,topic已经存在.kafka-topics.sh \--zookeeper mypc01:2181,mypc02:2181,mypc03:2181/kafka \--delete \--topic pet首先server.properties 设置 delete.topic.enable=true删除kafka存储目录（server.properties文件log.dirs配置，默认为"/

kafka启动后总是报错,查看log报错如下/usr/local/kafka/logs/server.logERROR Fatal error during KafkaServer startup. Prepare to shutdown(kafka.server.KafkaServer) kafka.common.InconsistentBrokerIdException:Configured broker.id 10 doesn’t match stored broker.id 1从报错

假设有三台机器,分别为mypc01,mypc02,mypc03#!/bin/bashshow(){ echo -e "\033[0;37;44m"$1"\033[00m"}case $1 in start)for i in mypc01 mypc02 mypc03doshow "--------------- $i ---------------" ssh $i> /dev/null 2>&1 << eof/usr/local/kafka/bin/