19-24-kafka-消费者理论

19-kafka-消费者理论：

Kafka 消费者

消费方式

pull：从 broker 中读取数据，若 kafka 没有数据，消费者可能会陷入循环中，一直返回空数据。Kafka 的消费者在消费数据时会传入一个时长参数 timeout，如果当前没有数据可供消费，consumer 会等待一段时间之后再返回，这段时长即为 timeout

push：（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由 broker 决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成 consumer 来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而 pull 模式则可以根据 consumer 的消费能力以适当的速率消费消息。

分区分配策略（当消费者的个数发生变化时会产生变化）

一个 consumer group 中有多个 consumer，一个 topic 有多个 partition，需确定那个 partition 由哪个 consumer 来消费。Kafka 有两种分配策略，一是 RoundRobin（按照组分，topic和partition，整体hash排序发送给消费者），一是 Range（按照主题进行分区）。

参考：https://blog.csdn.net/qq_36951116/article/details/100863502

offset 的维护（了解为主，主要存储格式，消费者组+topic+分区）

由于 consumer 在消费过程中可能会出现断电宕机等故障，consumer 恢复后，需要从故障前的位置的继续消费，所以 consumer 需要实时记录自己消费到了哪个 offset，以便故障恢复后继续消费。启用生产者，启用消费者，观察offset

[root@hadoop102 zookeeper-3.4.10]# bin/zkCli.sh

[zk: localhost:2181(CONNECTED) 1] ls /
[cluster, controller_epoch, controller, brokers, zookeeper, admin, isr_change_notification, consumers, latest_producer_id_block, config]
[zk: localhost:2181(CONNECTED) 7] get /brokers/ids

Kafka 0.9 版本之前，consumer 默认将 offset 保存在 Zookeeper 中，从 0.9 版本开始，

consumer 默认将 offset 保存在 Kafka 一个内置的 topic 中，该 topic 为**__consumer_offsets**。

1）修改配置文件 consumer.properties

exclude.internal.topics=false

2）读取 offset，0.11.0.0 之后版本(含):

bin/kafka-console-consumer.sh --topic __consumer_offsets --zookeeper hadoop102:2181 --formatter “kafka.coordinator.group.GroupMetadataManager$OffsetsMessageFormatter” --consumer.config config/consumer.properties --from beginning

消费者组案例(主要理解消费者组只有一个消费者在消费)

参考：https://www.cnblogs.com/cjsblog/p/9664536.html

1）需求：测试同一个消费者组中的消费者，同一时刻只能有一个消费者消费。

2）案例实操

（1）在 hadoop102、hadoop103 上修改/opt/module/kafka/config/consumer.properties 配置

文件中的 group.id 属性为任意组名。

[root@hadoop103 config]$ vi consumer.properties

group.id=test_group_v1

（2）在 hadoop102、hadoop103 上分别启动消费者

[root@hadoop102 kafka]$ bin/kafka-console-consumer.sh --zookeeper hadoop102:2181 --topic first --consumer.config

config/consumer.properties

[root@hadoop103 kafka]$ bin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic first --consumer.config

config/consumer.properties

（3）在 hadoop104 上启动生产者

[root@hadoop104 kafka]$ bin/kafka-console-producer.sh --broker-list hadoop102:9092 --topic first

>hello world

（4）查看 hadoop102 和 hadoop103 的接收者。

同一时刻只有一个消费者接收到消息。

Kafka 高效读写数据（了解）

1）顺序写磁盘

Kafka 的 producer 生产数据，要写入到 log 文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到 600M/s，而随机写只有 100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。

2）零拷贝

Zookeeper 在 Kafka 中的作用（了解）

Kafka 集群中有一个 broker 会被选举为 Controller，负责管理集群 broker 的上下线，所有 topic 的分区副本分配和 leader 选举等工作。Controller 的管理工作都是依赖于 Zookeeper 的。以下为 partition 的 leader 选举过程：监听ids，挂了在选取新的leader,然后更新leader以及isr

Kafka 事务

Kafka 从 0.11 版本开始引入了事务支持。事务可以保证 Kafka 在 Exactly Once 语义的基础上，生产和消费可以跨分区和会话，要么全部成功，要么全部失败。

Producer事务(同幂等性，跨分区跨回话精准一次)，即全局id和pid对应，再次启动通过全局id获取之前的pid。

为了实现跨分区跨会话的事务，需要引入一个全局唯一的 Transaction ID，并将 Producer获得的PID 和Transaction ID 绑定。这样当Producer 重启后就可以通过正在进行的 TransactionID 获得原来的 PID。为了管理 Transaction，Kafka 引入了一个新的组件 Transaction Coordinator。Producer 就是通过和 Transaction Coordinator 交互获得 Transaction ID 对应的任务状态。Transaction

Coordinator 还负责将事务所有写入 Kafka 的一个内部 Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

Consumer 事务一般不做了解，以消费一次为主，hw和leo

学习路径：https://space.bilibili.com/302417610/，如有侵权，请联系q进行删除：3623472230