吴声子夜歌的博客

Kafka一直被认为是一个强大的消息中间件，它实现了高吞吐、高可用和低延时的消息传输能力，这让它成为流式处理系统中完美的数据来源。目前通用的一些流式处理框架如Apache Spark、Apache Flink、Apache Storm等都可以将Kafka作为可靠的数据来源。但遗憾的是，在0.l0.x版本之前，Kafka还并不具备任何数据处理的能力，但在此之后，Kafka Streams应运而生。Kafka Streams是一个用于处理和分析数据的客户端库。

我们知道，kafka中每个topic被划分为多个分区，那么生产者将消息发送到topic时，具体追加到哪个分区呢？这就是所谓的分区策略，Kafka 为我们提供了默认的分区策略，同时它也支持自定义分区策略。若发送消息时指定了分区（即自定义分区策略），则直接将消息append到指定分区；若发送消息时未指定 patition，但指定了 key（kafka允许为每条消息设置一个key），则对key值进行hash计算，根据计算结果路由到指定分区，这种情况下可以保证同一个 Key 的所有消息都进入到相同的分区；

虽然key中包含了4个字段，但最终确定这条消息所要存储的分区还是根据单独的group字段来计算的，这样就可以保证消费位移信息与消费组对应的GroupCoordinator处于同一个broker节点上，省去了中间轮转的开销，这一点与消费组的元数据信息的存储是一样的。同消费组的元数据信息一样，最终提交的消费位移也会以消息的形式发送至主题consumer offsets,.与消费位移对应的消息也只定义了key和value字段的具体内容，它不依赖于具体版本的消息格式，以此做到与具体的消息格式无关。

具体来说，每个消费组的元数据信息都是一条消息，不过这类消息并不依赖于具体版本的消息格式，因为它只定义了消息中的key和value字段的具体内容，所以消费组元数据信息的保存可以做到与具体的消息格式无关。这里所说的响应就是指SyncGroupRequest请求对应的SyncGroupResponse,SyncGroupResponse的内容很简单，里面包含的就是消费者对应的所属分配方案，SyncGroupResponse的结构如图所示，具体字段的释义可以从前面的内容中推测出来，这里就不赘述了。

对于之前所说的350s的定时任务，显然第一层时间轮不能满足条件，所以就升级到第二层时间轮中，最终被插入第二层时间轮中时间格17所对应的TimerTaskList。当“收割机”线程获取DelayQueue中超时的任务列表TimerTaskList之后，既可以根据TimerTaskList的expiration来推进时间轮的时间，也可以就获取的TimerTaskList执行相应的操作，对里面的TimerTaskEntry该执行过期操作的就执行过期操作，该降级时间轮的就降级时间轮。

与endOffsets对应的是beginningOffsets()方法，一个分区的起始位置起初是0，但并不代表每时每刻都为0，因为日志清理的动作会清理旧的数据，所以分区的起始位置会自然而然地增加。法的调用过程中实现的。代码中的endOffsets()方法用来获取指定分区的末尾的消息位置，参考图中9的位置，注意这里获取的不是8，是将要写入最新消息的位置。到目前为止，我们知道消息的拉取是根据poll方法中的逻辑来处理的，这个poll方法中的逻辑对于普通的开发人员而言是一个黑盒，无法精确地掌控其消费的起始位置。

再考虑一种情况，当有新的消费者加入时，那么必然会有再均衡的动作，对于同一分区而言，它可能在再均衡动作之后分配给新的消费者，如果不持久化保存消费位移，那么这个新的消费者也无法知晓之前的消费位移。如果这里引入了重试机制，前一次的异步提交的消费位移在重试的时候提交成功了，那么此时的消费位移又变为了x。这两个示例都有重复消费的问题，如果在业务逻辑处理完之后，并且在同步位移提交前，程序出现了崩溃，那么待恢复之后又只能从上一次位移提交的地方拉取消息，由此在两次位移提交的窗口中出现了重复消费的现象。

Kafka Connect是一个高伸缩性、高可靠性的数据集成工具，用于在Apache Kafka与其他系统间进行数据搬运以及执行ETL操作，比如Kafka Connect能够将文件系统中某些文件的内容全部灌入Kafka topic中或者是把Kafka topic中的消息导出到外部的数据库系统，如图所示。如图所示，Kafka Connect主要由source connector和sink connector组成。

