深入理解 Kafka

 

1. Kafka中有哪几个主要组件?

     主题：Kafka主题是一堆或一组消息。

     生产者：在Kafka，生产者发布通信以及向Kafka主题发布消息。

     消费者：Kafka消费者订阅了一个主题，并且还从主题中读取和处理消息。

     经纪人：在管理主题中的消息存储时，我们使用Kafka Brokers。

2. 什么是 kafka Rebalance？以及rebalance触发的时机？

     2.1、什么是 RebalanceRebalance 本质上是一种协议，规定了一个 Consumer Group 下的所有 consumer 如何达成一致，来分配订阅Topic 的每个分区。

     例如：某 Group 下有 20 个 consumer 实例，它订阅了一个具有 100 个 partition 的 Topic 。正常情况下，kafka 会为每个 Consumer 平均的分配 5 个分区。这个分配的过程就是 Rebalance。

     2.2、触发 Rebalance 的时机Rebalance 的触发条件有3个。组成员个数发生变化。例如有新的 consumer 实例加入该消费组或者离开组。

     订阅的 Topic 个数发生变化。

     订阅 Topic 的分区数发生变化。

     Rebalance 发生时，Group 下所有 consumer 实例都会协调在一起共同参与，kafka 能够保证尽量达到最公平的分配。但是 Rebalance 过程对 consumer group 会造成比较严重的影响。在 Rebalance 的过程中 consumer group 下的所有消费者实例都会停止工作，等待 Rebalance 过程完成。

3. 谈谈你对kafka消费者组的理解？

     同样是逻辑上的概念，是Kafka实现单播和广播两种消息模型的手段。同一个topic的数据，会广播给不同的

     group；同一个group中的worker，只有一个worker能拿到这个数据。换句话说，对于同一个topic，每个

     group都可以拿到同样的所有数据，但是数据进入group后只能被其中的一个worker消费。group内的worker

     可以使用多线程或多进程来实现，也可以将进程分散在多台机器上，worker的数量通常不超过partition的数

     量，且二者最好保持整数倍关系，因为Kafka在设计时假定了一个partition只能被一个worker消费（同一group内）。消费组，即Consumer Group ,应该算是kafka比较有创意的设计了。那么何谓ConsumerGroup呢？用一句话概括就是：ConsumerGroup是kafka提供的可扩展且具有容错性的消费者机制。既然是一个组，那么组内必然可以有多个消费者和消费者实列，他们共享一个公共的ID，这个ID被称为GroupID。组内的消费者协调在一起消费订阅主题的所有分区。当然，每个分区只能由同一个消费者组内的一个Consumer实列来消费。

     ConsumerGroup之间批次独立，互不影响，他们能订阅相同的主题而互不干涉。kafka仅仅使用consumer Group

     这一种机制，却实现了传统消息引擎系统的俩大模型：如果所有实列属于同一个Group，那么它实现的就是消息队列模型；如果所有实列分别属于不同的Group，那么他实现的就是发布/订阅模型。

     理想情况下，Group中的Consumer实列的数量应该等于该Group订阅主题的总分区数。

     ConsumerGroup的位移也是提交到Broker中的内部主题中的_consumer_offsets

     ConsumerGroup中的consumer实列数在理想情况下是等于订阅主题的分区总数的。

     （Group中的分区只能被同一消费组下的一个消费者消费，一个消费者可以消费多个分区）

     有三种情况：

     缓冲和削峰：上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢慢处理。

     解耦和扩展性：项目开始的时候，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。

     冗余：可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费到，供多个毫无关联的业务使用。

     健壮性：消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。

     异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

   1. 消费者实列数小于分区数：这种情况会下，一个消费者实列会消费多个分区

   2. 消费者实列数等于分区数： 一个消费者消费一个分区

   3. 消费者实列数大于分区数：会有几个消费者处于空闲的状态下。

   4. 为什么要使用 kafka，为什么要使用消息队列

4. Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么

     ISR:In-Sync Replicas 副本同步队列 AR:Assigned Replicas 所有副本 ISR是由leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR, 倘若该副本后面慢慢地追上了 Leader 的进度，那么它是能够重新被加回 ISR 的，存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

5. kafka中的broker 是干什么的

     broker 是消息的代理，Producers往Brokers里面的指定Topic中写消息，Consumers从Brokers里面拉取指定Topic的消息，然后进行业务处理，broker在中间起到一个代理保存消息的中转站。

6. kafka中的 zookeeper 起到什么作用，可以不用zookeeper么

     zookeeper 是一个分布式的协调组件，早期版本的kafka用zk做meta信息存储，consumer的消费状态，group的管理以及 offset的值。考虑到zk本身的一些因素以及整个架构较大概率存在单点问题，新版本中逐渐弱化了zookeeper的作用。新的consumer使用了kafka内部的group coordination协议，也减少了对zookeeper的依赖，

     但是broker依然依赖于ZK，zookeeper 在kafka中还用来选举controller 和 检测broker是否存活等等。

7. kafka follower如何与leader同步数据

     Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下，如果leader挂掉，会丢失数据，kafka使用ISR的方式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。

8. kafka 为什么那么快

     分区机制

     二分算法、哈希算法

     Cache Filesystem Cache PageCache缓存

     顺序写 由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。

     Zero-copy 零拷技术减少拷贝次数

     Batching of Messages 批量量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。

     Pull 拉模式 使用拉模式进行消息的获取消费，与消费端处理能力相符。

9. kafka producer如何优化打入速度

     增加线程

     提高 batch.size

     增加更多 producer 实例

     增加 partition 数

     设置 acks=-1 时，如果延迟增大：可以增大 num.replica.fetchers（follower 同步数据的线程数）来调解；

     跨数据中心的传输：增加 socket 缓冲区设置以及 OS tcp 缓冲区设置。

10. kafka有哪几种ack机制，ack为 0， 1， -1 的时候代表啥

      11.1、设置为0：

      意味着producer不等待broker同步完成的确认，继续发送下一条(批)信息提供了最低的延迟。但是最弱的持久性，当服务器发生故障时，就很可能发生数据丢失。例如leader已经死亡，producer不知情，还会继续发送消息broker接收不到数据就会数据丢失。

      11.2、设置为1：

      意味着producer要等待leader成功收到数据并得到确认，才发送下一条message。此选项提供了较好的持久性较低

      的延迟性。Partition的Leader死亡，follwer尚未复制，数据就会丢失。

      11.3、设置为-1：

      意味着producer得到follwer确认，才发送下一条数据持久性最好，延时性最差。三种机制性能递减，可靠性递增。

11. Kafka中是怎么体现消息顺序性的？

      kafka每个partition中的消息在写入时都是有序的，消费时，每个partition只能被每一个group中的一个消费者消

      费，保证了消费时也是有序的。 整个topic不保证有序。如果为了保证topic整个有序，那么将partition调整为1.

