什么是Kafka？有什么优势

Kafka

Kafka是一个分布式消息队列，具备高性能、持久化、多副本备份、横向扩展能力.(pub-sub模型)

维基百科

Kafka 是由Apache软件基金会开发的一个开源流处理平台，由Scala和JAVA编写.该项目的目标是为处理实时数据提供一个统1、高吞吐、低延迟的平台。其持久化层本质是一个"按照分布式事务日志架构的大规模发布/订阅消息队列".Kafka能够经过Kafka Connect链接到外部系统(用于数据输入/输出),并提供了Kafka Streams ———— 一个Java流式处理库.

基于kafka-zookeeper 的分布式消息队列系统整体架构以下：

Kafka 架构说明

一个典型的Kafka集群包含若干Producer，若干Broker，若干Consumer，以及一个Zookeeper集群。Kafka经过Zookeeper管理集群配置，选举Leader，以及在Consumer Group发送变化时进行Rebalance(负载均衡)。Producer 使用push(推)模式将消息发布到Broker；Consumer 使用pull(拉)模式从Broker订阅并消费消息。

Kafka 四大核心

• 生产者API：容许应用程序发布记录流至一个或多个kafka的主题(Topics)
  
• 消费者API：容许应用程序订阅一个或多个主题，并处理这些主题接收到的记录流
  
• Streams API: 容许应用程序充当流处理器(stream processor)，从一个或多个主题获取输入流，并生产一个输出流至一个或多个的主题，可以有效地变换输入流为输出流
  
• Connector API: 容许构建和运行可重用的生产者或消费者，可以把kafka主题链接到现有的应用程序或数据系统

Kafka 基础概念

• 不管是kafka集群，仍是consumer都依赖于zookeeper集群保存一些meta信息，来保证系统可用性
• Producer 采用推(push)模式将消息发布到broker，每条消息都被追加(append)到分区(partition)中，属于顺序写磁盘(顺序写磁盘效率比随机写内存要高，保障kafka吞吐率)
• Producer
• • 发送消息者称为 Producer

• 生产者组件图

• 建立Kafka生产者
• • 要往Kafka写入信息，首先要建立一个生产者对象，并设置一些属性。Kafka生产者有3个必选属性
• bootstrap.servers
• • 该属性指定broker的地址清单，地址的格式为host:port。清单里不须要包含全部的broker地址，生产者会从给定的broker里查找到其余的broker的信息。(建议提供两个broker信息，一旦其中一个宕机，生产者仍然可以链接到集群上)
• key.serializer
• • broker 但愿接受到的消息的键和值都是字节数组.生产者接口容许使用参数化类型，所以能够把java对象做为键和值发送给broker。
• value.serializer
• • value.serializer 指定的类会将值序列化。若是键和值都是字符串，可使用key.serializer同样的序列化器。若是键是整数类型而值是字符串，那么须要使用不一样的序列化器.

生产者的配置

参数	描述
acks	acks 参数指定了必需要有多少个分区副本收到消息，生产者才会认为消费写入是成功的。acks = 0 生产者在成功写入消息以前不会等待任何来自服务器的响应。(缺点：没法确认消费是否成功；优势：高吞吐量)；acks = 1 只要集群的首领节点收到消息，生产者就会收到一个来自服务器的成功响应。若是消费没法到达首领节点(好比首领节点奔溃，新的首领尚未被选举处理)，生产者会收到一个错误响应，为了不数据丢失，生产者会重发消息。不过，若是一个没有收到消息的节点成为新首领，消息仍是会丢失。acks = all 只有当全部参与复制的节点所有收到消息时，生产者才会收到一个来自服务器的成功响应。
buffer.memory	该参数用来设置生产者缓冲区的大小，生产者用它缓冲要发送到服务器的消息。0.9.0.0 版本被替换成了 max.block.ms,表示在抛出异常以前能够阻塞一段时间
compression.type	默认状况下为none，消费发送时不会被压缩。该参数能够设置为snappy、gzip或lz4，它指定了消息被发送给broker以前使用哪种压缩算法进行压缩。1. snappy 压缩算法有Google发明，它占用较少的CPU，却能提供较好的性能和至关可观的压缩比(比较关注性能和网路带宽) 2. gzip 压缩算法通常会占用较多的CPU，但会提供更高的压缩比(网络带宽有限次采用)
retries	生产者从服务器收到的错误有多是临时性的错误(好比分区找不到首领)。在这中状况下，retries参数是值决定了生产者能够重发消息的次数，若是达到这个次数，生产者会放弃重试并返回错误。默认状况下，生产者会在每次重试之间等待100ms，能够经过retry.backoff.ms参数来改变这个时间间隔.
batch.size	当有多个消息须要被发送到同一个分区时，生产者会把它们放在同一个批次里。该采纳数指定了一个批次可使用的内存大小，按照字节数计算(而不是消息个数)。1. 批次设置很大 不会形成延迟，只会占用更多的内存 2. 批次设置很小 由于生产者须要更频繁地发送消息，会增长一些额外的开销
linger.ms	该参数指定了生产者在发送批次以前等待更多消息加入批次的时间。
client.id	该参数能够是任意的字符串，服务器会用它来识别消息的来源，还能够用在日志和配额指标里
request.timeout.ms	指定了生产者在发送数据时等待服务器返回响应的时间
max.block.ms	该参数指定了在调用send()方法或使用partitionsFor()方法获取元数据时生产者的阻塞时间。当生产者的发送缓冲区已满，或者没有可用的元数据时，这些方法就会阻塞。在阻塞时间达到max.block.ms时，生产者会抛出超时异常
max.request.size	该参数用于控制生产者发送的请求大小。它能够指能发送的单个消息的最大值，能够指单个请求里全部消息总的大小。

