kafka笔记

最新推荐文章于 2024-06-16 21:25:39 发布

原创最新推荐文章于 2024-06-16 21:25:39 发布 · 181 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#kafka #大数据

Kafka是一种分布式的、基于发布/订阅的消息系统

特点：

消息持久化：通过O(1)的磁盘数据结构提供数据的持久化
高吞吐量：每秒百万级的消息读写
分布式：扩展能力强
多客户端支持：java、php、python、c++ ……
实时性：生产者生产的message立即被消费者可见

基本组件

Broker：每一台机器叫一个Broker
Producer：日志消息生产者，用来写数据，当对接flume的时候，flume的sink就是Kafka的producer生产者
Consumer：消息的消费者，用来读数据，可以通过spark streaming作为消费者来读取数据
Topic：不同消费者去指定的Topic中读，不同的生产者往不同的Topic中写
Partition：新版本才支持Partition，在Topic基础上做了进一步区分分层

一个生产者的数据可以分配给多个partition，并且这多个partition可以对接到多个groupid里面，但是每个groupid必须消费一个完整的生产者所分配的分区数据，即如下图所示：

这两个p1表示同一个生产者的不同分区的数据，它们的结果必须到一个完整的groupid里面。
当consumer的个数大于分区的个数时，会出现有的消费者无法消费的情况，如图所示：
在这里插入图片描述
• Kafka内部是分布式的、一个Kafka集群通常包括多个Broker
• zookeeper负载均衡：将Topic分成多个分区，每个Broker存储一个或多个Partition
• 多个Producer和Consumer同时生产和消费消息

在这里插入图片描述

一个生产者->两个分区->一个消费者：
在上述这种情况下，生产者的数据分别到两个分区当中，然后合并返回一个消费者里面，那么它们的顺序可能会与生产者输入的顺序不同。

#查看某个topic主题详情，例如分区数
bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test

• 一个Topic是一个用于发布消息的分类或feed名，kafka集群使用分区的日志，每个分区都是有顺序且不变的消息序列。
• commit的log可以不断追加。消息在每个分区中都分配了一个叫offset的id序列来唯一识别分区中的消息
每一个分区的日志是用topic-分区id为名称的文件夹，例如test-0 test-1表示topic为test的两个分区
• 无论发布的消息是否被消费，kafka都会持久化一定时间（可配置）。
• 在每个消费者都持久化这个offset在日志中。通常消费者读消息时会使offset值线性的增长，但实际上其位置是由消费者控制，它可以按任意顺序来消费消息。比如复位到老的offset来重新处理。
message（消息）是通信的基本单位，每个producer可以向一个topic（主题）发布一些消息。如果consumer订阅了这个主题，那么新发布的消息就会广播给这些consumer。
生产者可以发布数据到它指定的topic中，并可以指定在topic里哪些消息分配到哪些分区（比如简单的轮流分发各个分区或通过指定分区语义分配key到对应分区）。
生产者直接把消息发送给对应分区的broker，而不需要任何路由层。
批处理发送，当message积累到一定数量或等待一定时间后进行发送。可以减少网络请求次数。
• 一种更抽象的消费方式：消费组（consumer group）
1、如果所有的消费者实例都有相同的消费组，这样就像传统的queue方式。
2、如果所有的消费者实例都有不同的消费组，这样就像传统的发布订阅方式。
一个partition只能对应一个consumer，但是一个consumer可以对应多个partition（指的是同一个groupid里面的），如下图：
在这里插入图片描述
对于第一个group A来说p0、p3->C1的原因是这样的话，只需要建立一个连接就行。
• Kafka存储布局简单：Topic的每个Partition对应一个逻辑日志（一个日志为相同大小的一组分段文件）
• 每次生产者发布消息到一个分区，代理就将消息追加到最后一个段文件中。当发布的消息数量达到设定值或者经过一定的时间后，段文件真正flush磁盘中。写入完成后，消息公开给消费者。
• 与传统的消息系统不同，Kafka系统中存储的消息没有明确的消息Id。
• 消息通过日志中的逻辑偏移量来公开。
在这里插入图片描述
Kafka虽然也是要写入磁盘，但是它却比较快的原因是采用了zero-copy机制。
• Kafka代理是无状态的：意味着消费者必须维护已消费的状态信息offset。这些信息由消费者自己维护，代理完全不管。这种设计非常微妙，它本身包含了创新。
Kafka默认采用at least once的消息投递策略。
• 三种保证策略：
At most once 消息可能会丢，但绝不会重复传输
At least one 消息绝不会丢，但可能会重复传输
Exactly once 每条消息肯定会被传输一次且只传输一次
• 由于kafka中一个topic中的不同分区只能被消费组中的一个消费者消费，就避免了多个消费者消费相同的分区时会导致额外的开销（如要协调哪个消费者消费哪个消息，还有锁及状态的开销）。kafka中消费进程只需要在代理和同组消费者有变化时时进行一次协调（这种协调不是经常性的，故可以忽略开销）。