KafKa基本介绍

kafKa的基本介绍:

kafka是一个分布式的消息队列,kafka并不是JMS的实现。

JMS是一套java规范,它有消息的消费者和生产者,有两种模式:

一:点对点模式。一个生产者对应一个消费者,由消息的消费者去拉取消息,消息获取到以后消息清除。好比牵手女朋友,这哥们比较专情,找了一个女朋友就对其他的女人不感兴趣大笑

二:发布/订阅模式。一对多模式,一个消息的生产者对应多个消息的消费者,消息生产出来以后,推送给所有消息的订阅者。好比一个女神有很多爱慕者,女神发一条动态,很多关注者就会收到这条消息,屌丝都忙着对女神点赞。偷笑

KafKa和JMS的一个区别就是:在一对多模式中,kafKa中的消息生产出来以后,不会直接推送给消息的消费者,而是存放在队列中,由消息的消费者自己去主动拉取。


kafka的基本组成:

kafka一样有消息的生产者producer和消息的消费者consumer,kafka集群有若干个broker(翻译成中文:经纪人,掮客)组成。


kafka的broker:

kafka集群一般都有多个broker,每个broker有若干个topic,,可能订单的信息存放在一个topic中,评论的信息存放在另外一个topic中,topic是一种逻辑上的概念。topic和partition是对应关系,如果partition是三个,那么topic就分成三份。同一个topic对应多个partition(可以是一个),每个partition都是一个目录,partition的名称,由topic的名称+有序序号,有序序号从0开始,最大序号为partitions的数量减一。partition分区有多个副本,可以设置,它会从多个副本中选出一个leader,由这个leader接受数据和提供数据的消费,避免宕机以后的数据丢失问题。partition只是一个逻辑概念,真正接受数据和提供数据消费的是topic。

hashPartition是kafka的默认的分组策略,由hash值(key的hash)模上partition分区的数量决定数据发送到那台broker上,它还有随机分组策略,轮询策略等。每个broker上都会保存一份元数据信息,包括这些broker上有多少个topic,partition数量,那个是leader等元数据信息。


segment  每个partition相当于一个巨型文件被分成若干个大小相等的segment(段)数据文件中,每个segment file中保存有文件大小相等但消息数量不一定相同的消息。partition分区中的index文件存储元数据信息,log文件存储消息,这样设计,方便对old segment file 进行删除处理,默认会保存7天。每个segment的大小默认为1G(可以理解为滚动写入,超过一个G重新生成新的index和log文件)      


kafka为什么快?

不同于redis和memcached等内存型的数据库,kafka是将数据写入到速度低容量大的磁盘,kafka严重依赖底层操作系统的pagecache功能,写入的数据,会将page的属性标记为dirty,pageCache实际上就是将系统的空闲内存当做缓存 来用。 


关于kafka的consumer

