(100%)kafka产品生态与kafka面试题

https://github.com/confluentinc/ksql

Kafak的核心主要有Broker，Topic，日志，分区和集群。

该核心还包括相关的工具，如MirrorMaker

Kafka Stream是一种Streams API，用于从流中转换，汇总和处理记录，并生成衍生流。

Kafka Connect是创建可重用的生产者和消费者的连接器API（例如DynamoDB的更改流）。

通过REST（HTTP），Kafka REST代理用于生产者和消费者。

Schema Registry使用Kafka记录的Avro来管理Schema。 

Kafka MirrorMaker用于将集群的数据复制到另一个集群。

Kafka Connect Source，Kafka Connect Sink和Kafka Stream的图

Kafka REST代理和Confluent Schema Registry

什么是Kafka Stream(流)？ 

什么是Kafka Connect(连接)？

什么是Schema Registry？

什么是Kafka Mirror Maker？

你什么时候可能需要使用Kafka REST代理？

LinkedIn工程师构建Kafka用来支持实时分析。

Kafka旨在为实时流处理提供分析系统。 

LinkedIn开发了Kafka作为流数据源实时处理的统一平台。 

Kafka背后的目标是建立一个高吞吐量的流式数据平台，支持大量的事件流，如日志聚合，用户活动等。

为了扩展以满足LinkedIn Kafka的需求，它支持分布式，分片和负载均衡。

实现扩展需要启发的Kafka分区和消费者模型。

Kafka使用分区，分布式，提交日志来对写入和读取进行扩展或缩放。 

Kafka的分片称为分区（Kinesis，类似于Kafka，称为分区“碎片”）。

根据维基百科，“数据库碎片是数据库或搜索引擎中数据的水平分区，每个分区称为分片或数据库分片，每个分片都保存在单独的数据库服务器实例上，以传播负载。 

Kafka旨在处理来自离线系统以及传统消息用例（低延迟）的定期的大量数据负载。 

MOM是面向消息的中间件;

就像IBM MQSeries，JMS，ActiveMQ和RabbitMQ等MOM一样，Kafka通过复制和Leader选举对节点故障进行容错。

然而，Kafka的设计更像是一个分布式数据库事务日志，而不是传统的消息系统。

与许多MOM不同，Kafka复制被构建在低级设计中，而不是事后的想法。

Kafka依赖文件系统来存储和缓存记录。  硬盘驱动器的顺序写入性能很快（真的很快）。 JBOD只是一堆磁盘驱动器。具有六个7200rpm SATA RAID-5阵列的JBOD写入性能大概为600MB /秒。像Cassandra表一样，Kafka日志是只写结构，意思是数据追加到日志末尾。当使用HDD时，操作系统可进行快速的、可预测的和优化的顺序读写。使用HDD，顺序磁盘存取比随机存储器和SSD更快。  虽然JVM GC的开销可能很高，但Kafka倾向于操作系统来获取大而快速的坚实缓存。而且，现代操作系统使用所有可用的主存进行磁盘缓存。操作系统的文件缓存几乎是免费的，没有操作系统的开销。实现正确的缓存一致性是一个挑战，但Kafka依赖于牢固的OS来实现缓存一致性。使用操作系统进行缓存也减少了缓冲区副本的数量。由于Kafka磁盘使用往往会执行顺序读取，因此操作系统预读缓存令人印象深刻。  Cassandra，Netty和Varnish使用类似的技术。所有这些都在Kafka文档中得到了很好的解释，而且在Varnish网站上也有更多有趣的解释。

Kafka喜欢用于读写的长顺序磁盘存取。就像Cassandra，LevelDB，RocksDB和其他的，Kafka使用一种日志结构化存储和压缩的形式而不是以磁盘上可变的BTree的形式。像Cassandra一样，Kafka使用tombstone而不是立即删除记录。 



由于现在的磁盘有一些速度非常快且无限的空间，所以Kafka可以提供消息传递系统中通常不存在的功能，比如持续使用旧的消息。这种灵活性允许Kafka服务些有趣的应用。

生产者向Kafka的Broker索要哪个Kafka Broker拥有哪个Topic分区Leader而不需要路由层的元数据。这种领导关系数据允许生产者直接向Kafka Broker分区领导者发送记录。 



生产者客户端控制哪个分区发布消息，并可以根据某些应用程序逻辑选择一个分区。生产者可以通过key，随机循环或使用自定义应用程序特定的分区逻辑来对记录进行分区。

Kafka生产者支持记录的批处理。批处理可以按批量记录的字节大小进行配置。批量记录可以根据时间自动刷新。 



批处理对网络IO吞吐量有好处，并大大加快了吞吐量。  



