消息队列和应用工具产品体系-消息队列 Kafka 版的特征及基本使用

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 消息队列和应用工具产品体系-消息队列 Kafka 版的特征及基本使用

开发者学习笔记【阿里云云原生助理工程师认证(ACA)课程:消息队列和应用工具产品体系-消息队列 Kafka 版的特征及基本使用】

课程地址:https://edu.aliyun.com/course/3112075/lesson/19041


消息队列和应用工具产品体系-消息队列 Kafka 版的特征及基本使用

 

内容介绍:

一、 Kafka 的简介

二、 Kafka 和 RocketMQ 对比

三、 Kafka 和 RocketMQ 对比

四、 阿里 Kafka 的场景介绍

五、 Kafka 基本操作流程

 

一、 Kafka 的简介

image.png

接下来介绍消息队列家族中的另一个主要产品 Kafka。首先,先介绍一下卡夫卡的产生背景。Kafka 的诞生是为了解决 Linkedln 公司的数据管道问题。起初 Linkedln 采用的是active MQ进行数据交换,大约在2010年前后,那时候的active MQ还远远不能满足 Linkedln 对数据传输系统的要求,经常因为各种缺陷而导致消息阻塞或服务无法正常访问。为了能够解决这个问题, Linkedln 决定研发自己的消息传递系统。当时的 Linkedln 的首席架构师,便开始组织团队进行消息传递系统的研发,这个系统就是 Kafka。

Kafka 是由 Scala 和 Java 编写的一种高吞吐的分布式发布消息系统。具有无线数据堆积能力和高效的持久化能力。单机写入能力高达每秒钟百万条, Kafka 在Linkedln 在公司获得巨大成功后,于2011年初进行开源。并于2012年10月成为 Apache 基金会的顶级项目。从某种程度上来看,kafka 可以说是第一个开源的现代消息队列产品。实际上,在 Kafka 开源之后,淘宝中金进团队对 Kafka 做过充分的瑞缪。 Kafka 的无限堆积和高效的持久化速度,都对淘宝自己的消息的队列产品的设计产生了启发效果。我们之前在微服务章节中提到的福瑞德罩子,在2012年尝试对100万的行的這兔一一程序进行解偶合,使用的正是 Kafka 消息队列。

 

二、 Kafka 和 RocketMQ 对比

 

 

 

性能对比

数据可靠性

多Topic性能

严格消息顺序

定时消息

事务消息

失败重试

消息轨迹

消息查询

RocketMQ

单机十万TPS

同步异步刷盘可靠性高

数万队列性能不受影响

严格保证

支持

支持

Kafka

单机百万TPS

异步刷盘可靠性一般

超过64Topic性能下降

宕机不保证

不支持

不支持

 

RocketMQ 团队在 Kafka 的 Review 后发现,除了无限消息堆积,高效的持久化速度的优点之外, Kafka 本身基于日志的设计思路,在转发业务消息时,却有着难遇克服的缺点。首先, Kafka 虽然单机性能比较高,但是是基于在发送端进行缓存之后,统一发送的模式,在这种模式下,如果使用的是扎哇客户端则如果缓存过多,引发 Z C很严重的问题。同时在极端情况下,消息进入缓存但还没来得及发送的时候,客户端崩溃就会导致消息丢失、业务出错,而 RocketMQ 同步写盘模式可靠性高于 Kafka 的异步写模式,不会因为操作系统的崩溃啊,而导致数据丢失。在多 Topic 方面, Kafka 单机如果超过64个队列,也就是64个 Topic ,系统的 log 会明显的飙高,导致消息发送速度明显变慢,而 RocketMQ 单机最高支持五万个队列,系统log 也不会有明显的上升。关于严格消息顺序, Kafka 支持顺序消息,但是集群中的一台 Brooker 宕机后,就会产生消息乱序,相比较之下 RocketMQ 支持更严格的消息顺序,在顺序消息场景中,集群中的一台 Brooker 宕机之后,消息发

送会失败 但不会乱序。同时, Kafka 也 不支持定时消息、事务消息、消息重置、消息轨迹、消息查询等业务消息的使用功能。因此,综合起来说, Kafka 更适合于可靠性要求不高的日常之类消息,而 RocketMQ 更适合具有高可靠性要求的业务消息,如淘宝消息、订单、充值等类型的消息。

 

