大数据Kafka:消息队列和Kafka基本介绍

目录
  • 一、什么是消息队列
  • 二、消息队列的应用场景
    • 异步处理
    • 应用耦合
    • 限流削峰
    • 消息驱动系统
  • 三、消息队列的两种方式
    • 点对点模式
    • 发布/订阅模式
  • 四、常见的消息队列的产品
    • 1) RabbitMQ
    • 2) activeMQ:
    • 3) RocketMQ
    • 4) kafka
  • 五、Kafka的基本介绍

一、什么是消息队列

消息队列,英文名:Message Queue,经常缩写为MQ。从字面上来理解,消息队列是一种用来存储消息的队列 。来看一下下面的代码

上述代码,创建了一个队列,先往队列中添加了一个消息,然后又从队列中取出了一个消息。这说明了队列是可以用来存取消息的

总结:消息队列指的就是将数据放置到一个队列中, 从队列一端进入, 然后从另一端流出的过程

二、消息队列的应用场景

消息队列在实际应用中包括如下四个场景:

1、应用耦合:

多应用间通过消息队列对同一消息进行处理,避免调用接口失败导致整个过程失败;

2、异步处理:

多应用对消息队列中同一消息进行处理,应用间并发处理消息,相比串行处理,减少处理时间;

3、限流削峰:

广泛应用于秒杀或抢购活动中,避免流量过大导致应用系统挂掉的情况;

4、消息驱动的系统:

系统分为消息队列、消息生产者、消息消费者,生产者负责产生消息,消费者(可能有多个)负责对消息进行处理

下面详细介绍上述四个场景以及消息队列如何在上述四个场景中使用

异步处理

具体场景:用户为了使用某个应用,进行注册,系统需要发送注册邮件并验证短信。

对这两个操作的处理方式有两种:串行及并行。

1) 串行方式: 新注册信息生成后 , 先发送注册邮件, 再发送验证短信

注意 : 在这种方式下,需要最终发送验证短信后再返回给客户端

2) 并行处理:新注册信息写入后,由发短信和发邮件并行处理

注意: 在这种方式下,发短信和发邮件 需处理完成后再返回给客户端。

假设以上三个子系统处理的时间均为 50ms ,且不考虑网络延迟

则总的处理时间: 串行: 50+50+50=150ms ​

并行: 50+50 = 100ms

如果引入消息队列 , 在来看整体的执行效率 :

在写入消息队列后立即返回成功给客户端,则总的响应时间依赖于写入消息队列的时间,而写入消息队列的时间本身是可以很快的,基本可以忽略不计,因此总的处理时间相比串行提高了2倍,相比并行提高了一倍;

应用耦合

具体场景:

用户使用 QQ 相册上传一张图片,人脸识别系统会对该图片进行人脸识别,一般的做法是,服务器接收到图片后,图片上传系统立即调用人脸识别系统,调用完成后再返回成功,如下图所示: 如果引入消息队列 , 在来看整体的执行效率

该方法有如下缺点:

1) 人脸识别系统被调失败,导致图片上传失败;

2) 延迟高,需要人脸识别系统处理完成后,再返回给客户端,即使用户并不需要立即知道结果;

3) 图片上传系统与人脸识别系统之间互相调用,需要做耦合; 若使用消息队列:

此时图片上传系统并不需要关心人脸识别系统是否对这些图片信息的处理、以及何时对这些图片信息进行处理。

事实上,由于用户并不需要立即知道人脸识别结果,人脸识别系统可以选择不同的调度策略,按照闲时、忙时、正常时 间,对队列中的图片信息进行处理。

限流削峰

具体场景:

购物网站开展秒杀活动,一般由于瞬时访问量过大,服务器接收过大,会导致流量暴增,相关系统无法处理请求甚至崩溃。而加入消息队列后,系统可以从消息队列中取数据,相当于消息队列做了一次缓冲。

该方法有如下优点:

请求先入消息队列,而不是由业务处理系统直接处理,做了一次缓冲 , 极大地减少了业务处理系统的压力;

队列长度可以做限制,事实上,秒杀时,后入队列的用户无法秒杀到商品,这些请求可以直接被抛弃,返回活动已结束或商品已售完信息;

消息驱动系统

具体场景:用户新上传了一批照片, 人脸识别系统需要对这个用户的所有照片进行聚类,聚类完成后由对账系统重新生成用 户的人脸索引( 加快查询 ) 。这三个子系统间由消息队列连接起来,前一个阶段的处理结果放入队列中,后一个阶段从队列中获取消息继续处理。

