本文曾经收录到Github仓库，该仓库蕴含计算机根底、Java根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享等外围知识点，欢送star~

Github地址：https://github.com/Tyson0314/Java-learning

Kafka 都有哪些特点？

  • 高吞吐量、低提早：kafka每秒能够解决几十万条音讯，它的提早最低只有几毫秒，每个topic能够分多个partition, consumer group 对partition进行consume操作。
  • 可扩展性：kafka集群反对热扩大
  • 持久性、可靠性：音讯被长久化到本地磁盘，并且反对数据备份避免数据失落
  • 容错性：容许集群中节点失败（若正本数量为n,则容许n-1个节点失败）
  • 高并发：反对数千个客户端同时读写

请简述下你在哪些场景下会抉择 Kafka？

  • 日志收集：一个公司能够用Kafka能够收集各种服务的log，通过kafka以对立接口服务的形式凋谢给各种consumer，例如hadoop、HBase、Solr等。
  • 音讯零碎：解耦和生产者和消费者、缓存音讯等。
  • 用户流动跟踪：Kafka常常被用来记录web用户或者app用户的各种流动，如浏览网页、搜寻、点击等流动，这些流动信息被各个服务器公布到kafka的topic中，而后订阅者通过订阅这些topic来做实时的监控剖析，或者装载到hadoop、数据仓库中做离线剖析和开掘。
  • 经营指标：Kafka也常常用来记录经营监控数据。包含收集各种分布式应用的数据，生产各种操作的集中反馈，比方报警和报告。
  • 流式解决：比方spark streaming和 Flink

Kafka 的设计架构你晓得吗？

Kafka 架构分为以下几个局部：

  • Producer ：音讯生产者，就是向 kafka broker 发消息的客户端。
  • Consumer ：音讯消费者，向 kafka broker 取音讯的客户端。
  • Topic ：能够了解为一个队列，一个 Topic 又分为一个或多个分区，
  • Consumer Group：这是 kafka 用来实现一个 topic 音讯的播送（发给所有的 consumer）和单播（发给任意一个 consumer）的伎俩。一个 topic 能够有多个 Consumer Group。
  • Broker ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 能够包容多个 topic。
  • Partition：为了实现扩展性，一个十分大的 topic 能够散布到多个 broker上，每个 partition 是一个有序的队列。partition 中的每条音讯都会被调配一个有序的id（offset）。将音讯发给 consumer，kafka 只保障按一个 partition 中的音讯的程序，不保障一个 topic 的整体（多个 partition 间）的程序。
  • Offset：kafka 的存储文件都是依照 offset.kafka 来命名，用 offset 做名字的益处是不便查找。例如你想找位于 2049 的地位，只有找到 2048.kafka 的文件即可。当然 the first offset 就是 00000000000.kafka。

Kafka 分区的目标？

分区对于 Kafka 集群的益处是：实现负载平衡。分区对于消费者来说，能够进步并发度，提高效率。

你晓得 Kafka 是如何做到音讯的有序性？

kafka 中的每个 partition 中的音讯在写入时都是有序的，而且独自一个 partition 只能由一个消费者去生产，能够在外面保障音讯的程序性。然而分区之间的音讯是不保障有序的。

Kafka Producer 的执行过程？

1，Producer生产音讯 --> 2，从Zookeeper找到Partition的Leader --> 3，推送音讯 --> 4，通过ISR列表告诉给Follower --> 5， Follower从Leader拉取音讯，并发送ack --> 6，Leader收到所有正本的ack，更新Offset，并向Producer发送ack，示意音讯写入胜利。

讲一下你应用 Kafka Consumer 生产音讯时的线程模型，为何如此设计？

Thread-Per-Consumer Model，这种多线程模型是利用Kafka的topic分多个partition的机制来实现并行：每个线程都有本人的consumer实例，负责生产若干个partition。各个线程之间是齐全独立的，不波及任何线程同步和通信，所以实现起来非常简单。

请谈一谈 Kafka 数据一致性原理

一致性就是说不论是老的 Leader 还是新选举的 Leader，Consumer 都能读到一样的数据。

假如分区的正本为3，其中正本0是 Leader，正本1和正本2是 follower，并且在 ISR 列表外面。尽管正本0曾经写入了 Message4，然而 Consumer 只能读取到 Message2。因为所有的 ISR 都同步了 Message2，只有 High Water Mark 以上的音讯才反对 Consumer 读取，而 High Water Mark 取决于 ISR 列表外面偏移量最小的分区，对应于上图的正本2，这个很相似于木桶原理。

