本文主要聊聊java线程池ThreadPoolExecutor的源码实现，以及如何通过Apollo配置中心来达到动态调整线程池大小 任务执行过程简述 首先我还是用图文来说明一下线程池执行任务的大致原理，防止大家一看代码就晕圈 线程池中的每一个线程我们称之为worker线程，因为源码中就是一个继承 ...

前言 本文聊聊消费者拉取消息时向kafka server发送LIST_OFFSETS的请求，这个请求的功能一言以蔽之:根据请求参数中的timeStamp获取消费者(或副本)能够fetch的位移 它的使用场景是：当前是新消费者组，或是消费者组过期了(相关参数为offsets.retention.min ...

前言 本文聊聊消费者如何获取上次提交的位移 OffsetFetch请求 在Kafka消费者-源码分析(上)一文的最后，Consumer在refreshCommittedOffsetsIfNeeded方法发起了该请求，目的是获取消费者上次提交的位移，作为下次拉取请求的fetchOffset参数 123 ...

前言 衔接上文kafka-rebalance之JoinGroup, 我们已经知道在JoinGroup请求的响应中，leader consumer会计算分区分配方案，并发起SyncGroup请求，本文讲解SyncGroup请求的处理过程 同样的思路，我们还是从请求发起看起 发送请求 123456789 ...

前言 在AbstractCoordinator的initiateJoinGroup方法中，通过判断joinFuture为null，发起了JoinGroupRequest请求，本文主要讲解GroupCoordinator对该请求的处理。同样的，源码分为客户端发起请求时的参数，broker端的处理过程， ...

本文主要介绍Consumer在第一次拉取消息前，获取Coordinator的过程，衔接Kafka消费者-源码分析一文 前言 在ConsumerCoordinator的poll方法中，我们聊到第一次poll时，consumer需要加入消费者组，此时coordinator未知，需要向broker获取 ...

本文从消费者拉取消息开始分析消费流程，但kafka并不是单纯的在poll方法中拉取消息，鉴于消费者组的存在，以及Rebalance动作，使整个消费流程的复杂度直线上升，因此需要比生产者花费更多的章节去讲解 准备 为了方便大家阅读源码，这里先对源码中经常出现的部分做一个解释，提示大家的阅读效率 名 ...

前言 为什么我现在才写副本同步的解析呢，因为它太复杂了，仅仅是什么时候触发的副本同步，就涉及到KafkaController，LeaderAndIsr请求等，经过前面文章的梳理，现在时机正好 正文 通常我们会为了提高系统并发能力、可伸缩性，为topic设置多个分区，每个分区副本数通常设置为3个，其中 ...

前言 本文主要讲解follower副本发起用于同步的fetch请求之前，获取了leader副本的leader epoch及其startOffset，关于leader epoch的介绍，可以看看前面的LeaderAndIsr请求一文 follower副本同步 在follower副本每次发起fetch请 ...

在KafkaController初始化的过程中，多次遇见了LeaderAndIsr请求，这是broker之间通信的一个重要请求，它也是副本同步的关键步骤，本文主要分析KafkaApis对该请求的处理 ControllerChannelManager 在讲解LeaderAndIsr请求之前，我们先 ...