• Consumer
• • 消息接收者称为Consumer
• • consumer 采用pull(拉)模式从broker中读取数据
• • push(推) 模式很难适应消费速率不一样的消费者，由于消息发送速率是由broker决定的。它的目标是尽量以最快速度传递消息，可是这样很容易形成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则能够根据consumer的消费能力以适当的速率消费消息
• • 对于Kafka而言,pull模式更合适，它可简化broker的设计，consumer可自主控制消费消息的速率，同时consumer能够本身控制消费方式——便可批量消费也可逐条消费， 同时还能选择不一样的提交方式从而实现不一样的传输语义
• • pull 模式不足之处是，若是kafka没有数据，消费者可能会陷入循环中，一直等待数据到达。为了不这种状况，咱们在拉请求中有参数，容许消费者请求在的等待数据到达的"长轮询"中进行阻塞(而且可选地等待到给定的字节数，以确保打的传输大小)
• Consumer Group (CG)
• • 这是kafka用来实现一个topic消息的广播(发给全部的consumer)和单播(发给任意一个consumer)的手段。一个topic能够有多个CG。topic的消息会复制(概念上的复制)到全部的CG，但每一个partition只会把消息发给该CG中的一个consumer。若是须要实现广播，只要每一个consumer有一个独立的CG就能够了。要实现单播只要全部consumer在同一个CG。用CG还能够将consumer进行自由的分组而不须要屡次发送消息到不一样的topic
• • 每一个分区在同一时间只能由group中的一个消费者读取，可是多个group能够同时消费这个partition。
• • 消费者经过向被指派为群组协调器的broker发送心跳来维持它们和群组的从属关系以及它们对分区的全部权关系.
• Broker(代理)
• • 已发布的消息保存在一组服务器中，称之为Kafka集群。集群中的每个服务器都是一个代理。
• 主题(Topic)
• • Kafka将消息以topic为单位进行概括(一条消息必须属于某一个主题)
• • 在Kafka集群中，能够有无数的主题
• • Kafka 的主题始终是支持多用户订阅的；也就是说，一个主题能够有零个，一个或多个消费者订阅写入的

数据

• • 分区数(Partitions): 控制topic将分片成多少log。能够显示指定，若是不指定则会使用broker(server.properties)中的num.partitions配置的数量
• • replication-factor副本：控制消息保证在几个broker(服务器)上，通常状况下等于broker的个数。
• 分区(Partitions)
• • 消息发送时都被发送到一个topic，其本质就是一个目录，而topic是由一些Partition Logs(分区日志)组成

• • 每一个Topic都有一个或者多个Partitions 构成
• • 每一个Partition都是有序且不可变的消息队列
• • Topic的Partition数量能够在建立时配置
• • Partition数量决定了每一个Consumer group中并发消费者的最大数量
• • 分区的缘由：
• • 1. 方便在集群中扩展，每一个Partition能够经过调整以适应它所在的机器，而一个topic又能够有多个Partition组成，所以整个集群就能够适应任意大小的数据了；
• • 1. 能够提升并发，由于能够以Partition为单位读写
• • 分区的原则：
• • 1. 指定了partition，则直接使用
• • 1. 未指定partition但指定key，经过对key的value进行hash出一个partition
• • 1. partition和key都未指定，使用轮询选出一个partition
• 偏移量(offset)
• • 任何发布到partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset(偏移量),offset是一个long型数字，它惟一标记一条消息。消费者经过(offset、partition、topic)跟踪记录.