对于Kafka企业级用户而言，一个常见的痛点就是跨机房或跨数据中心(data center,DC)的数据传输。大型企业通常在多个数据中心部署Kafka集群。.这里的数据中心可能是企业拥有的自建机房，也可能是公有云厂商的不同机房。在多个机房部署Kafk集群的优势如下。实现灾备。较近的地理位置可缩短延时以及用户响应时间。实现负载均衡，即每个数据中心上的集群可能只保存部分数据集合。区别隔离不同优先级的数据处理。

在创建Topic时我们需要设定Partition的数量，但如果觉得初始设置的Partition数量太少了，那么就可以使用createPartitions方法来调整Topic的Partition数量，但是需要注意在Kafka中Partition只能增加不能减少。自0.ll.0.0版本起，Kafka社区推出了AdminClient和KafkaAdminClient,意在统一所有的集群管理API。一个Topic会有自身的描述信息，例如：partition的数量，副本集的数量，是否为internal等等。

从consumer的角度来看，第一个阶段是收集所有consumer的topic订阅信息，而第二个阶段则利用这些信息给每个consumer分配要消费的分区。这样做的另一个好处就是，解耦了组管理与分区分配，coordinator负责组管理工作，而consumer程序负责分区分配。在所有consumer成员都收到SyncGroup response之后，coordinator将group状态设置为Stable,此时组开始正常工作，每个成员按照coordinator发过来的方案开始消费指定的分区。

举一个简单的例子，假设消息M1、M2被发送到test的0分区但属于不同的batch,M3被发送到test的1分区，那么batches中包含的信息就是{“test-0”->[batch1,batch2],“test-l”->[batch.3]}。KafkaProducer中还有一个专门的Sender I/O线程负责将缓冲池中的消息分批次发送给对应的broker,完成真正的消息发送逻辑。上面的元数据信息的前3项信息是比较重要的，producer端可以使用这些信息做一些消息发送成功之后的处理，比如写入日志等。

当创建topic时，controller负责创建分区对象，它首先会短暂地将所有分区状态设置为NonExistent,之后马上读取ZooKeeper中（严格来说是从controller的上下文信息中读取，关于controller的上下文信息稍后会详细讨论)的副本分配方案，然后令分区状态进入NewPartition。下图展示了controller的架构。分区重分配操作通常都是由Kafka集群的管理员发起的，旨在对topic的所有分区重新分配副本所在broker的位置，以期望实现更均匀的分配效果。

对于那些落后leader进度太多的follower而言，它们是没有资格竞选leader的，毕竟它们手中握有的数据太旧了，如果允许它们成为leader,会造成数据丢失，而这对clients而言是灾难性的。由于没有任何数据，因此3个副本的LEO都是0，HW值是0。Kafka把分区的所有副本均匀地分配到所有broker上，并从这些副本中挑选一个作为leader副本对外提供服务，而其他副本被称为follower副本，只能被动地向leader副本请求数据，从而保持与leader副本的同步。我们举一个实际的例子。

它和KafkaProducer不同，后者是线程安全的，因此用户可以在多个线程中放心地使用同一个KafkaProducer实例，事实上这也是社区推荐的producer使用方法，因为通常它比每个线程维护一个KafkaProducer实例效率要高。本例使用全局的KafkaConsumer实例执行消息获取，然后把获取到的消息集合交给线程池中的worker线程执行工作。代码中共有如下3个类。此方法与第一种方法的区别在于，我们将消息的获取与消息的处理解耦，把后者放入单独的工作者线程中，即所谓的worker线程中。

如图所示，Generation1时group有3个成员，随后成员2退出组，coordinator触发rebalance,consumer group进入到Generation2时代，之后成员4加入，再次触发rebalance,group进入到Generation3时代。针对rebalance过程中的分区分配，下面举一个简单的例子，加以说明。由此可见，原先A和B分别处理3个分区的数据，rebalance之后A、B和C各自承担2个分区的消费，可以说这个分配方案非常公平，每个consumer上的负载是相同的。

若此时由于某些原因（比如瞬时的网络抖动）导致record1未发送成功，同时Kafka又配置了重试机制以及max.in.flight.requests.per.connection大于1（默认值是5），那么producer重试recordl成功后，recordl在日志中的位置反而位于record2之后，这样造成了消息的乱序。采用同步发送当然是可以的，但是性能会很差，并不推荐在实际场景中使用。首先，对于消息丢失的问题，很容易想到的一个方案就是：既然异步发送可能丢失数据，改成同步发送似乎是一个不错的主意。