该方法有如下优点:

避免了直接调用下一个系统导致当前系统失败;

每个子系统对于消息的处理方式可以更为灵活,可以选择收到消息时就处理,可以选择定时处理,也可以划分时间 段按不同处理速度处理;

三、消息队列的两种方式

点对点模式

点对点模式下包括三个角色

  • 消息队列
  • 发送者 (生产者)
  • 接收者(消费者)

消息发送者生产消息发送到 queue 中,然后消息接收者从 queue 中取出并且消费消息。消息被消费以后, queue 中不再有存储,所以消息接收者不可能消费到已经被消费的消息。 点对点模式特点:

每个消息只有一个接收者(Consumer)(即一旦被消费,消息就不再在消息队列中);

发送者和接收者间没有依赖性,发送者发送消息之后,不管有没有接收者在运行,都不会影响到发送者下次发送消息;

接收者在成功接收消息之后需向队列应答成功,以便消息队列删除当前接收的消息;

发布/订阅模式

发布 / 订阅模式下包括三个角色:

  • 角色主题(Topic)
  • 发布者(Publisher)
  • 订阅者(Subscriber)

发布者将消息发送到 Topic, 系统将这些消息传递给多个订阅者。 发布 / 订阅模式特点:

每个消息可以有多个订阅者;

发布者和订阅者之间有时间上的依赖性。针对某个主题(Topic)的订阅者,它必须创建一个订阅者之后,才能消费发布者的消息。

为了消费消息,订阅者需要提前订阅该角色主题,并保持在线运行;

四、常见的消息队列的产品

1) RabbitMQ

RabbitMQ 2007 年发布,是一个在 AMQP ( 高级消息队列协议 ) 基础上完成的,可复用的企业消息系统,是当前最主 流的消息中间件之一。

2) activeMQ:

ActiveMQ 是由 Apache 出品, ActiveMQ 是一个完全支持 JMS1.1 和 J2EE 1.4 规范的 JMS Provider 实现。它非常快速 ,支持多种语言的客户端和协议,而且可以非常容易的嵌入到企业的应用环境中,并有许多高级功能, 目前市场的活跃 度比较低, 在 java 领域正在被 RabbitMQ 替代

3) RocketMQ

RocketMQ 出自 阿里公司的开源产品,用 Java 语言实现,在设计时参考了 Kafka ,并做出了自己的一些改进,消息可靠性上比 Kafka 更好。 RocketMQ 在阿里集团被广泛应用在订单,交易,充值,流计算,消息推送,日志流式处理 等

4) kafka

Apache Kafka 是一个分布式消息发布订阅系统。它最初由 LinkedIn 公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log) ,之后成为 Apache 项目的一部分。 Kafka 系统快速、可扩展并且可持久化。它的分区特性,可复制和可容错都是其不错的特性。 各种消息队列产品的对比图:

五、Kafka的基本介绍

kafka 是最初由 linkedin 公司开发的,使用 scala 语言编写, kafka 是一个分布式,分区的,多副本的,多订阅者的日 志系统(分布式MQ 系统),可以用于搜索日志,监控日志,访问日志等 Kafka is a distributed,partitioned,replicated commit logservice 。

它提供了类似于 JMS 的特性,但是在设计实现上完全不同,此外它并不是JMS 规范的完整实现。

kafka 对消息保存时根据 Topic 进行归类,发送消息者成为 Producer, 消息 接受者成为Consumer, 此外 kafka 集群有多个 kafka 实例组成,每个实例 (server) 成为 broker 。

无论是 kafka 集群,还是producer和 consumer 都依赖于 zookeeper 来保证系统可用性集群保存一些 meta 信息

kakfa的特点:

  • 可靠性: 分布式, 分区 , 复制 和容错等
  • 可扩展性: kakfa消息传递系统轻松缩放, 无需停机
  • 耐用性: kafka使用分布式提交日志, 这个意味着消息会尽可能快速的保存在磁盘上, 因此它是持久的
  • 性能: kafka对于发布和订阅消息都具有高吞吐量, 即使存储了许多TB的消息, 他也爆出稳定的性能-kafka非常快: 保证零停机和零数据丢失