副本

• 副本因子操做的单位是以分区为单位,每一个分区都有各自的主副本和从副本
• 主副本叫作leader，从副本叫作follower，处于同步状态的副本叫作in-sync
• 致使副本同步失败的缘由：
• • 网络拥塞致使复制变慢
• • broker 发生奔溃致使复制滞后
• 持续的副本：持续请求获得最新消息副本被称为同步的副本。在首领发生失效时，只有同步副本才有可能被选为新首领

复制

• Kafka的复制机制和分区的多副本架构是Kafka可靠性保证的核心。把消息写入多个副本能够是Kafka在发送奔溃时仍能保证消息的持久性。

replicas(ISR);

• • Follower 经过拉的方式从leader同步数据。消费者和生产者都是从leader读写数据，不与follower交互
• • 当有多个副本数时，kafka并非将多个副本同时对外提供读取和写入,做用是让kafka读取和写入数据时的高可靠
• log 日志
• • kafka-log 目录下,会根据: 主题-分区 值建立目录
• • 00000000000000000000.index -- 索引 稀疏索引
• • 00000000000000000000.log -- 数据
• • log 默认状况下会根据1G的大小，建立一个新的segment file文件
• • 00000000000000001123.index -- 1123 offset的开始值
• • 00000000000000001123.log
• log 的优化
• • 能够选择删除或者合并

集群成员关系

• Kafka 使用Zookeeper来维护集群成员的信息。每一个broker都有一个惟一标识符，这个标识符能够在配置文件里指定，也能够自动生成。在broker启动的时候，它经过建立临时节点把本身的ID注册到Zookeeper。Kafka组件订阅Zookeeper的 /brokers/ids 路径(broker在Zookeeper上的注册路径)，当有broker加入集群或退出集群时，这些组件就能够得到通知。在broker停机、出现网络分区或长时间垃圾回收停顿时，broker会从Zookeeper上断开链接，此时broker在启动时建立的临时节点会自动从Zookeeper上移除。监听broker列表的Kafka组件会被告知该broker已移除。在关闭broker时，它对应的节点也会消失，不过它的ID会继续存在于其余数据结构中

处理请求

• broker 的大部分工做是处理客户端、分区副本和控制器发送给分区首领的请求。Kafka提供一个二进制协议(基于TCP),指定了请求信息的格式以及broker如何对请求作出响应——包括成功处理请求或在处理请求过程当中遇到错误。
• 客户端发起链接并发送请求，broker处理请求并做出响应。broker按照请求到达的顺序来处理它们——这种顺序保证让Kafka具备了消息队列的特性，同时保证保存的消息也是有序的。
• 标志消息头

参数	描述
Request type	API key
Request version	broker能够处理不一样版本的客户端请求，并根据客户端版本作出不一样的响应
Correlation ID	一个具备惟一性的数字，用于标识请求消息，同时也会出如今响应消息和错误日志里(用于诊断问题)
Client ID	用于标识发送请求的客户端

• broker会在它所监听的每个端口上运行一个Acceptor线程，这个线程会建立一个链接，并把它交给Processor线程去处理。Processor线程("网络线程")的数量是能够配置的 。网络线程负责从客户端获取请求信息，把它们放进请求队列，而后从响应队列获取响应信息，把它们发送给客户端。
• 客户端如何知道往哪里发送请求
• • 客户端使用了另外一种请求类型，也就是元数据请求。这种请求包含了客户端感兴趣的主题列表。服务器端的响应消息里指明了这些主题所包含的分区、每一个分区都有哪些副本，以及哪一个副本是首领。元数据请求能够发送给任意一个broker，由于全部broker都缓存了这些信息。

控制器