缓冲是可配置的，您可以权衡延迟来获得更好的吞吐量。或在负载很重的系统中可以有更好的平均吞吐量和更低的总体延迟。 



批处理允许累积更多的字节进行发送，这相当于Kafka Brokers上一些较大的I / O操作，并提高了压缩效率。为了提高吞吐量，Kafka Producer配置允许基于时间和大小的缓冲。生产者以较少的网络请求发送多条记录，而不是逐个发送每条记录。

在大型流媒体平台中，瓶颈并不总是CPU或磁盘，而是网络带宽。作为多个服务可以共享NiC卡的容器化和虚拟化的云存在更多的网络带宽问题。此外，当将数据中心与数据中心或WAN通信时，更可能会带来网络带宽问题。



批处理有利于高效的压缩和网络IO吞吐量。  



Kafka提供端对端批量压缩，而不是一次压缩一条记录，Kafka可有效一次压缩一批记录。相同的消息批次可以一次性压缩并发送到Kafka代理/服务器，并以压缩形式写入日志分区。您甚至可以配置压缩，以便在Kafka代理将压缩记录提供给消费者之前不发生解压缩。 



Kafka支持GZIP，Snappy和LZ4压缩协议。

Kafka消费者从Broker那里抽取数据。其他系统的Borker推送数据或流数据到消费者。消息通常是一个基于拉的系统（SQS，大多数MOM使用拉模式）。在拉式的系统中，如果一个消费者落后了，那么它可以稍后赶上。 



由于Kafka是基于拉模式的，它实现了批处理数据的聚合。就像许多其它基于拉模式的系统一样，Kafka实现了长轮询（SQS和Kafka所做的）。长轮询在请求一段时间后会保持连接打开状态，并等待响应。 



基于拉模式的系统必须拉取数据，然后处理它，并且拉取和获取数据之间总是有一个暂停。 



基于推送的系统会将数据推送给消费者（scribe，flume，反应流，RxJava，Akka）。基于推送或流式传输的系统在处理缓慢或死亡的消费者方面存在些问题。在推送系统中，如果消费者的消费速度低于生产者的生产速率时可能会被压垮。一些基于推送的系统使用基于背压的回退协议，其允许消费者指示它被所看到的反应流被压垮了。当尝试跟踪消息确认时，不冲垮消费者和对消费者进行恢复通常是棘手的。 



基于推送或流式传输的系统可以立即发送请求或累积请求并分批发送（或基于背压的组合）。基于推送的系统总是推送数据。消费者在处理已发送的数据时候累积消息来降低消息处理的延迟。然而，如果消费者在处理过程中死亡，那么Broker如何知道消费者在哪里，数据何时再次发送给另一个消费者,这个问题不容易解决。Kafka通过使用基于拉式的系统来解决这些复杂问题。

传统MOM消费者消息状态跟踪 

Kafka消费者消息状态跟踪 

有三种消息传递语义：至多一次，至少一次，仅一次。

最多一次时消息可能会丢失但不会重新投递。

至少一次是消息永远不会丢失，但可能会重新被投递。

仅一次是消息只发送一次。

仅一次是首选但更昂贵，并且需要更多的生产者和消费者的簿记。

Kafka消费者和消息传递语义 

Kafka提供了可持续性操作的可预测性的语义。发布消息时，消息将“提交”到日志中，这意味着所有的ISR都接受了消息。只要至少有一个副本存在，则这个提交策略就可以有很好的持久性。  生产者的连接可能会在发送中间下降，生产者可能无法确定其发送的消息是否会通过，然后生产者会重新发送消息。这个重新发送逻辑就是为什么使用消息Key和使用幂等消息（重复确定）很重要的原因。Kafka并没有保证从生产者重新尝试得到的消息不会重复。   生产者可以重新发送消息，直到收到确认，即确认被收到了。生产者重新发送消息而不需知道其发送的其他消息是否发出了，消除了“一次”和“最多一次”的消息传递语义。

生产者耐用性 

改进的生产者（2017年6月发行的版本） 

Kafka生产者的原子日志写（2017年6月发行的版本） 

以下是使用新的生产者API的示例。 

Kafka通过可配置数量的Kafka Broker复制每个主题的分区。

默认情况下，Kafka的复制模型不是像大多数MOM一样的螺栓功能，因为Kafka从一开始就要使用分区和多节点。

每个主题分区有一个领导和零个或多个追随者。


领导者和追随者被称为副本。

复制因子是领导节点加上所有追随者。

Kafka Broker平均分享分区领导权。

消费者只能从领导者那里读取。

生产者只能写给领导者。 

追随者上的主题日志分区与领导者的日志保持同步，ISR是领导者的精确副本减去正在运行中所需要复制的记录。追随者就像一个普通的Kafka消费者一样从他们的领导人那里批量拉取记录。

