Kafka Java Consumer设计原理

        Kafka0.10.1.0版本开锁后，KafkaConsumer就变成了双线程设计，即用户主线程和心跳线程。但是在消费这个层面上看都还是单线程的设计。


        而在老版本kafka中Scala Consumer 的API是多线程的，并且是阻塞机制，为了更好的打造上下游生态，Kafka将更好实现的单线程API推出，并且是否使用多线程来交给用户的选择。

多线程方案

1. 消费者程序启动多个线程

每个线程维护专属的 KafkaConsumer 实例负责完整的消息获取、消息处理流程。如下图所示：

2. 消费者程序使用单或多线程获取消息，同时创建多个消费线程执行消息处理逻辑。

获取消息的线程可以是一个，也可以是多个，每个线程维护专属的 KafkaConsumer 实例，处理消息则交由特定的线程池来做，从而实现消息获取与消息处理的真正解耦。具体架构如下图所示：

方案一的优势

1. 实现起来简单，因为它比较符合目前我们使用 Consumer API 的习惯。我们在写代码的
   时候，使用多个线程并在每个线程中创建专属的 KafkaConsumer 实例就可以了。
2. 多个线程之间彼此没有任何交互，省去了很多保障线程安全方面的开销。
3. 由于每个线程使用专属的 KafkaConsumer 实例来执行消息获取和消息处理逻辑，因
   此，Kafka 主题中的每个分区都能保证只被一个线程处理，这样就很容易实现分区内的
   消息消费顺序。这对在乎事件先后顺序的应用场景来说，是非常重要的优势。

方案一的不足

1. 每个线程都维护自己的 KafkaConsumer 实例，必然会占用更多的系统资源，比如内
   存、TCP 连接等。在资源紧张的系统环境中，方案 1 的这个劣势会表现得更加明显。
2. 这个方案能使用的线程数受限于 Consumer 订阅主题的总分区数。我们知道，在一个消
   费者组中，每个订阅分区都只能被组内的一个消费者实例所消费。假设一个消费者组订
   阅了 100 个分区，那么方案 1 最多只能扩展到 100 个线程，多余的线程无法分配到任
   何分区，只会白白消耗系统资源。当然了，这种扩展性方面的局限可以被多机架构所缓
   解。除了在一台机器上启用 100 个线程消费数据，我们也可以选择在 100 台机器上分别
   创建 1 个线程，效果是一样的。因此，如果你的机器资源很丰富，这个劣势就不足为虑
   了。
3. 每个线程完整地执行消息获取和消息处理逻辑。一旦消息处理逻辑很重，造成消息处理
   速度慢，就很容易出现不必要的 Rebalance，从而引发整个消费者组的消费停滞。这个
   劣势你一定要注意。我们之前讨论过如何避免 Rebalance。

方案二的优势

方案 2 将任务切分成了消息获取和消息处理两个部分，分别由不
同的线程处理它们。比起方案 1，方案 2 的最大优势就在于它的高伸缩性，就是说我们可
以独立地调节消息获取的线程数，以及消息处理的线程数，而不必考虑两者之间是否相互影
响。如果你的消费获取速度慢，那么增加消费获取的线程数即可；如果是消息的处理速度
慢，那么增加 Worker 线程池线程数即可。

方案二的不足

1. 它的实现难度要比方案 1 大得多，毕竟它有两组线程，你需要分别管理它们。
2. 因为该方案将消息获取和消息处理分开了，也就是说获取某条消息的线程不是处理该消
   息的线程，因此无法保证分区内的消费顺序。举个例子，比如在某个分区中，消息 1 在
   消息 2 之前被保存，那么 Consumer 获取消息的顺序必然是消息 1 在前，消息 2 在
   后，但是，后面的 Worker 线程却有可能先处理消息 2，再处理消息 1，这就破坏了消
   息在分区中的顺序。还是那句话，如果你在意 Kafka 中消息的先后顺序，方案 2 的这个
   劣势是致命的。
3. 方案 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 的多线程架构。

如有错误欢迎指正