三、 阿里 Kafka 的改进

项目

消息队列 Kafka 

Apache Kafka

磁盘水位

磁盘写满删除旧数据

磁盘写满直接宕机

线程池隔离

读冷数据仍可以保证写入基本正常

读冷数据直接导致线程堵塞,数据写入大量失败

分区规模

万级分区仍然可以保证稳定写入

千级分区就会出现大量抖动

巡检系统

针对死锁、宕机等问题进行自动发现和修复

只能等社区缓慢修复,且通常要等新版发布,周期长。

Bug 修复

及时发现并修复

只能等社区缓慢修复,且通常要等新版发布,周期长。

磁盘水位

磁盘写满删除旧数据

磁盘写满直接宕机

弹性能力

秒级伸缩,业务几乎无感知

小时级弹缩,期间会因为复制流量加大,对集群造成影响

存储成本

专业版提供高可靠云储存,节省大量储存空间

出于可用性和可靠性考虑,业界通常都是3副本存储,存储压力大。

版本升级

一键自助升级

手工操作易出错

Metrics 曲线

能看到完整 Metrics曲线,追踪流量、排查问题必备。

只能看到实时Metrics, 历史数据较难查看。

堆积告警

告警及时发现问题。

无。

订阅关系

完整的订阅关系。

比较简略。

分区状态

可以看到完整的状态图。

比较简略。

发送消息

控制台直接发送消息。

只能命令行操作,成本高。

查询消息

控制台根据时间或者位点直接查看消息。

命令行可以消费,但无法根据位点或者时间直接定位到具体的消息。

 

阿里云队列 Kafka 版100%的兼容开源设计的 Apache Kafka 业务代码无需进行任何改造即可移植。同时,相比较开源的 Kafka ,阿里云托管的消息队列 Kafka 版,从稳定性、内核性能和治理能力三个大方面提供了十余项的改进 。其中,稳定性方面的改进主要包括在磁盘水位方面,实现了磁盘的循环写入;在线程池隔离方面,修改了在开源版本中读取冷数据的线程堵塞问题;在分区规模方面,可以保证万级分区的稳定写入,防止开源版本上千个分区的性能抖动。同时,添加了巡检系统、Bug 快速发现修复功能;在内核方面,主要的改进包括利用强大的弹性伸缩能力,提供了强大的弹性伸缩能力,相比较于开源版本的小时级弹性伸缩,云托管版气功的秒级弹性伸缩,对业务层基本无感知;在存储方面,开源版的 Kafka 为了提高可用性和可靠性,需要自行构建3副本存储系统,资源成本和育人成本都非常高。而云托管版本基于可靠的云飞天存储系统,大幅度降低了用户的综合成本;而在治理能力方面,云托管版本也提供了很多功能改善,主要的改善功能包括一键式自助升级、完善的 Metrics 曲线、消息堆积警告功能、完整的消息队列订阅关系和分区状态以及控制台发送消息和消息查询功能。在这十余项改进过程中,最为重要的就是在图中橘黄色框标注的四项,即磁盘水位、线程池隔离、分区规模和弹性能力。

 

四、 阿里 Kafka 的场景介绍

image.png

1. Kafka 的第一个适用场景是用于数据聚合

许多公司例如淘宝、天猫等,每天都会产生大量的日志。这些日志一般为流式数据形式,例如搜索引擎的 PV 、查询等。相较于一些以日志为中心的系统,如 scrap ,flum,Kafka 在具备高性能的同时,可以实现更强的数据持久化,以更短的端到端使用时间。 Kafka 这种使用特性,决定了它非常适合作为日志收集中心,可以忽略文件的细节,将多台主机或应用的日志数据,抽象成一个个的日志或事件的消息流,并将这些消息流异步的发送到 Kafka 集群,从而实现非常低的RT。Kafka 客户端可以批量提交消息和压缩消息,对生产者而言几乎感觉不到性能的开支。消费者可以使用 Hodoop ,odps 等离线仓库存储,或者使用丝锥末、斯帕克等实时 在线分析系统对日志进行统计分析。 Kafka 在数据聚合方面具有以下优势:作为应用系统和分析系统的桥梁,并将他们之间的关联解耦。具有高可扩展性,即 当数据量增加时可通过增加节点快速水平扩展。支持实时在线分析系统和类似于 Hadoop 的离线分析系统。

