多线程开发消费者实例
- Kafka Java Consumer设计原理
- 多线程方案
- 1. 消费者程序启动多个线程
- 2. 消费者程序使用单或多线程获取消息，同时创建多个消费线程执行消息处理逻辑。
- 方案一的优势
- 方案一的不足
- 方案二的优势
- 方案二的不足
- 方案一主体实现
- 方案二主体实现
Kafka Java Consumer设计原理
Kafka0.10.1.0版本开锁后，KafkaConsumer就变成了双线程设计，即用户主线程和心跳线程。但是在消费这个层面上看都还是单线程的设计。
而在老版本kafka中Scala Consumer 的API是多线程的，并且是阻塞机制，为了更好的打造上下游生态，Kafka将更好实现的单线程API推出，并且是否使用多线程来交给用户的选择。
多线程方案
1. 消费者程序启动多个线程
每个线程维护专属的 KafkaConsumer 实例负责完整的消息获取、消息处理流程。如下图所示：
2. 消费者程序使用单或多线程获取消息，同时创建多个消费线程执行消息处理逻辑。
获取消息的线程可以是一个，也可以是多个，每个线程维护专属的 KafkaConsumer 实例，处理消息则交由特定的线程池来做，从而实现消息获取与消息处理的真正解耦。具体架构如下图所示：
方案一的优势
- 实现起来简单，因为它比较符合目前我们使用 Consumer API 的习惯。我们在写代码的
时候，使用多个线程并在每个线程中创建专属的 KafkaConsumer 实例就可以了。 - 多个线程之间彼此没有任何交互，省去了很多保障线程安全方面的开销。
- 由于每个线程使用专属的 KafkaConsumer 实例来执行消息获取和消息处理逻辑，因
此，Kafka 主题中的每个分区都能保证只被一个线程处理，这样就很容易实现分区内的
消息消费顺序。这对在乎事件先后顺序的应用场景来说，是非常重要的优势。
方案一的不足
- 每个线程都维护自己的 KafkaConsumer 实例，必然会占用更多的系统资源，比如内
存、TCP 连接等。在资源紧张的系统环境中，方案 1 的这个劣势会表现得更加明显。 - 这个方案能使用的线程数受限于 Consumer 订阅主题的总分区数。我们知道，在一个消
费者组中，每个订阅分区都只能被组内的一个消费者实例所消费。假设一个消费者组订
阅了 100 个分区，那么方案 1 最多只能扩展到 100 个线程，多余的线程无法分配到任
何分区，只会白白消耗系统资源。当然了，这种扩展性方面的局限可以被多机架构所缓
解。除了在一台机器上启用 100 个线程消费数据，我们也可以选择在 100 台机器上分别
创建 1 个线程，效果是一样的。因此，如果你的机器资源很丰富，这个劣势就不足为虑
了。 - 每个线程完整地执行消息获取和消息处理逻辑。一旦消息处理逻辑很重，造成消息处理
速度慢，就很容易出现不必要的 Rebalance，从而引发整个消费者组的消费停滞。这个
劣势你一定要注意。我们之前讨论过如何避免 Rebalance。
方案二的优势
方案 2 将任务切分成了消息获取和消息处理两个部分，分别由不
同的线程处理它们。比起方案 1，方案 2 的最大优势就在于它的高伸缩性，就是说我们可
以独立地调节消息获取的线程数，以及消息处理的线程数，而不必考虑两者之间是否相互影
响。如果你的消费获取速度慢，那么增加消费获取的线程数即可；如果是消息的处理速度
慢，那么增加 Worker 线程池线程数即可。
方案二的不足
- 它的实现难度要比方案 1 大得多，毕竟它有两组线程，你需要分别管理它们。
- 因为该方案将消息获取和消息处理分开了，也就是说获取某条消息的线程不是处理该消
息的线程，因此无法保证分区内的消费顺序。举个例子，比如在某个分区中，消息 1 在
消息 2 之前被保存，那么 Consumer 获取消息的顺序必然是消息 1 在前，消息 2 在
后，但是，后面的 Worker 线程却有可能先处理消息 2，再处理消息 1，这就破坏了消
息在分区中的顺序。还是那句话，如果你在意 Kafka 中消息的先后顺序，方案 2 的这个
劣势是致命的。 - 方案 2 引入了多组线程，使得整个消息消费链路被拉长，最终导致正确位移提交会变得
异常困难，结果就是可能会出现消息的重复消费。如果你在意这一点，那么我不推荐你
使用方案 2。
方案一主体实现
public class KafkaConsumerRunner implements Runnable {
private final AtomicBoolean closed = new AtomicBoolean(false);
private final KafkaConsumer consumer;
public void run() {
try {
consumer.subscribe(Arrays.asList("topic"));
while (!closed.get()) {
ConsumerRecords records = consumer.poll(Duration.ofMillis(10000));
// 执行消息处理逻辑
}
} catch (WakeupException e) {
// Ignore exception if closing
if (!closed.get()) throw e;
} finally {
consumer.close();
}
}
// Shutdown hook which can be called from a separate thread
public void shutdown() {
closed.set(true);
consumer.wakeup();
}
...
}这段代码创建了一个 Runnable 类，表示执行消费获取和消费处理的逻辑。每个KafkaConsumerRunner 类都会创建一个专属的 KafkaConsumer 实例。在实际应用中，你可以创建多个 KafkaConsumerRunner 实例，并依次执行启动它们，以实现方案 1 的多线程架构。
方案二主体实现
private final KafkaConsumer<String, String> consumer;
private ExecutorService executors;
...
private int workerNum = ...;
executors = new ThreadPoolExecutor(
workerNum, workerNum, 0L, TimeUnit.MILLISECONDS,
new ArrayBlockingQueue<>(1000),
new ThreadPoolExecutor.CallerRunsPolicy());
...
while (true) {
ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(1));
for (final ConsumerRecord record : records) {
executors.submit(new Worker(record));
}
}当 Consumer 的 poll 方法返回消息后，由专门的线程池来负责处理具体的消息。调用 poll 方法的主线程不负责消息处理逻辑，这样就实现了方案 2 的多线程架构。