这样做的起因是还没有被足够多正本复制的音讯被认为是“不平安”的，如果 Leader 产生解体，另一个正本成为新 Leader，那么这些音讯很可能失落了。如果咱们容许消费者读取这些音讯，可能就会毁坏一致性。试想，一个消费者从以后 Leader（正本0） 读取并解决了 Message4，这个时候 Leader 挂掉了，选举了正本1为新的 Leader，这时候另一个消费者再去从新的 Leader 读取音讯，发现这个音讯其实并不存在，这就导致了数据不一致性问题。

当然，引入了 High Water Mark 机制，会导致 Broker 间的音讯复制因为某些起因变慢，那么音讯达到消费者的工夫也会随之变长（因为咱们会先期待音讯复制结束）。延迟时间能够通过参数 replica.lag.time.max.ms 参数配置，它指定了正本在复制音讯时可被容许的最大延迟时间。

ISR、OSR、AR 是什么？

ISR：In-Sync Replicas 正本同步队列

OSR：Out-of-Sync Replicas

AR：Assigned Replicas 所有正本

ISR是由leader保护，follower从leader同步数据有一些提早（具体能够参见 图文理解 Kafka 的正本复制机制），超过相应的阈值会把 follower 剔除出 ISR, 存入OSR（Out-of-Sync Replicas ）列表，新退出的follower也会先寄存在OSR中。AR=ISR+OSR。

LEO、HW、LSO、LW等别离代表什么

LEO：是 LogEndOffset 的简称，代表以后日志文件中下一条

HW：水位或水印（watermark）一词，也可称为高水位(high watermark)，通常被用在流式解决畛域（比方Apache Flink、Apache Spark等），以表征元素或事件在基于工夫层面上的进度。在Kafka中，水位的概念反而与工夫无关，而是与地位信息相干。严格来说，它示意的就是地位信息，即位移（offset）。取 partition 对应的 ISR中 最小的 LEO 作为 HW，consumer 最多只能生产到 HW 所在的地位上一条信息。

LSO：是 LastStableOffset 的简称，对未实现的事务而言，LSO 的值等于事务中第一条音讯的地位(firstUnstableOffset)，对已实现的事务而言，它的值同 HW 雷同

LW：Low Watermark 低水位, 代表 AR 汇合中最小的 logStartOffset 值。

数据传输的事务有几种？

数据传输的事务定义通常有以下三种级别：

（1）最多一次: 音讯不会被反复发送，最多被传输一次，但也有可能一次不传输
（2）起码一次: 音讯不会被漏发送，起码被传输一次，但也有可能被反复传输.
（3）准确的一次（Exactly once）: 不会漏传输也不会反复传输,每个音讯都传输被

Kafka 消费者是否能够生产指定分区音讯？

Kafa consumer生产音讯时，向broker收回fetch申请去生产特定分区的音讯，consumer指定音讯在日志中的偏移量（offset），就能够生产从这个地位开始的音讯，customer领有了offset的控制权，能够向后回滚去从新生产之前的音讯，这是很有意义的。

Kafka音讯是采纳Pull模式，还是Push模式？

Kafka最后思考的问题是，customer应该从brokes拉取音讯还是brokers将音讯推送到consumer，也就是pull还push。在这方面，Kafka遵循了一种大部分音讯零碎独特的传统的设计：producer将音讯推送到broker，consumer从broker拉取音讯。

一些音讯零碎比方Scribe和Apache Flume采纳了push模式，将音讯推送到上游的consumer。这样做有益处也有害处：由broker决定音讯推送的速率，对于不同生产速率的consumer就不太好解决了。音讯零碎都致力于让consumer以最大的速率最疾速的生产音讯，但可怜的是，push模式下，当broker推送的速率远大于consumer生产的速率时，consumer恐怕就要解体了。最终Kafka还是选取了传统的pull模式。

Pull模式的另外一个益处是consumer能够自主决定是否批量的从broker拉取数据。Push模式必须在不晓得上游consumer生产能力和生产策略的状况下决定是立刻推送每条音讯还是缓存之后批量推送。如果为了防止consumer解体而采纳较低的推送速率，将可能导致一次只推送较少的音讯而造成节约。Pull模式下，consumer就能够依据本人的生产能力去决定这些策略。