• 控制器其实就是一个broker。集群里第一个启动的broker经过在Zookeeper里建立一个临时节点 /controller 让本身成为控制器。其余broker在启动时也会尝试建立这个节点，不过它们会收到一个"节点已存在"的异常，而后"意识"到控制器节点已存在，也就是说集群里已经有一个控制器了。其余broker在控制器节点上建立Zookeeper watch对象，这样它们就能够收到这个节点的变动通知。这种方式能够确保集群里一次只有一个控制器存在。
• 若是控制器被关闭或者Zookeeper断开链接，Zookeeper上的临时节点就会消失。集群里的其余broker经过watch对象获得控制器节点消失的通知，它们会尝试让本身成为新的控制器。第一个在Zookeeper里成功成功建立控制器节点的broker就会成为新的控制器，其余节点会收到"节点已存在"的异常，而后在新的控制器节点上再次建立watch对象。每一个新选出的控制器经过Zookeeper的条件递增操做得到一个全新的、数值更大的controller epoch。其余broker在知道当前controller epoch后，若是收到有控制器发出的包含旧epoch的消息，就会忽略它们。
• 当控制器发现一个broker已经离开集群(经过观察相关的Zookeeper路径)，它就知道，那些失去首领的分区须要一个新首领(这些分区的首领恰好在这个broker上)。控制器遍历这些分区，并肯定谁应该成为新首领(简单来讲就是分区副本列表里的下一个副本)，而后向全部包含新首领或现有跟随者的broker发送请求。该请求消息包含了谁是新首领已经谁是分区跟随者的信息。随后新首领开始处理来着生产者和消费者的请求，而跟随者开始重新首领那里复制消息。
• 当控制器发现一个broker加入集群时，它会使用broker ID来检查新加入的broker是否包含现有的分区副本。若是有，控制器就把变动通知发送给新加入的broker和其余broker，新broker上的副本开始从首领那里复制消息。

Kafka 消费过程分析

• • Kafka提供了两套consumer API：高级Consumer API 和 低级 Consumer API
• • 高级API 优势
• • 1. 高级API写起来简单
• • 1. 不须要自行去管理offset，系统经过zookeeper自行管理
• • 1. 不须要管理分区，副本等状况，系统自动管理
• • 1. 消费者断线会自动根据上一次记录在zookeeper中的offset去接着获取数据(默认设置1分钟更新一下zookeeper中存的offset)
• • 1. 可使用group来区分对同一个topic的不一样程序访问分离开来(不一样的group记录不一样的offset，这样不一样程序读取同一个topic才不会由于offset互相影响)
• • 高级API 缺点
• • 1. 不能自行控制offset(对于某些特殊需求)
• • 1. 不能细化控制，如分区、副本、zk等
• • 低级API
• • 低级API优势
• • 1. 可以让开发者本身控制offset，想从哪里读取就从哪里读取
• • 1. 自行控制链接分区，对分区自定义进行负载均衡
• • 1. 对zookeeper的依赖性下降(如：offset不必定非要靠zk存储，自行存储offset便可，好比存储在文件或则内存中)
• • 低级API缺点
• • 太过复杂，须要自行控制offset，链接哪一个分区，找到分区leader等
• kafka复制原理
• • 消费的发送方式：主题value、主题keyvalue、主题分区keyvalue、主题分区时间戳

keyvalue

• • Kafka 中topic的每一个partition有一个预写式的日志文件，虽然partition能够继续细分为若干个segment文件，可是对于上层应用来讲能够将partition当作最小的存储单元，每一个partition都由一些列有序的、不可变的消息组成，这些消息被连续的追加到partition中。
• • LEO：LogEndOffset的缩写，表示每一个partition的log最后一条Message的位置
• • HW： 是HighWatermark的缩写，是指consumer可以看到的此partition的位置
• • 具体描述：Kafka每一个topic的partition有N个副本(replicas).
• • kafka 经过多副本机制实现故障自动转移，当kafka集群中一个broker失效状况下仍然保证服务可用。kafka中发生复制时确保partition的日志能有序地写到其余节点上，N个replicas中，其中一个replicas为leader，其余都为follower，leader处理partition的全部读写请求，于此同时，follower会被动按期地去复制leader的数据。kafka提供了数据复制算法保证，若是leader发生故障或挂掉，一个新leader被选举并接受客户端的消息成功写入。
• • leader负责维护和跟踪ISR中全部follower滞后的状态.
• • 当producer发送一条消息到broker后，leader写入消息并复制到全部follower。消息提交以后才被成功复制到全部的同步副本。消息复制延迟受最慢的follower限制，重要的是快速检测慢副本，若是follower"落后"太多或者失效，leader将会把它从ISR中删除.
• leader 将某个follower提出ISR列表的状况：
• • 1. 按数量——若是leader当前的offset已经到10，可是某个follower同步的数据仍是2，可是kafka对于数量的误差设置为6。若是当前误差小于等于设置的误差，那么会将该follower提出ISR列表，进入到OSR列表[全部的副本数据 = ISR + OSR]
  1. 按时间——有新数据，多久没有发送确认信息

