kafka监听topic消费_Kafka消费者-从Kafka读取数据

(1)Customer和Customer Group

(1)两种常用的消息模型

队列模型(queuing)和发布-订阅模型(publish-subscribe)。

队列的处理方式是一组消费者从服务器读取消息，一条消息只由其中的一个消费者来处理。

发布-订阅模型中，消息被广播给所有的消费者，接收到消息的消费者都可以处理此消息。

(2)Kafka的消费者和消费者组

Kafka为这两种模型提供了单一的消费者抽象模型： 消费者组 (consumer group)。 消费者用一个消费者组名标记自己。 一个发布在Topic上消息被分发给此消费者组中的一个消费者。 假如所有的消费者都在一个组中，那么这就变成了队列模型。 假如所有的消费者都在不同的组中，那么就完全变成了发布-订阅模型。 一个消费者组中消费者订阅同一个Topic，每个消费者接受Topic的一部分分区的消息，从而实现对消费者的横向扩展，对消息进行分流。

注意：当单个消费者无法跟上数据生成的速度，就可以增加更多的消费者分担负载，每个消费者只处理部分partition的消息，从而实现单个应用程序的横向伸缩。但是不要让消费者的数量多于partition的数量，此时多余的消费者会空闲。此外，Kafka还允许多个应用程序从同一个Topic读取所有的消息，此时只要保证每个应用程序有自己的消费者组即可。

消费者组的概念就是：当有多个应用程序都需要从Kafka获取消息时，让每个app对应一个消费者组，从而使每个应用程序都能获取一个或多个Topic的全部消息；在每个消费者组中，往消费者组中添加消费者来伸缩读取能力和处理能力，消费者组中的每个消费者只处理每个Topic的一部分的消息，每个消费者对应一个线程。

(3)线程安全

在同一个群组中，无法让一个线程运行多个消费者，也无法让多线线程安全地共享一个消费者。按照规则，一个消费者使用一个线程，如果要在同一个消费者组中运行多个消费者，需要让每个消费者运行在自己的线程中。最好把消费者的逻辑封装在自己的对象中，然后使用java的ExecutorService启动多个线程，使每个消费者运行在自己的线程上,可参考https://www.confluent.io/blog

(2)Partition Rebalance分区再均衡

(1)消费者组中新添加消费者读取到原本是其他消费者读取的消息

(2)消费者关闭或崩溃之后离开群组，原本由他读取的partition将由群组里其他消费者读取

(3)当向一个Topic添加新的partition，会发生partition在消费者中的重新分配

以上三种现象会使partition的所有权在消费者之间转移，这样的行为叫作再均衡。

再均衡的优点：

给消费者组带来了高可用性和伸缩性

再均衡的缺点：

(1)再均衡期间消费者无法读取消息，整个群组有一小段时间不可用

(2)partition被重新分配给一个消费者时，消费者当前的读取状态会丢失，有可能还需要去刷新缓存，在它重新恢复状态之前会拖慢应用程序。

因此需要进行安全的再均衡和避免不必要的再均衡。

(3)创建Kafka消费者、订阅主题、轮询

Properties props = newProperties();

props.put("bootstrap", "broker1:9092,broker2:9092");

props.put("group.id", "CountryCounter");

props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");

props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");//1.创建消费者

Kafka