Pull有个毛病是，如果broker没有可供生产的音讯，将导致consumer一直在循环中轮询，直到新音讯到t达。为了防止这点，Kafka有个参数能够让consumer阻塞晓得新音讯达到(当然也能够阻塞晓得音讯的数量达到某个特定的量这样就能够批量发

Kafka 高效文件存储设计特点

Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期革除或删除曾经生产完文件，缩小磁盘占用。

通过索引信息能够疾速定位message和确定response的最大大小。

通过index元数据全副映射到memory，能够防止segment file的IO磁盘操作。

通过索引文件稠密存储，能够大幅升高index文件元数据占用空间大小

Kafka创立Topic时如何将分区搁置到不同的Broker中

正本因子不能大于 Broker 的个数；

第一个分区（编号为0）的第一个正本搁置地位是随机从 brokerList 抉择的；

其余分区的第一个正本搁置地位绝对于第0个分区顺次往后移。也就是如果咱们有5个 Broker，5个分区，假如第一个分区放在第四个 Broker 上，那么第二个分区将会放在第五个 Broker 上；第三个分区将会放在第一个 Broker 上；第四个分区将会放在第二个 Broker 上，顺次类推；

残余的副本相对于第一个正本搁置地位其实是由 nextReplicaShift 决定的，而这个数也是随机产生的

谈一谈 Kafka 的再平衡

在Kafka中，当有新消费者退出或者订阅的topic数发生变化时，会触发Rebalance(再平衡：在同一个消费者组当中，分区的所有权从一个消费者转移到另外一个消费者)机制，Rebalance顾名思义就是从新平衡消费者生产。Rebalance的过程如下：

第一步：所有成员都向coordinator发送申请，申请入组。一旦所有成员都发送了申请，coordinator会从中抉择一个consumer负责leader的角色，并把组成员信息以及订阅信息发给leader。

第二步：leader开始调配生产计划，指明具体哪个consumer负责生产哪些topic的哪些partition。一旦实现调配，leader会将这个计划发给coordinator。coordinator接管到调配计划之后会把计划发给各个consumer，这样组内的所有成员就都晓得本人应该生产哪些分区了。

所以对于Rebalance来说，Coordinator起着至关重要的作用

Kafka 是如何实现高吞吐率的？

Kafka是分布式音讯零碎，须要解决海量的音讯，Kafka的设计是把所有的音讯都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，应用硬盘并没有带来过多的性能损失。kafka次要应用了以下几个形式实现了超高的吞吐率：

  • 程序读写；
  • 零拷贝
  • 文件分段
  • 批量发送
  • 数据压缩。

Kafka 毛病？

  • 因为是批量发送，数据并非真正的实时；
  • 对于mqtt协定不反对；
  • 不支持物联网传感数据间接接入；
  • 仅反对对立分区内音讯有序，无奈实现全局音讯有序；
  • 监控不欠缺，须要装置插件；
  • 依赖zookeeper进行元数据管理；

Kafka 新旧消费者的区别

旧的 Kafka 消费者 API 次要包含：SimpleConsumer（简略消费者） 和 ZookeeperConsumerConnectir（高级消费者）。SimpleConsumer 名字看起来是简略消费者，然而其实用起来很不简单，能够应用它从特定的分区和偏移量开始读取音讯。高级消费者和当初新的消费者有点像，有消费者群组，有分区再平衡，不过它应用 ZK 来治理消费者群组，并不具备偏移量和再平衡的可操控性。

当初的消费者同时反对以上两种行为，所以为啥还用旧消费者 API 呢？

Kafka 分区数能够减少或缩小吗？为什么？

咱们能够应用 bin/kafka-topics.sh 命令对 Kafka 减少 Kafka 的分区数据，然而 Kafka 不反对缩小分区数。

Kafka 分区数据不反对缩小是由很多起因的，比方缩小的分区其数据放到哪里去？是删除，还是保留？删除的话，那么这些没生产的音讯不就丢了。如果保留这些音讯如何放到其余分区外面？追加到其余分区前面的话那么就毁坏了 Kafka 单个分区的有序性。如果要保障删除分区数据插入到其余分区保障有序性，那么实现起来逻辑就会非常复杂。

最初给大家分享一个Github仓库，下面有大彬整顿的300多本经典的计算机书籍PDF，包含C语言、C++、Java、Python、前端、数据库、操作系统、计算机网络、数据结构和算法、机器学习、编程人生等，能够star一下，下次找书间接在下面搜寻，仓库继续更新中~

Github地址：https://github.com/Tyson0314/java-books