kafka的consumer有组的概念,一个consumerGroup有多个consumer,多个consumerGroup之间消费的数据没有关联,消费者会从队列中拉取消息,但是队列中的消息不会消失,仍然存储在磁盘上;但是同一个consumerGroup中的consumer不能重复消费消息,这点需要注意。

   consumerGroup中的一个consumer对应一个或者多个partition分片,但是一个分片只能对应一个consumer。(一夫多妻制羡慕

如果consumer的数量大于分片数量,多余的consumer消费不到数据只能等待其他的consumer挂掉才有机会消费数据,只有Rebalance。


关于kafka的配置文件中的request.required.acks反馈机制

消息的生产者producer生产消息,发送到集群上的broker上,是否需要broker反馈状态。acks有三种状态:

0:表示producer生产消息不关心broker是否接受消息,默认为0

1:表示producer生产消息,leader接受消息后发送ack

-1:表示producer生产消息,所有的fllowers都同步消息才发送ack


关于kafka中数据丢失和重复消费的问题:

思考:kafka中数据丢失和重复消费问题发生在什么情况下?

kafka数据丢失和重复消费发生两种情况下:

一:消息的生产者producer生产消息的时候:

同步模式下,producer发送消息,如果反馈机制设置为1时,kafka集群上的leader恰好挂掉,就会产生数据丢失的问题

异步模式下,producer生产的消息缓存在缓冲区中,如果反馈机制设置为0时,这时候缓存区满了,就会造成数据丢失问题。

二:消息的consumer消费消息的时候:

consumer从队列中拉取消息后更新offerset偏移量的时候,如果offset更新有问题,就会造成数据的丢失和重复消费问题。


如何解决数据丢失和重复消费问题?

在producer生成消息的时候:

如果是同步模式,leader将数据同步到flower上去,然后再发送ack反馈,这样就不会造成数据的丢失。

如果是异步模式,设置非阻塞超时时间(一旦缓存区阻塞一定时间producer就知道)

在consumer拉取消息的时候:

我们可以让consumer拉取到消息后,先不用更新offset,等做完数据的处理以后,再去更新offset,这样即使数据在处理过程中出现问题也不会造成数据的丢失和重复消费问题,如果使用storm消费消息我们可以采用ack机制。

如何解决数据重复问题?

我们可以采用第三方介质来出来,比如redis,利用redis中的key不重复来做去重操作;在某下场景下如果重复数据对我们没什么影响也可以不用处理。

关于(未完待续。。。)

<think>嗯,用户想了解Apache Kafka基本概念和核心功能。首先,我需要回忆一下Kafka的定义和主要用途。Kafka是一个分布式流处理平台,主要用于处理实时数据流,支持发布-订阅模式,这在消息队列系统中很常见。根据引用[1]和[3],Kafka具有高吞吐量、可扩展性和容错性,适合企业级消息传递和大规模数据处理。 接下来,核心功能方面,用户可能需要知道Kafka的四个核心API,如生产者API、消费者API等,这些在引用[1]和[4]里提到过。另外,Kafka的架构包括Broker、Topic、Partition这些概念,需要详细解释。比如,Topic是消息的分类,Partition用于横向扩展和并行处理,引用[3]和[4]中的信息可以支持这部分内容。 用户可能还会关心Kafka的存储机制,比如它的高性能存储模块,这部分在引用[3]里有提到。另外,Kafka与其他系统的集成能力,比如通过Kafka Connect进行数据导入导出,以及流处理能力如Kafka Streams,这些也是核心功能的一部分。 需要注意的是,用户的问题可能涉及Kafka的分布式特性,比如ZooKeeper的作用和KRaft模式的引入,引用[5]中提到Kafka 3.0开始使用KRaft替代ZooKeeper,这一点要说明清楚。 此外,应用场景部分需要举例说明,比如在微服务架构中的异步通信,日志聚合,实时分析等,引用[4]中的例子可以作为参考。还要提到Kafka在数据管道中的作用,连接不同系统进行数据流转。 最后,生成相关问题时要覆盖用户可能进一步想了解的内容,比如架构组件、消息模式、存储机制、ZooKeeper和KRaft的区别,以及应用场景。确保问题有针对性,帮助用户深入理解Kafka的不同方面。</think>### Apache Kafka 简介及核心功能 #### 1. **基本概念** Apache Kafka 是一个**分布式流处理平台**,主要用于实时数据流的处理、存储和传输。其核心设计目标是实现高吞吐量、水平扩展和容错能力,适用于大规模数据处理场景[^1][^3]。 #### 2. **核心功能** - **分布式流系统** Kafka 通过分布式架构将数据分片存储在多个节点(Broker)上,支持横向扩展。每个 Topic 分为多个 Partition,每个 Partition 可在不同 Broker 上复制以提高容错性[^3][^5]。 - **发布-订阅模式** 生产者(Producer)将消息发布到 Topic,消费者(Consumer)订阅 Topic 并按需消费消息。例如,微服务中可用 Kafka 实现服务间异步通信,确保解耦和可靠传输[^4]。 - **高性能存储** Kafka 采用顺序读写和零拷贝技术优化磁盘 I/O,支持高吞吐量(百万级消息/秒)。数据按时间或大小策略持久化存储,便于回溯和批量处理。 - **流处理能力** 通过 Kafka Streams API 或集成外部框架(如 Flink),可直接对数据流进行实时处理(如聚合、过滤)。 #### 3. **核心组件** - **Broker**:Kafka 集群中的单个节点,负责消息存储和转发。 - **Topic**:逻辑上的消息分类,例如 `user_activity` 或 `payment_events`。 - **Partition**:Topic 的分区,每个 Partition 是一个有序、不可变的消息队列。 - **Producer/Consumer**:生产者推送消息到 Topic,消费者按需拉取消息[^3]。 #### 4. **关键特性** - **容错性**:通过副本机制(Replication)保障数据可靠性,即使部分节点故障,数据仍可用。 - **扩展性**:新增 Broker 可自动分配负载,无需停机。 - **持久化**:消息可配置保留时间(如 7 天),支持历史数据重放[^3]。 #### 5. **应用场景** - **日志聚合**:集中收集多服务的日志数据。 - **实时分析**:结合流处理框架进行实时指标计算(如用户行为分析)。 - **事件溯源**:记录系统状态变化事件,用于审计或回放[^4]。 ```plaintext 示例架构: 生产者 → Kafka Topic(Partition 1, Partition 2) → 消费者组 ``` #### 6. **生态集成** - **Kafka Connect**:工具库,支持与数据库、Hadoop 等系统集成。 - **KRaft 模式**:Kafka 3.0+ 版本支持去 ZooKeeper 的元数据管理,简化集群运维。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值