2. Kafka 的第二个应用场景是用于网站的活动跟踪。

一个成功的网站运营,需要对站点的用户行为进行详细的分析,通过Kafka 的发布订阅模型,开发者可以实时收集用户在网站上的活动数据。例如注册、登录、充值、支付购买等活动,然后根据业务数据类型,将消息发送到不同的 Tao Pike ,再利用订阅消息的实时投递,将消息流用于对 Storm、Spark 等实时流计算引擎,进行实时计算、实时监控,或者将数据加载到 Hadoop,Max computer 等离线数据仓库,进行离线数处理。 Kafka 用于活动网站跟踪时具有以下优势:网站用户产生的行为信息较为庞大,需要较高的吞吐量来支持。而网站活动的流量剑锋,很容易导致行为数据快速激增,而云平台下的 Kafka 可以快速按需扩容,轻松应对数据高峰。

image.png

3. Kafka 的第三个应用场景适用于进行流计算处理。

在很多领域,如股市走向分析、气象数据监控、用户行为分析,由于数据量产生快、实时性强且数据量大,开发者很难统一采集这些数据,并将其存储后再进行处理,这便导致了传统的数据处理架构不能满足需求。与传统架构不同, Kafka 以及 Storm 、Samza 、Spark 等 流式计算引擎的出现,就是为了更好地解决这类数据在处理过程中遇到的问题。流计算模型能够实现在数据的流通过程中,对数据进行实时的捕捉、分析,并根据业务需求,进行计算分析,最终把结果保存或者分发给需要的组介。 Kafka 用于流计算引擎时,具有如下优势:可以实现应用和分析系统的结耦以及快速弹性伸缩,同时可以对开源的 Storm 、Samza、Spark 以及 EMR、Blink、StreamCompute 等阿里云产品进行无缝的对接。

image.png

4. Kafka 应用的第四个场景是作为数据中转枢纽。

近十多年来诸如数据存储、搜索、流式处理、批量计算、时序数据库等专用系统应运而生,这些系统是为了单一的目的而产生,因其简便性使得在商业硬件上构建分布式系统变得更加容易且性价比更高。通常一份数据需要注入到多个专用系统内,例如 当应用日志用于离线日志分析时,搜索单个日志记录同样不可或缺。而构建各自独立的工作流,来采集每种类型的数据再导入到自己的专用系统里,显然不切实际。利用 Kafka 作为数据中转枢纽,同一份数据可以被导入到不同的专用系统中。Kafka 作为数据中转枢纽具有以下优势:能在商业硬件上存储高容量的数据,实现可横向扩展的分布式系统。一对多的发布订阅模型支持通分数据集能同时被多次消费。支持本地数据持久化 Page Cache, 在无性能损耗的情况下能同时传送信息到实时和批处理的消费者。

image.png

 

五、 Kafka 基本操作流程

image.png

Kafka 实例的开通大致可以分为四个步骤:

第一步获取访问权限,开通云托管的 Kafka 服务,需要使用阿里云其他云产品中的资源。因此需要先授权 Kafka 访问开发者拥有的其他阿里云资源。

第二步购买和部署实例,在购买实例时,首先需要选择实例的付费方式,付费方式有两种分别是包年包月和按量付费。而在产品规格方面,有三种规格可以选择分别是标准版、专业高写版和专业高读版。其中标准版只支持0.10X 版本的 Kafka ,而专业版支持0.10X-2.0X 的一系列版本。设置完产品规格后,需要进行地域和可用区的设置,这部分和 RocketMQ 类似,不同地域知网不同地区内网不能直接互联,因此需要和业务模块放在同一地域。另外,开发者还需要设置实例的网络规格,在标准版中,内网网卡的流量从20M 到120M ;而专业的高写版,从20M 到2000M ;在专业的高读版中,读流量和写流量不同,从读50M 写10M 到读240M 写60M 。在实例例行部分,又分为两种类型,分别是 VPC 部署和公网VPC 部署。如果是公网VPC 部署,开发者还需购买相应的公网带宽。除了上述属性之外,开发者还可以配置磁盘类型、磁盘容量、消息保留最长时间、 Topic 规格等参数。其中在磁盘容量储存中,如果选择的是标准版,则购买300g 磁盘实际上只有100g 可用,另外200g 作为备份容量。而如果购买的是专业版,则购买300g 磁盘实际可用就是300g ,另外600g 备份容量为免费赠送。