apache kafka 是一个分布式发布 - 订阅消息系统和一个强大的队列,可以处理大量的数据,并使能够将消息从一个 端点传递到另一个端点,kafka 适合离线和在线消息消费。 kafka 消息保留在磁盘上,并在集群内复制以防止数据丢失。kafka构建在 zookeeper 同步服务之上。它与 apache 和 spark 非常好的集成,应用于实时流式数据分析。

kafka的主要应用场景:

1) 指标分析 : kafka 通常用于操作监控数据 , 这设计聚合来自分布式应用程序和统计信息 , 以产生操作的数据集中反馈

2) 日志聚合解决方法 : kafka 可用于跨组织从多个服务器收集日志 , 并使他们一标准的合适提供给多个服务器

3) 流式处理 : 流式的处理框架 (spark, storm , flink) 从主题中读取数据 , 对其进行处理 , 并将处理后的结果数据写入新的主题, 供用户和应用程序使用 , kafka 的强耐久性在流处理的上下文中也非常的有用

到此这篇关于大数据Kafka:消息队列和Kafka基本介绍的文章就介绍到这了,更多相关大数据消息队列和Kafka内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 浅谈使用java实现阿里云消息队列简单封装

    一.前言 最近公司有使用阿里云消息队列的需求,为了更加方便使用,本人用了几天时间将消息队列封装成api调用方式以方便内部系统的调用,现在已经完成,特此记录其中过程和使用到的相关技术,与君共勉. 现在阿里云提供了两种消息服务:mns服务和ons服务,其中我认为mns是简化版的ons,而且mns的消息消费需要自定义轮询策略的,相比之下,ons的发布与订阅模式功能更加强大(比如相对于mns,ons提供了消息追踪.日志.监控等功能),其api使用起来更加方便,而且听闻阿里内部以后不再对mns进行新的开发

  • java实现消息队列的两种方式(小结)

    实现消息队列的两种方式 Apache ActiveMQ官方实例发送消息 直接在Apache官网http://activemq.apache.org/download-archives.html下载ActiveMQ源码 下载解压后拿到java代码实例 然后倒入IDE 如下: 请认真阅读readme.md文件,大致意思就是把项目打成两个jar包,然后启动服务,然后同时运行打的两个jar包,然后就能看到具体的调用信息.打jar包时直接利用maven打就行了,不用修改代码. 启动服务: 利用Spring

  • 消息队列-kafka消费异常问题

    目录 概述 重试一定次数(消息丢失) 加入到死讯队列(消息不丢失) 总结 概述 在kafka中,或者是说在任何消息队列中都有个消费顺序的问题.为了保证一个队列顺序消费,当当中一个消息消费异常时,必将影响后续队列消息的消费,这样业务岂不是卡住了.比如笔者举个最简单的例子:我发送1-100的消息,在我的处理逻辑当中 msg%5==0我就进行 int i=1/0操作,这必将抛异常,一直阻塞在msg=5上,后面6-100无法消费.下面笔者给出解决方案. 重试一定次数(消息丢失) @KafkaHandle

  • KOA+egg.js集成kafka消息队列的示例

    Egg.js : 基于KOA2的企业级框架 Kafka:高吞吐量的分布式发布订阅消息系统 本文章将集成egg + kafka + mysql 的日志系统例子 系统要求:日志记录,通过kafka进行消息队列控制 思路图: 这里消费者和生产者都由日志系统提供 λ.1 环境准备 ①Kafka 官网下载kafka后,解压 启动zookeeper: bin/zookeeper-server-start.sh config/zookeeper.properties 启动Kafka server 这里conf

  • .net msmq消息队列实例详解

    本文为大家分享了.net msmq消息队列实例代码,供大家参考,具体内容如下 1.msmq消息队列windows环境安装 控制面板---->程序和功能---->启用或关闭Windows程序---->Microsoft Message Queue(MSMQ)服务器 选中如图所示功能点击"确认"进行安装,安装好后可在 "计算机管理"中进行查看 2.创建消息队列实体对象 /// <summary> /// 消息实体 /// </summ

  • Spring boot 整合KAFKA消息队列的示例

    这里使用 spring-kafka 依赖和 KafkaTemplate 对象来操作 Kafka 服务. 一.添加依赖和添加配置项 1.1.在 Pom 文件中添加依赖 <dependency> <groupId>org.springframework.kafka</groupId> <artifactId>spring-kafka</artifactId> </dependency> 1.2.添加配置项 spring: kafka: b

  • 大数据Kafka:消息队列和Kafka基本介绍

    目录 一.什么是消息队列 二.消息队列的应用场景 异步处理 应用耦合 限流削峰 消息驱动系统 三.消息队列的两种方式 点对点模式 发布/订阅模式 四.常见的消息队列的产品 1) RabbitMQ 2) activeMQ: 3) RocketMQ 4) kafka 五.Kafka的基本介绍 一.什么是消息队列 消息队列,英文名:Message Queue,经常缩写为MQ.从字面上来理解,消息队列是一种用来存储消息的队列 .来看一下下面的代码 上述代码,创建了一个队列,先往队列中添加了一个消息,然后

  • Java分布式学习之Kafka消息队列

    目录 介绍 Kafka核心相关名称 kafka集群安装 kafka使用 kafka文件存储 Springboot整合kafka 介绍 Apache Kafka 是分布式发布-订阅消息系统,在 kafka官网上对 kafka 的定义:一个分布式发布-订阅消息传递系统. 它最初由LinkedIn公司开发,Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目.Kafka是一种快速.可扩展的.设计内在就是分布式的,分区的和可复制的提交日志服务. 注意:Kafka并没有遵循JMS规范(

  • 关于Kafka消息队列原理的总结

    目录 Kafka消息队列原理 Kafka的逻辑数据模型 Kafka的分发策略 Kafka的物理存储模型和查找数据的设计 Kafka的持久化策略设计 Kafka的节点间的数据一致性策略设计 Kafka的备份和负载均衡 Kafka消息队列内部实现原理 Kafka消息队列原理 最近在测试kafka的读写性能,所以借这个机会了解了kafka的一些设计原理,既然作为分布式系统,我们还是按照分布式的套路进行分析. Kafka的逻辑数据模型 生产者发送数据给服务端时,构造的是ProducerRecord<In

  • 通过pykafka接收Kafka消息队列的方法

    没有Kafka环境,所以也没有进行验证.感觉今后应该能用到,所以借抄在此,备查. pykafka使用示例,自动消费最新消息,不重复消费: # -* coding:utf8 *- from pykafka import KafkaClient host = '192.168.200.38' client = KafkaClient(hosts="%s:9092" % host) print client.topics # 生产者 # topicdocu = client.topics['

  • kafka 消息队列中点对点与发布订阅的区别说明

    目录 背景知识 1.JMS中定义 2.二者分析与区别 2.1 点对点模式 2.2 发布订阅模式 3.流行的消息队列模型比较 3.1 RabbitMQ 3.2 Kafka 背景知识 JMS一个在 Java标准化组织(JCP)内开发的标准(代号JSR 914).2001年6月25日,Java消息服务发布JMS 1.0.2b,2002年3月18日Java消息服务发布 1.1. Java消息服务(Java Message Service,JMS)应用程序接口是一个Java平台中关于面向消息中间件(MOM

  • Kafka中消息队列的两种模式讲解

    目录 Kafka消息队列的两种模式 1.点对点模式 2.发布/订阅模式 Kafka消息队列模型 Kafka消息队列的两种模式 消息队列包括两种模式,点对点模式(point to point, queue)和发布/订阅模式(publish/subscribe,topic) 1.点对点模式 点对点模式下包括三个角色: 消息队列 发送者 (生产者) 接收者(消费者) 消息发送者生产消息发送到queue中,然后消息接收者从queue中取出并且消费消息.消息被消费以后,queue中不再有存储,所以消息接收

  • 浅谈Java消息队列总结篇(ActiveMQ、RabbitMQ、ZeroMQ、Kafka)

    一.消息队列概述 消息队列中间件是分布式系统中重要的组件,主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构.目前使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ. 二.消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景.异步处理,应用解耦,流量削锋和消息通讯四个场景. 2.1异步处理 场景说明:用户注册后,需要发注册邮件和注册短信.传统的做法有两种 1.串行的方式;2.并行方式 a.串

  • Redis 中使用 list,streams,pub/sub 几种方式实现消息队列的问题

    目录 使用Redis实现消息队列 基于List的消息队列 分析下源码实现 基于Streams的消息队列 分析下源码实现 stream的结构 streamCG消费者组 streamConsumer消费者结构 发布订阅 普通的订阅 基于模式(pattern)的发布/订阅 看下源码实现 总结 参考 使用 Redis 实现消息队列 Redis 中也是可以实现消息队列 不过谈到消息队列,我们会经常遇到下面的几个问题 1.消息如何防止丢失: 2.消息的重复发送如何处理: 3.消息的顺序性问题: 关于 mq

随机推荐