Kafka跟踪哪些Kafka的Broker还活着。

为了活着，Kafka Broker必须使用ZooKeeper的心跳机制来保持ZooKeeper会话，并且必须让所有跟随者与领导者同步而不能落后太远。 


对于被称为同步的代理活动，ZooKeeper的会话和同步都是必需的。

同步副本称为ISR。

每个领导者都会跟踪一组“同步副本”。  


如果ISR /追随者死亡或落后了，则领导者将从该组ISR中移除跟随者。

落后是指在一个replica.lag.time.max.ms时间段后，副本未处于同步。  


当所有ISR将消息应用于其日志时，消息被视为“已提交”。

消费者只看到已提交的消息。

kafka保证：只要有至少一个ISR，承诺的邮件就不会丢失。

Kafka的分区是一个复制的日志。

复制的日志是分布式数据系统原语。

复制的日志对于使用状态机实现其他分布式系统非常有用。

复制日志模型在一系列有价值的数据上达成共识。 


当领导者活着的时候，所有的追随者只需要从他们的领导中复制值和顺序。

如果领导者死亡，Kafka从同步的追随者中选出一个新的领导者。

如果一个生产者被告知信息已经被提交了，然后领导者失败了，那么新当选的领导者就必须有这个已提交的消息。 

你拥有越多的ISR，在领导失败的时候就会要更多的选举。

法定人数是所需确认的数量和必须比较的日志数量，以选择领导者，以确保可用性。

大多数系统使用多数投票，Kafka不会使用简单的多数投票来提高可用性。 

在Kafka里，基于完整的日志来选举领导者。

如果我们的复制因子为3，则在领导者声明发送的消息已提交之前，至少要有两个ISR必须处于同步。

如果一个新的领导人需要当选，那么新的领导人不能失败超过3次，新的领导人要确保有所有提交的消息。 


在跟随者中，必须至少要有一个副本包含了所有已提交的消息。

多票法定人数的问题是它不会采取多次失败来获得一个不可操作的集群。

多数ISR的Kafka法定人数 

Kafka为每个领导者维护了一些ISR。

只有ISR里的成员才有资格进行领导选举。

在所有ISR确认写之前，生产者对分区的写入都不会被提交。

每当ISR设置更改时，ISR将持久到ZooKeeper中。

只有作为ISR成员的副本才有资格当选领导者。 


这种风格的ISR仲裁允许生产者在没有大部分节点的情况下继续工作，但只是一个ISR的多数投票。

这种风格的ISR仲裁还允许一个副本重新加入到ISR集中并具有其投票数，但是在加入之前必须完全重新同步，即使副本在其崩溃期间丢失了未刷新的数据。

Kafka对数据丢失的保证仅在至少一个副本同步时才有效。 

如果正在复制一个分区的领导者下的所有追随者同时死亡，则数据会丢失，Kafka会保证数据无效。

如果一个分区的所有副本都down了，则默认情况下，Kafka会选取第一个副本作为领导者（不一定在ISR集中）（config unclean.leader.election.enable = true是默认值）。

这种选择有利于可靠性的一致性。  


如果一致性比您用例的可用性更重要，那么您可以设置config unclean.leader.election.enable = false，
然后如果一个分区的所有副本都down了，则Kafka等待第一个存在的ISR成员（不是第一个副本）选举成为新领导人。

生产者可以通过将acks设置为 -  
    没有（0），仅限于（1）或所有副本（-1）来选择持久性。 

acks = all是默认值。

当所有当前的同步复制（ISR）收到消息时，都会发生ack。  

您可以在一致性和可用性之间进行权衡。

如果优先于可用性的耐久性，则禁用不好的领导者选举，并指定最小的ISR大小。  

①、最小ISR大小越高，一致性的保证会越好。

②、但是如果ISR集的大小小于最小阈值，则ISR的最小值越小，则会降低分区的可用性因为分区对写入不可用。

Kafka有对消费者和生产者的配额限制来限制他们对带宽的消费。

这些配额阻止消费者或生产者摆脱所有Kafka Broker的资源。

配额是客户端ID或用户。

配额数据存储在ZooKeeper中，所以更改不需要重新启动Kafka的Broker。

使用配额来限制消费者的带宽。

所有。这意味着所有ISR必须将消息写入其日志分区。

Kafka选择第一个副本不一定在ISR集合中）作为领导者因为unclean.leader.election.enable = true默认用于支持可用性。

通过电线以及磁盘优化IO吞吐量。它还通过压缩整个批次来提高压缩效率。

成为高吞吐量，可扩展的流数据平台，用于实时分析大量事件流，如日志聚合，用户活动等。

生产者原子写入，性能改进和生产者不发送重复的消息。

有三种消息传递语义：至多一次，至少一次，仅一次。