第一章 初识Kafka
kafka是一款发布订阅的消息系统,具体结构从大向下可以列举为:
1个Kafka集群种有N个broker,一个broker有N个主题分区
broker指的是一个独立的Kafka服务器
主题指的是消息的分类
为什么要选用Kafka
发布订阅的消息系统很多,选择Kafka的原因如下:
多个生产者
Kafka可以支持多个生产者,这是因为Kafka是以主题(TOPIC)来区分消息的,多个生产者可以向同一个主题发送消息,从而支持多个生产者。
多个消费者
一个主题可以被多个消费者消费,并且可以有两种消费方式:
第一种是消费时,一个消息仅消费一次(多个应用设置同一个消费组)
第二种是消费时,一个消息同时被多个应用消费(多个应用,设置为不同的消费组)
基于磁盘的数据存储
Kafka的消息会被提交到磁盘种,因此当消费者挂掉时,消息也不会消失。
伸缩性
独立的Kafka服务器是一个Broker,当性能不能够时,可以扩展为Kafka集群
高性能
- Cache Filesystem Cache PageCache缓存
- 顺序写 由于现代的操作系统提供了预读和写技术,磁盘的顺序写大多数情况下比随机写内存还要快。
- Zero-copy 零拷技术减少拷贝次数
- Batching of Messages 批量量处理。合并小的请求,然后以流的方式进行交互,直顶网络上限。
- Pull 拉模式 使用拉模式进行消息的获取消费,与消费端处理能力相符。
使用场景
活动跟踪
分析用户与前端交互的日志信息
传递消息
邮件,通知
度量指标和日志记录
系统日志或者系统指标的分析
提交日志
例如数据库的日志信息可以用来进行缓存更新
流处理
对Kafka的消息进行简单的统计处理
第二章 安装Kafkas
zookeeper
Kafka使用zookeeper保存集群的元数据信息和消费者信息,zookeeper的选举算法见
https://blog.csdn.net/wx1528159409/article/details/84622762?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.control
第三章 Kafka生产者
生产者场景
不同的生产者会有不同的场景,从来产生不同的API使用的方式。主要考虑以下几点:
- 是否允许丢失数据
- 是否允许重复消费
- 延迟和吞吐量需求是怎么样的
创建Kafka生产者
必填属性
bootsrap.servers:集群地址,不需要包含所有的broker地址,会从其中某个broker中获取其他broker地址。
key.serializer:key的序列化方式
value.serializer:value的序列化方式
可选参数
-
acks:指定了必须要有多少个分区副本收到消息,生产者才会认为消息写入时成功的。该参数对消息丢失的可能性有重要影响
acks=0,生产者不判断消息是否写入成功,消息丢失可能性最大,吞吐量最大。
acks=1,broker中leader节点收到消息时,生产者就会收到消息写入成功的响应,消息丢失可能性适中,吞吐量适中
acks=all,所有的broker节点都收到消息时,生产者会收到消息写入成功的响应,消息丢失可能性最低,吞吐量最低
-
buffer.memory:缓存区大小,生产者消息会发送到缓冲区,然后缓冲区发送到服务器。如果进缓冲区的速度大于出缓冲区的速度,要么发送阻塞,要么出现异常。max.block.ms可以设置缓冲区的时间
-
compression.type:该参数设压缩模式,默认情况下不进行压缩。可以设置为snappy,gzip,lz4。
-
reries:重试次数,同时可以设置retry.backoff.ms设置重试间隔
-
batch.size:多个消息要被发送到同一个分区时,会进行打包发送,这里设置的是批次的大小(打包的大小)
-
linger.ms:设置了生产者在发送批次之前等待更多消息加入批次的时间,Kafka会在批次大小填满或者等待linger.ms时间进行发送。
-
client.id:可以是任意字符串,服务器用它识别消息的的来源
-
max.in.flight.requests.per.connection:制定生产者在收到服务器响应之前可以发送多少个消息,设置为1,表示按照顺序写入服务器
-
max.block.ms:可以设置缓冲区的时间
-
max.request.size:生产者发送的请求大小,注意和批次大小要相互匹配,也要和接收者(message.max.bytes)相互匹配
-
receive.buffer.bytes 和 send.buffer.bytes:指定TPC socket的缓冲区大小,设置为-1是系统默认值
发送消息方式
-
发送并忘记
调用send()方法,不关心异常情况,适用于允许丢数据的场景
这里不关心服务端发生的异常,但是生产者那一端会有其他异常,例如SerializationExcepion(序列化异常),BufferExhaustedException或TimeoutException(缓冲区已满),InterruptException(线程中断)
-
同步发送
调用send()方法,返回一个Futrue对象,调用get()方法进行等待,可以知道消息是否发送成功。适用于不允许丢数据的场景
KafkaProducer一般会有两类错误,一种是可重试错误,这类错误可以通过重发消息解决,例如“无主(no leader)”异常,可以重新为分区选举leader来接近。一种是无法通过重试来接近的异常,例如"消息过大"的异常,这个时候直接泡醋异常,不会进行任何重试。
-
异步发送
调用send()方法,设置回调函数,服务器在返回响应时调用该函数。
第四章 Kafka消费者
KafkaConsumer概念
消费者和消费者群组
为了保证消费端的横向扩展,消费者群组概念被提出,不过值得注意的是,消费者的横向扩展的上线与分区个数有关系。如下图:
消费者群组和分区再均衡
分区的所有权从一个消费者转移到另一个消费者,这样的行为被称为再均衡。
什么时候再平衡?
消费者发送那个心跳到群组协调器的broker来维持它们和群组的从属关系,以及它们对分区的所有权关系。如果消费者没有以正常时间间隔发送心跳,那么会触发再平衡。
分配分区时一个怎样的一个过程?
当消费者要加入群组时,它向群组协调器发送一个JoinGroup请求。第一个加入群组的消费者成为“群主”。群主从协调器中获取群组成员列表,并负责给每一个消费者分配分区。
创建Kafka消费者
消费者需要填充的属性。
bootsrap.servers:集群地址,不需要包含所有的broker地址,会从其中某个broker中获取其他broker地址。
key.serializer:key的序列化方式
value.serializer:value的序列化方式
group.id:群组id,非必须,但是常规的情况下都会填
订阅主题
创建好消费者对象后,调用subsceibe()方法接受一个主题列表作为参数。
值得注意的时subsceibe()方法也可以传入一个正则表达式,正则表达式可以匹配多个主题,如果有人创建了新的主题,并且主题名字和正则表达式匹配,那么会立即触发一次再平衡,消费者就可以读取新添加的主题。
轮询
消费轮询时消费者Api的核心,通过轮询向服务器请求数据。一旦消费者订阅了主题,轮询就会处理所有的细节,包括:群组协调 / 分区再平衡 / 发送心跳 / 获取数据,开发者只需要使用一组简单的Api来处理从分区返回的数据。消费者代码主要部分如下:
Properties props = new Properties();
KafkaConsumer<String, String> consumer = new KafkaConsumer<String, String>(props);
consumer.subscribe(Collections.singletonList("topic1"));
try {
// 无限循环,通过秩序轮询Kafka请求数据
while (true){
/**
* 灰常重要的代码,在这行代码里做了以下几件事情
* 1 群组协调:第一次调用时,会负责查找 GroupCoordinator,然后加入群组
* 2 分区再均衡:如果发生再平衡,在这代码里面执行
* 3 发送心跳:心跳也是这里发出的,因此要保证轮询期间所作的任何处理工作应该尽快完成
* 4 获取数据
*/
ConsumerRecords<String, String> poll = consumer.poll(Duration.ofMillis(100));
poll.forEach(item->{
// 返回的 ConsumerRecord 对象记录了topic,分区,offset
String format = MessageFormat.format("topic={0}, partition={1}, offset={2}, consumer={3}, value={4}",
item.topic(),
item<