12. Kafka支持读写分离吗？为什么？

      Redis和MySQL都支持主从读写分离，我个人觉得这和它们的使用场景有关。对于那种读操作很多而写操作相对不频繁的负载类型而言，采用读写分离是非常不错的方案——我们可以添加很多follower横向扩展，提升读操作性能。反观Kafka，它的主要场景还是在消息引擎而不是以数据存储的方式对外提供读服务，通常涉及频繁地生产消息和消费消息，这不属于典型的读多写少场景，因此读写分离方案在这个场景下并不太适合。

      在 Kafka 中，生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的，从 而实现的是一种主写主读的生产消费模型。Kafka 并不支持主写从读，因为主写从读有 2 个很明 显的缺点:

      (1)数据一致性问题。数据从主节点转到从节点必然会有一个延时的时间窗口，这个时间 窗口会导致主从节点之间的数据不一致。某一时刻，在主节点和从节点中 A 数据的值都为 X， 之后将主节点中 A 的值修改为 Y，那么在这个变更通知到从节点之前，应用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不一致的问题。

      (2)延时问题。类似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程需要经 历网络→主节点内存→网络→从节点内存这几个阶段，整个过程会耗费一定的时间。而在 Kafka 中，主从同步会比 Redis 更加耗时，它需要经历网络→主节点内存→主节点磁盘→网络→从节 点内存→从节点磁盘这几个阶段。对延时敏感的应用而言，主写从读的功能并不太适用。这道题目考察的是你对 Leader/Follower 模型的思考。

      Leader/Follower 模型并没有规定 Follower 副本不可以对外提供读服务。很多框架都是允 许这么做的，只是 Kafka最初为了避免不一致性的问题，而采用了让 Leader 统一提供服 务的方式。

      不过，在开始回答这道题时，你可以率先亮出观点:自 Kafka 2.4 之后，Kafka 提供了有限度的读写分离，也就是

      说，Follower 副本能够对外提供读服务。说完这些之后，你可以再给出之前的版本不支持读写分离的理由。

      场景不适用。读写分离适用于那种读负载很大，而写操作相对不频繁的场景，可 Kafka 不属于这样的场景。

      同步机制。Kafka 采用 PULL 方式实现 Follower 的同步，因此，Follower 与 Leader 存 在不一致性窗口。如果

      允许读 Follower 副本，就势必要处理消息滞后(Lagging)的问题。

13. 消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1?offset+1

14. Kafa consumer 是否可以消费指定分区消息？

      Kafa consumer 消费消息时，向 broker 发出"fetch"请求去消费特定分区的消息，consumer

      指定消息在日志中的偏移量（offset），就可以消费从这个位置开始的消息，customer 拥有

      了 offset 的控制权，可以向后回滚去重新消费之前的消息，这是很有意义的

15. Kafka 消息是采用 Pull 模式，还是 Push 模式？生产者push推送，消费者pull拉取

16. 比较RabbitMQ与Apache Kafka【频率比上面的题要高，重点】

      在应用场景方面 RabbitMQ RabbitMQ遵循AMQP协议，由内在高并发的erlanng语言开发，用在实时的对可靠性要求比较高的消息传递上，适合分布式事务，也是比较受到大家欢迎的。 kafka kafka是Linkedin于2010年12月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。常用日志采集，数据采集，Web活动跟踪上，企业服务总线。

      在架构模型方面， RabbitMQ RabbitMQ遵循AMQP协议，RabbitMQ的broker由Exchange,Binding,queue组成，

      其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费（长连接，queue有消息会推送到consumer端，consumer循环从输入流读取数据）。

      rabbitMQ以broker为中心；有消息的确认机制。 kafka kafka遵从一般的MQ结构，producer，broker，

      consumer，以consumer为中心，消息的消费信息保存的客户端consumer上，consumer根据消费的点，从broker上批量pull数据；无消息确认机制。 在吞吐量 kafka kafka具有高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量操作，具有O(1)的复杂度，消息处理的效率很高。 rabbitMQ

      rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不一样，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操作；基于存储的可靠性的要求存储可以采用内存或者硬盘。 在可用性方面， rabbitMQ rabbitMQ支持miror的queue，主queue失效，miror queue接管。 kafka kafka的broker支持主备模式。 在集群负载均衡方面，kafka kafka采用zookeeper对集群中的broker、consumer进行管理，可以注册topic到zookeeper上；通过

      zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；并且producer可以基于语义指定分片，消息发送到broker的某分片上。 rabbitMQ 4种集群模式，主流的是镜像模式。

      可拓展方面kafka可以通过增加分区进行扩展，而不需要通过添加额外的节点而在运行中造成任何停机。

【推荐】

最佳实践-PB级日志收集智能分析系统-LCA