第二个interceptor会在消息发送后更新成功发送消息数或失败发送消息数。下面定义第二个interceptor——CounterInterceptor,该interceptor会在消息发送后更新“发送成功消息数”和“发送失败消息数”两个计数器，并在producer关闭时打印这两个。producer拦截器(interceptor)是一个相当新的功能，它和consumer端interceptor是在Kafka0.l0.0.0版本中被引入的，主要用于实现clients端的定制化控制逻辑。

Kafka是一个能够支持高并发以及流式消息处理的消息中间件，并且Kafka天生就是支持集群的，今天就主要来介绍一下如何搭建Kafka集群。Kafka目前支持使用Zookeeper模式搭建集群以及KRaft模式（即无Zookeeper）模式这两种模式搭建集群，这两种模式各有各的好处，今天就来分别介绍一下这两种方式这个配置项用于指定Kafka服务器监听客户端连接的地址和端口，当 Kafka 服务器启动时，它将监听listeners配置项中指定的地址和端口，等待客户端的连接请求。一般情况下这个配置以或者。

数据流(也被称为“事件流”或“流数据”)。首先，数据流是无边界数据 集的抽象表示。无边界意味着无限和持续增长。无边界数据集之所以是无限的，是因为随 着时间的推移，新的记录会不断加入进来。这个简单的模型(事件流)可以表示很多业务活动，比如信用卡交易、股票交易、包裹 递送、流经交换机的网络事件、制造商设备传感器发出的事件、发送出去的邮件、游戏 里物体的移动，等等。这个清单是无穷无尽的，因为几乎每一件事情都可以被看成事件 的序列。除了没有边界外，事件流模型还有其他一些属性。事件流是有序的。

有时候，我们需要知道提交的消费者群组偏移量是多少，比如某个特定的群组是否在提交 偏移量，或者偏移量提交的频度。也就是说，如果集群里有 5 个 broker，生产者的配额是 10MB/s，那么它可以以 10MB/s 的速率在单个 broker 上生成 数据，总共的速率可以达到 50MB/s。根 据分区大小的不同，复制过程可能需要花一些时间，因为数据是通过网络复制到新副本上 的。也就是说，在没有认证的情况下也可以使用这些命令行工具，在没 有安全检查和审计的情况下也可以执行诸如主题变更之类的操作。

另一方面，如果 broker 返回的是 INVALID_CONFIG 错误，即使通过重试 也无法改变配置选项，所以这样的重试是没有意义的。实际 上，如果使用这样的配置，那么当只剩下一个同步副本时，它就变成只读了，这是为了避 免在发生不完全选举时数据的写入和读取出现非预期的行为。但是，更少的同 步副本意味着更低的有效复制系数，在发生宕机时丢失数据的风险更大。只有那些被提交到 Kafka 的数据，也就是那些已经被写入所 有同步副本的数据，对消费者是可用的，这意味着消费者得到的消息已经具备了一致性。

目录1、集群成员关系2、控制器3、复制4、处理请求4.1、生产请求4.2、获取请求5、物理存储5.1、分区分配5.2、文件管理5.3、文件格式5.4、索引5.5、清理5.6、清理的工作原理5.7、被删除的事件1、集群成员关系Kafka 使用 Zookeeper 来维护集群成员的信息。每个 broker 都有一个唯一标识符，这个 标识符可以在配置文件里指定，也可以自动生成。在 broker 启动的时候，它通过创建临时节点把自己的 ID 注册到 Zookeeper。Kafka 组件订阅 Zookeeper

}//不做任何配置 } @Override public Customer deserialize(String topic , byte [ ] data) {int id;try {//不需要关闭任何资源 } }

如果发送到 Kafka 的对象不是简单的字符串或整型，那么可以使用序列化框架来创建消息 记录，如 Avro、Thrift 或 Protobuf，或者使用自定义序列化器。我们强烈建议使用通用的 序列化框架。} }//用来配置当前类 public void configure(Map < String ,?//不做任何配置 } /*** 执行序列化操作* @return* Customer对象被序列化成:* 表示customerID的4字节整数。

Producer API ：Producer API 用于将流数据发送至一个或多个Kafka主题中。Consumer API ：Consumer API 用于应用程序在订阅一个或多个主题后，对他们所产生的数据流进行处理。Streams API ：Streams API 使用来自一个或多个主题的输入流，并生成到一个或多个输出主题的输出流，提供一种有效的数据流处理方式。

【代码】Kafka——配置文件详解。

在IDE工具中使用maven打成jar包。启动zookeeper。访问9000端口即可。

Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。对于像Hadoop一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。