qq_3316359388的博客

kafka中所有的请求都是通过 TCP 网络以 Socket 的方式进行通讯的。Kafka Broker 端处理请求的全流程：1.顺序处理请求。while (true) { Request request = accept(connection); handle(request);}这个方法吞吐量太差，只适用于请求发送非常不频繁的系统。每个请求使用单独线程处理。为每个入站请求都创建一个新的线程来异步处理。while (true) {

副本机制有什么好处？1.提供数据冗余。即使系统部分组件失效，系统依然能够继续运转，因而增加了整体可用性以及数据持久性。2.提供高伸缩性。支持横向扩展，能够通过增加机器的方式来提升读性能，进而提高读操作吞吐量。3.改善数据局部性。允许将数据放入与用户地理位置相近的地方，从而降低系统延时。kafka目前只能享受到副本机制带来的第 1 个好处，也就是提供数据冗余实现高可用性和高持久性。Kafka 是有主题概念的，而每个主题又进一步划分成若干个分区。kafka副本的概念实际上是在分区层级下定义的，每个分区

对于 Kafka 消费者，最重要的就是监控它们的消费进度，或者说监控它们消费的滞后程度（消费者 Lag 或 Consumer Lag）。所谓滞后程度，就是指消费者当前落后于生产者的程度。Lag 的单位是消息数。我们一般是在主题这个级别上讨论 Lag 的，但实际上，Kafka 监控 Lag 的层级是在分区上的。如果要计算主题级别的，你需要手动汇总所有主题分区的 Lag，将它们累加起来，合并成最终的 Lag 值。一个正常工作的消费者，它的 Lag 值应该很小，甚至是接近于 0 的，这表示该消费者能够及时地消

何时创建 TCP 连接？和生产者不同的是，构建 KafkaConsumer 实例时是不会创建任何 TCP 连接的，TCP 连接是在调用 KafkaConsumer.poll 方法时被创建的。再细粒度地说，在 poll 方法内部有 3 个时机可以创建 TCP 连接。1.发起 FindCoordinator 请求时。Coordinator是消费者端的一个组件，驻留在 Broker 端的内存中，负责消费者组的组成员管理和各个消费者的位移提交管理。当消费者程序首次启动调用 poll 方法时，它需要向 Kafk

Kafka Java Consumer 是单线程的设计。Kafka Java Consumer 设计原理谈到 Java Consumer API，最重要的当属它的入口类 KafkaConsumer 了。我们说 KafkaConsumer 是单线程的设计，严格来说这是不准确的。因为，从 Kafka 0.10.1.0 版本开始，KafkaConsumer 就变为了双线程的设计，即用户主线程和心跳线程。所谓用户主线程，就是你启动 Consumer 应用程序 main 方法的那个线程，而新引入的心跳线程（He

所谓 CommitFailedException，顾名思义就是 Consumer 客户端在提交位移时出现了错误或异常，而且还是那种不可恢复的严重异常。如果异常是可恢复的瞬时错误，提交位移的 API 自己就能规避它们了，因为很多提交位移的 API 方法是支持自动错误重试的，比如我们在上一期中提到的commitSync 方法。Commit cannot be completed since the group has already rebalanced and assigned the partitions

Consumer 的消费位移，它记录了 Consumer 要消费的下一条消息的位移。切记是下一条消息的位移，而不是目前最新消费消息的位移。从用户的角度来说，位移提交分为自动提交和手动提交；从 Consumer 端的角度来说，位移提交分为同步提交和异步提交。开启自动提交位移的方法很简单。Consumer 端有个参数 enable.auto.commit，把它设置为 true 或者压根不设置它就可以了。它的默认值就是 true，如果启用了自动提交，Consumer 端还有个参数就派上用场了：auto.com

在 Rebalance 过程中，所有 Consumer 实例共同参与，在协调者组件的帮助下，完成订阅主题分区的分配。但是，在整个过程中，所有实例都不能消费任何消息，因此它对 Consumer 的 TPS 影响很大。所谓协调者，在 Kafka 中对应的术语是 Coordinator，它专门为 Consumer Group 服务，负责为 Group 执行 Rebalance 以及提供位移管理和组成员管理等。具体来讲，Consumer 端应用程序在提交位移时，其实是向 Coordinator 所在的 Brok

__consumer_offsets（两个下划线） 在 Kafka 源码中有个更为正式的名字，叫位移主题，即 Offsets Topic。新版本 Consumer 的位移管理机制就是将 Consumer 的位移数据作为一条条普通的 Kafka 消息，提交到 __consumer_offsets 中。可以这么说，__consumer_offsets 的主要作用是保存 Kafka 消费者的位移信息。它要求这个提交过程不仅要实现高持久性，还要支持高频的写操作。位移主题就是普通的 Kafka 主题。你可以手动地

Consumer Group 是 Kafka 提供的可扩展且具有容错性的消费者机制。既然是一个组，那么组内必然可以有多个消费者或消费者实例（Consumer Instance），它们共享一个公共的 ID，这个 ID 被称为 Group ID。组内的所有消费者协调在一起来消费订阅主题（Subscribed Topics）的所有分区（Partition）。每个分区只能由同一个消费者组内的一个 Consumer 实例来消费。Consumer Group 三个特性：1.Consumer Group 下可以有

所谓的消息交付可靠性保障，是指 Kafka 对 Producer 和 Consumer 要处理的消息提供什么样的承诺。常见的承诺有以下三种：最多一次（at most once）：消息可能会丢失，但绝不会被重复发送。至少一次（at least once）：消息不会丢失，但有可能被重复发送。精确一次（exactly once）：消息不会丢失，也不会被重复发送。目前，Kafka 默认提供的交付可靠性保障是第二种，即至少一次。只有 Broker 成功“提交”消息且 Producer 接到 Broker

为何采用 TCP？1.在开发客户端时，人们能够利用 TCP 本身提供的一些高级功能，比如多路复用请求以及同时轮询多个连接的能力。所谓的多路复用请求，即 multiplexing request，是指将两个或多个数据流合并到底层单一物理连接中的过程。TCP 的多路复用请求会在一条物理连接上创建若干个虚拟连接，每个虚拟连接负责流转各自对应的数据流。其实严格来说，TCP 并不能多路复用，它只是提供可靠的消息交付语义保证，比如自动重传丢失的报文。更严谨地说，作为一个基于报文的协议，TCP 能够被用于多路复用连

Kafka 拦截器分为生产者拦截器和消费者拦截器。生产者拦截器允许你在发送消息前以及消息提交成功后植入你的拦截器逻辑；而消费者拦截器支持在消费消息前以及提交位移后编写特定逻辑。值得一提的是，这两种拦截器都支持链的方式，即你可以将一组拦截器串连成一个大的拦截器，Kafka 会按照添加顺序依次执行拦截器逻辑。当前 Kafka 拦截器的设置方法是通过参数配置完成的。生产者和消费者两端有一个相同的参数，名字叫 interceptor.classes，它指定的是一组类的列表，每个类就是特定逻辑的拦截器实现类。拿上面

Kafka 只对“已提交”的消息（committed message）做有限度的持久化保证。也就是说，kafka收到了消息，并且满足配置好的参数条件，就认为是收到这是已提交消息。注意事项：1.Producer 永远要使用带有回调通知的发送 API，也就是说不要使用 producer.send(msg)，而要使用 producer.send(msg, callback)。不要小瞧这里的 callback（回调），它能准确地告诉你消息是否真的提交成功了。一旦出现消息提交失败的情况，你就可以有针对性地进行处

目前 Kafka 共有两大类消息格式，社区分别称之为 V1 版本和 V2 版本。V2 版本是 Kafka 0.11.0.0 中正式引入的。不论是哪个版本，Kafka 的消息层次都分为两层：消息集合（message set）以及消息（message）。一个消息集合中包含若干条日志项（record item），而日志项才是真正封装消息的地方。Kafka 底层的消息日志由一系列消息集合日志项组成。Kafka 通常不会直接操作具体的一条条消息，它总是在消息集合这个层面上进行写入操作。那么社区引入 V2 版本的目

为什么不像redis和mysql可以支持主从分离呢，是因为什么原因要这么设计呢？首先明确一下：主从分离与否没有绝对的优劣，它仅仅是一种架构设计，各自有适用的场景。第二、如你所说，Redis和MySQL都支持主从读写分离，我个人觉得这和它们的使用场景有关。对于那种读操作很多而写操作相对不频繁的负载类型而言，采用读写分离是非常不错的方案——我们可以添加很多follower横向扩展，提升读操作性能。反观Kafka，它的主要场景还是在消息引擎而不是以数据存储的方式对外提供读服务，通常涉及频繁地生产消息和消费消息

我们在使用 Apache Kafka 生产和消费消息的时候，肯定是希望能够将数据均匀地分配到所有服务器上。比如很多公司使用 Kafka 收集应用服务器的日志数据，这种数据都是很多的，特别是对于那种大批量机器组成的集群环境，每分钟产生的日志量都能以 GB 数，因此如何将这么大的数据量均匀地分配到 Kafka 的各个 Broker 上，就成为一个非常重要的问题。kafka为什么使用分区的概念而不是直接使用多个主题呢？其实分区的作用就是提供负载均衡的能力，或者说对数据进行分区的主要原因，就是为了实现系统的高伸

Broker 端参数首先 Broker 是需要配置存储信息的，即 Broker 使用哪些磁盘。那么针对存储信息的重要参数有以下这么几个：1.log.dirs：这是非常重要的参数，指定了 Broker 需要使用的若干个文件目录路径。要知道这个参数是没有默认值的，这说明什么？这说明它必须由你亲自指定。2.log.dir：注意这是 dir，结尾没有 s，说明它只能表示单个路径，它是补充上一个参数用的。这两个参数应该怎么设置呢？很简单，你只要设置log.dirs，即第一个参数就好了，不要设置log.dir。

1.操作系统Kafka 由 Scala 语言和 Java 语言编写而成，编译之后的源代码就是普通的“.class”文件。目前常见的操作系统有 3 种：Linux、Windows 和 macOS。如果考虑操作系统与 Kafka 的适配性，Linux 系统显然要比其他两个特别是 Windows 系统更加适合部署 Kafka。但其中具体的原因:1.I/O 模型的使用2.数据网络传输效率3.社区支持度1.I/O 模型的使用首先来看 I/O 模型。什么是 I/O 模型呢？你可以近似地认为 I/O 模型