• ISR(副本同步队列)
• • ISR 是全部副本的一个子集，由leader维护ISR列表，follower从leader同步数据有一些延迟，包括延迟时间 replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度，当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度）。任意一个超过阈值都会把follower剔除出ISR，存入OSR(Outof-Sync Replicas)列表，新加入的follower也会先存放在OSR中。
• • leader 新写入的信息，consumer不能马上消费，leader会等待该消息被全部ISR中的replicas同步后更新HW，此时消息才能被consumer消费。这样就保证了若是leader所在的broker失效，该消息仍然能够重新选举的leader中获取。对于来自内部的broker的读取请求，没有HW的限制。
• • 同步复制要求全部的能工做的follower都复制完，这条消息才会被commit，这种复制方式是否极大的影响了吞吐率？
• • 异步复制方式
• • follower异步的从leader复制数据，数据只要被leader写入log就被认为已经commit，这种状况下若是follower都尚未复制完，落后于leader时，忽然leader宕机，则会丢失数据。而kafka的这种使用ISR的方式则很好的均衡了确保数据不丢失已经吞吐率。
• • Kafka的管理最终都会反馈到Zookeeper节点上。
• • 具体位置：/brokers/topics/[topic]/partitions/[partition]/state.
• • 目前有两个地方会对这个Zookeeper的节点进行维护：
• • 1. Controller维护：Controller 下的LeaderSelector会选举新的leader，ISR和新的leader_epoch及controller_epoch写入Zookeeper的相关节点中。同时发起LeaderAndIsrRequest通知全部的replicas。
  1. leader维护：leader有单独的线程按期检测ISR中follower是否脱离ISR，若是发现ISR变化，则会将新的ISR的信息返回到Zookeeper的相关节点中。
• • Kafka集群中的其中一个Broker会被选举为Controller，主要负责Partition管理和副本状态管理，也会执行相似于重分配partition之类的管理任务。
• kafka 数据可靠性
• • 数据丢失的可能:能够采用callback的方式进行处理，判断异常信息是否为空，若是为空表示正常发送了，不然就有异常，可进行特殊处理
• • 当producer向leader发送数据时，能够经过acks参数来设置数据可靠性的级别：
• • 1. 1(默认)：这意味着producer在ISR中的leader已成功收到的数据并获得确认后发送下一条message。若是leader宕机了，则会丢失数据。
• • 1. 0：这意味着producer无需等待来自broker的确认而继续发送下一批消息。这种状况下数据传输效率最高，可是数据可靠性是最低的
• • 1. all：leader须要等待全部备份都写入日志，这种策略会保证只要有一个备份存活就不会丢失数据，这是最强的保证。
• kafka 消息传输保障
• • Kafka确保消息在producer和consumer之间传输。有如下三种可能的传输保障
• • 1. At most once : 消息可能丢失，但毫不会重复传输
• • 1. At least once : 消息毫不会丢，但可能重复传输
• • 1. Exactly once: 每条消息确定会被传输一次且仅传输一次
• kafka leader 和 follower 如何通讯

疑问

• 一个broker服务下，是否能够建立多个分区？
• • 能够，broker数与分区数没有关系
• 一个broker服务下，是否能够建立多个副本因子?
• • 不能够，会报错;

  建立主题时，副本因子应该小于等于可用的broker数

  Error while executing topic command : replication factor: 3 larger than available brokers: 1
  [2019-07-23 17:34:45,963] ERROR org.apache.kafka.common.errors.InvalidReplicationFactorException: replication factor: 3 larger than available brokers: 1
  (kafka.admin.TopicCommand$)