第三步 创建资源,在这一步中开发者需要创建 Topic 和 Consumer Group ,在创建 Topic 过程中,需要设置分区数,而分区数数最好是六的倍数,以减少数据倾斜的风险。在资源创建好之后,就可以正式的开始使用消息队列 Kafka。

第四步 就是使用 SDK 进行消息的收发,其中 SDK 支持了20多种 常见的开发语言,具体的使用方法同学们可以参考相关的开发文档。以上就是消息队列中的全部内容,希望通过这一章节的学习同学们能够对消息队列的模式、功能和使用方法有更加深入的掌握

相关文章
|
2月前
|
消息中间件 存储 缓存
Kafka【基础知识 01】消息队列介绍+Kafka架构及核心概念(图片来源于网络)
【2月更文挑战第20天】Kafka【基础知识 01】消息队列介绍+Kafka架构及核心概念(图片来源于网络)
99 2
|
10天前
|
消息中间件 分布式计算 监控
Python面试:消息队列(RabbitMQ、Kafka)基础知识与应用
【4月更文挑战第18天】本文探讨了Python面试中RabbitMQ与Kafka的常见问题和易错点,包括两者的基础概念、特性对比、Python客户端使用、消息队列应用场景及消息可靠性保证。重点讲解了消息丢失与重复的避免策略,并提供了实战代码示例,帮助读者提升在分布式系统中使用消息队列的能力。
31 2
|
14天前
|
消息中间件 存储 Java
深度探索:使用Apache Kafka构建高效Java消息队列处理系统
【4月更文挑战第17天】本文介绍了在Java环境下使用Apache Kafka进行消息队列处理的方法。Kafka是一个分布式流处理平台,采用发布/订阅模型,支持高效的消息生产和消费。文章详细讲解了Kafka的核心概念,包括主题、生产者和消费者,以及消息的存储和消费流程。此外,还展示了Java代码示例,说明如何创建生产者和消费者。最后,讨论了在高并发场景下的优化策略,如分区、消息压缩和批处理。通过理解和应用这些策略,可以构建高性能的消息系统。
|
21天前
|
消息中间件 人工智能 监控
|
27天前
|
消息中间件 存储 负载均衡
消息队列学习之kafka
【4月更文挑战第2天】消息队列学习之kafka,一个分布式的,支持多分区、多副本,基于 Zookeeper 的分布式消息流平台。
17 2
|
29天前
|
消息中间件 存储 运维
|
29天前
|
消息中间件 Cloud Native Serverless
飞天发布时刻丨阿里云 ApsaraMQ 全面升级,携手 Confluent 发布全新产品
阿里云在3月29日的飞天发布时刻宣布ApsaraMQ全面升级,实现全系产品Serverless化,与Confluent合作推出新产品,强化云原生消息队列服务。
|
2月前
|
消息中间件 Linux API
Linux进程间通信(IPC) Linux消息队列:讲解POSIX消息队列在Linux系统进程间通信中的应用和实践
Linux进程间通信(IPC) Linux消息队列:讲解POSIX消息队列在Linux系统进程间通信中的应用和实践
27 1
Linux进程间通信(IPC) Linux消息队列:讲解POSIX消息队列在Linux系统进程间通信中的应用和实践
|
2月前
|
消息中间件 关系型数据库 MySQL
Flink CDC产品常见问题之用upsert的方式写入kafka失败如何解决
Flink CDC(Change Data Capture)是一个基于Apache Flink的实时数据变更捕获库,用于实现数据库的实时同步和变更流的处理;在本汇总中,我们组织了关于Flink CDC产品在实践中用户经常提出的问题及其解答,目的是辅助用户更好地理解和应用这一技术,优化实时数据处理流程。
|
2月前
|
消息中间件 关系型数据库 Kafka
Flink CDC产品常见问题之Flink CDC里从kafka消费的时候顺序混乱如何解决
Flink CDC(Change Data Capture)是一个基于Apache Flink的实时数据变更捕获库,用于实现数据库的实时同步和变更流的处理;在本汇总中,我们组织了关于Flink CDC产品在实践中用户经常提出的问题及其解答,目的是辅助用户更好地理解和应用这一技术,优化实时数据处理流程。

相关产品

  • 云消息队列 Kafka 版