大数据-52 Kafka 基础概念和基本架构 核心API介绍 应用场景等

点一下关注吧!!!非常感谢!!持续更新!!!

目前已经更新到了:

  • Hadoop(已更完)
  • HDFS(已更完)
  • MapReduce(已更完)
  • Hive(已更完)
  • Flume(已更完)
  • Sqoop(已更完)
  • Zookeeper(已更完)
  • HBase(已更完)
  • Redis (已更完)
  • Kafka (正在更新...)

章节内容

上节我们完成了如下的内容:

  • Redis高可用 CAP-AP
  • Redis主从模式
  • Redis一主一从 一主多从
  • Redis哨兵模式
  • Redis哨兵模式 docker-compose测试

终于!我们更新完了Redis!现在我们开始更新Kafka。

Kafka介绍

Kafka最初是由Linkedin公司开发,是一个分布式、分区的、多副本、多生产者、多消费者、基于ZK的。

常见用于 Nginx 日志、消息服务。在2010年贡献给了Apache基金会成为顶级开源项目。

Kafka主要设计目标如下:

  • 以时间复杂度为O(1)的方式提供消息持久化的能力,即使TB级数据也能保证常数访问。
  • 高吞吐率,即使在非常廉价的机器上也可以有每秒100K条消息的传输
  • 支持KafkaServer间的消息分区,及分布式消费,同时保证每个Partition内的消息顺序传输。
  • 同时支持离线数据处理和实时数据处理
  • 支持在线水平扩展

生产消费图

消息模式

主流的消息传递有两种方式:点对点和发布订阅,Kafka属于 发布-订阅 模式的一种

对于消息中间件,消息会分为:拉、推。Kafka消息只有拉取,没有推送。(可以用轮询实现推送)

  • Kafka在一个或多个可以跨域多个数据中心的服务器上作为集群运行
  • Kafka集群按照主题分类管理,一个主题可以多个分区,一个分区可以有多个副本分区
  • 每个记录由一个键,一个值和一个时间戳组成。

核心API

  • ProducerAPI:允许应用程序记录流发布到一个或者多个Kafka主题
  • ConsumerAPI:允许应用程序订阅一个或多个主题并处理并生成记录流
  • StreamAPI:允许应用程序充当流处理器,使用一个或多个主题的输入流,并生成一个或者多个输出流。从而有效的将输入流转换为输出流。
  • ConnectorAPI:允许构建和运行将Kafka主题连接到现有应用程序或数据系统的可重用生产者或使用者

Kafka优势

  • 高吞吐:单机每秒处理几十百万的消息量,即使存储了TB消息,也能够稳定运行
  • 高性能:单节点支持上千个客户端,并保证零停机和零数据丢失。
  • 持久化数据存储:将消息持久化,通过数据持久化到磁盘以及replication防止数据丢失。
  • 分布式系统,易于向外扩展。所有Producer和Consumer等都可以有多个,分布式的,无需停机扩展。
  • Kafka是分布式、分区、复制、容错的
  • 客户端状态维护:消息被处理的状态在Consumer端维护,而不是由Server维护,失败能够自动平衡
  • 支持online和offline场景
  • 支持多种语言

应用场景

  • 日志收集:可以用Kakfa进行日志的收集
  • 消息系统:解耦生产者和消费者
  • 用户活动跟踪:用户行为被记录到Kafka中,消费者取到之后对用户的数据进行分析处理
  • 运营指标:记录运营监控数据、报警和报告
  • 流式处理:比如SparkStream、Storm

基本架构

消息和批次

  • Kafka的数据单元称为消息,可以把消息看成是数据库里的一个数据行或者一条记录。消息由字节组组成。
  • 消息由键,键也是一个字节数组,当消息以一种可控的方式写入不同的分区时,会用到键。
  • 为了提高效率,消息被分批写入Kafka,批次就是一组消息,这些消息属于同一个主题和分区。
  • 把消息分批次可以减少网络开销,批次越大,单位时间内处理的消息就越多,单个消息传输的时间久越长。

消息模式

  • 消息模式(schema)有很多可用的选项。如 JSON、XML,他们缺乏强类型的处理能力。
  • Kafka的开发者喜欢使用ApacheAvro,提供了一种紧凑序列格式化,模式和消息体分开。当模式发生变化时,不需要重新生成代码,它还支持强类型和模式进化。
  • 数据格式一致性对Kafka很重要,因为它消除了消息读写操作之间的耦合性。

主题和分区

Kafka的消息通过主题进行分类,主题可比数据库表或者文件系统里的文件夹。主题可以被分为若干区域,一个主题通过分区分布于Kafka集群中,提供了横向扩展的能力。

生产和消费者

生产者创建消息,消费者消费消息。

生产者在默认的情况下会把消息均衡的发布到主题的所有分区上:

  • 直接指定消息的分区
  • 根据消息的key散列取模得出分区
  • 轮询指定分区

消费者通过偏移量来区分已经读过的消息,从而消费消息。

消费者是消费组的一部分,消费组保证每个分区只有一个消费者使用,避免重复消费。

Broker 和 集群

一个独立的Kafka服务器成为Broker,Broker接受来自生产者的消息,为消息设置偏移量,并提交到磁盘进行保存。

Broker为消费者提供服务,对读取分区的请求做出响应,返回已提交到磁盘上的消息。

单个Broker可以轻松处理数千个分区以及每秒百万的消息量。

每一个集群都有一个Broker是集群控制器(自动从集群的活跃成员中选举出来)

控制器负责管理工作:

  • 将分区分配给Broker
  • 监控Broker

集群中一个分区属于一个Broker,该Broker称为分区首领。

  • 一个分区可以分配给多个Broker,此时会发生分区复制。
  • 分区的复制提高了消息冗余、高可用。
  • 副本分区不负责处理消息的读写。
相关推荐
赵渝强老师25 分钟前
【赵渝强老师】金仓数据库的数据文件
数据库·国产数据库·kingbase·金仓数据库
子兮曰1 小时前
后端字段又改了?我撸了一个 BFF 数据适配器,从此再也不怕接口“屎山”!
前端·javascript·架构
随逸1774 小时前
《Milvus向量数据库从入门到实战,手把手搭建语义检索系统》
数据库
卓卓不是桌桌4 小时前
如何优雅地处理 iframe 跨域通信?这是我的开源方案
javascript·架构
Qlly4 小时前
DDD 架构为什么适合 MCP Server 开发?
人工智能·后端·架构
神秘的猪头4 小时前
🚀 React 开发者进阶:RAG 核心——手把手带你玩转 Milvus 向量数据库
数据库·后端·llm
SelectDB1 天前
易车 × Apache Doris:构建湖仓一体新架构,加速 AI 业务融合实践
大数据·agent·mcp
IvorySQL1 天前
PostgreSQL 技术日报 (3月6日)|为什么 Ctrl-C 在 psql 里让人不安?
数据库·postgresql·开源
用户881586910911 天前
AI Agent 协作系统架构设计与实践
架构
NineData1 天前
数据库管理工具NineData,一年进化成为数万+开发者的首选数据库工具?
运维·数据结构·数据库