• 在kafka中，每个分区会有一个编号，从0开始
• 当执行删除命令以后，topic不是物理删除，而是一个标记删除的操做.
• 标记删除以后的主题是否还能够继续生产数据？
• • 不会有影响
• 如何保证一个主题下的数据，必定是有序的(生产与消费的顺序一致)
• • 让主题下只有一个分区
• 某一个主题下的分区数，对于消费组来讲，应该小于等于该主题下的分区数。
• 在使用kafka的过程当中，如何保证数据的不丢失，不重复的问题？
• 如何确保Producer不丢失数据?
• ACK (应答机制设置为2)
• Kafka 的用途？使用场景？
• • 消息系统；实时监控或者离线处理；日志收集
• • 异常处理、平常系统削峰、解耦、提速、广播
• Kafka中的ISR、AR表明什么？ISR的伸缩?
• • ISR: In-Sync Replicas 副本同步队列
• • AR: Assigned Replicas 全部副本
• • ISR是由leader维护，follower从leader同步数据有一些延迟(包括延迟时间replica.lag.time.max.ms 和 延迟条数 replica.lag.max.message两个维度，当前最新的版本0.10.x 中只支持replica.lag.time.max.ms这个维度),任意一个超过阈值都会把follower剔除出ISR,存入OSR(Outof-Sync Replicas)列表，新加入的follower也会存放在OSR中。AR=ISR+OSR
• Kafka中的HW、LEO、LSO、LW等分别表明什么？
• • HW: High Watermark 高水位，取一个partition对应的ISR中最小的LEO做为HW，consumer最多只能消费到HW所在的位置上一条信息
• • LEO: LogEndOffset 固然日志文件中下一条代写信息的offset
• • HW/LEO 这两个都是指最后一条的下一条的位置而不是最后一条的位置
• • LSO: Last Stable Offset 对未完成的事务而言，LSO的值等于事务中第一条消息的位置(firstUnstableOffset),对已完成的事务而言，它的值同HW相同
• • LW: Low Watermark 低水位，表明AR集合中最小的logStartOffset值
• Kafka 中是怎么体现消息顺序性的?
• • Kafka每一个partition中的消息在写入是都是有序的，消费时，每一个partition只能被每个group中的消费者消费，保证了消费时也是有序的
• • 整个topic不保证有序。若是为了保证topic整个有序，那么将partition调整为1
• Kafka中的分区器、序列化器、拦截器之间的处理顺序是什么?
• • 拦截器 -> 序列化器 -> 分区器
• Kafka 生产者客户端中使用了几个线程来处理？
• • 2个，主线程和Sender线程。主线程负责建立消息，而后经过分区器、序列化器、拦截器做用以后缓存到累加器RecordAccumulator中。Sender线程负责将RecordAccumulator中消息发送到Kafka中
• 消费者提交消费位移时提交的是当前消费到的最新消息的offset仍是offset+1？
• • offset + 1
• 形成重复消费的缘由：
• • 消费者消费后没有commit offset(程序奔溃/强行kill/消费耗时/自动提交偏移状况下unscrible)
• 形成消息漏消费的缘由:
• • 消费者没有处理完消息，提交offset(自动提交偏移，未处理状况下程序异常结束)
• KafkaConsumer 是非线程安全的，如何实现多线程消费
• • 1. 在每一个线程中建立一个KafkaConsumer
• • 1. 单线程建立KafkaConsumer，多个处理线程处理消息
• 消费者与消费组之间的关系
• • 消费者从属于消费组，消费偏移以消费组为单位。每一个消费组能够独立消费主题的全部数据，同一消费组内消费者共同消费主题数据，每一个分区只能被同一消费组内一个消费者消费
• 使用kafka-topics.sh 建立(删除)了一个topic以后，kafka背后执行了什么逻辑
• • 建立：在zk上 /brokers/topics/下节点 Kafka broker 会监听节点变化建立主题
• • 删除: 调用脚本删除topic会在zk上将topic设置待删除标志，kafka后台有定时线程会扫描全部须要删除的topic进行删除
• 建立topic时如何选择合适的分区数
• • 根据集群的机器数量和须要的吞吐量来决定适合的分区数
• Kafka 目前有哪些内部topic，特征，做用
• • __consumer_offsets 保证消费组的偏移
• 优先副本是什么？有什么特殊做用
• • 默认的leader副本
• • 发送leader变化时重选举会优先选择优先副本做为leader
• Kafka的Log Retention的理解
• • kafka 留存策略包括删除和压缩两种
• • 删除：根据时间和大小两种方式进行删除，大小是整个partition日志文件的大小，超过的会从老到新依次删除；时间指定日志文件中最大时间戳而非文件的最后修改时间
• • 压缩：相同key的value只保存一个 压缩过的是clean 未压缩的dirty 压缩以后的偏移量不连续 未压缩时连续

持续更新...