消息队列之 MetaQ 和 Kafka 哪个更香!(1)

简介: 消息队列之 MetaQ 和 Kafka 哪个更香!

image.png


消息队列

消息队列是一个用于接收消息、存储消息并且转发消息的中间件,主要是用于解决如下的场景:

  • 异步:A服务做了一些事情,异步发送消息给服务B;
  • 削峰/限流:类似一个蓄水池,比如说有些服务(例如电商服务的秒杀),请求量很高,服务端处理不过来,那么请求先放到消息队列里面,然后服务端按照自己的能力来消费处理;
  • 解耦:应用之间减少代码的耦合,使得应用的部署更加灵活;

消息队列有几个重要的概念模型:消息、队列、生产者、消费者,下面将介绍这几个基本概念:

  • 消息:消息是消息队列中的最基本概念,其本质上是一段数据,能够被多个应用程序所理解,是应用程序之间传递信息的载体,消息一般是由消息描述符和消息体组成;
  • 队列:队列是一种先进先出的数据结构,队列是由队列头部和队列尾部组成,一般需要在队列尾部进行插入,在队列头部进行删除;
  • 生产者:生产者主要是用来产生消息,并将消息放入队列的尾部;
  • 消费者:消费者主要是用来消费队列头部的消息;


MetaQ介绍

目前常用的消息中间件有kafka、RocketMQ和ActiveMQ等;今天我们将介绍MetaQ,MetaQ也是消息队列中间件,属于阿里内部的RocketMQ,下面将介绍MetaQ的相关概念:

       image.png

NameServer

命名服务,内部维护了topic和broker之间的对应关系,并且和所有broker保持心跳连接,在producer和consumer需要发布或者消费消息的时候,向nameserver发出请求来获取连接的broker的信息;

NameServer可以部署多个,每个之间互相独立,其他角色同时向多个NameServer机器上报状态信息,从而达到热备份的目的;

NameServer类似kafka中zookeeper的角色,那为什么不直接采用ZooKeeper角色呢,那是因为ZooKeeper有自动选举Master的功能,MetaQ的架构设计上决定了它不需要进行Master选举,而只需要使用一个轻量级的元数据服务器就可以了。


Broker

MetaQ的服务器,负责消息的中转、存储和转发,Broker可以分为Master和Slave,一个Master可以对接多个Slave,但是一个Slave只能对接一个Master,Master与Slave之间可以通过指定相同的BrokerName,不同的BrokerId来定义,BrokerId为0表示Master,不为0的表示Slave。

Master可以部署多个,每个Broker和NameServer集群中的所有节点建立长连接,定期的注册Topic信息到所有的NameServer上。

消息会发送到Master上,一旦Master上面记录成功,就直接返回成功,不用等待slave上面是否记录成功,slave会定时的去获取消息记录,所以slave和master上面会有一些时间差异;slave可以作为consumer的服务提供者,意思就是如果写入必须通过master,消费的时候则可以直接从slave上面获取。Master和slave都需要注册到nameserver上面,一旦master无法使用,客户端可以使用与之对应的slave。

每个Broker与Name Server集群中的所有节点建立长连接,定时(每隔30s)注册Topic信息到所有Name Server。Name Server定时(每隔10s)扫描所有存活broker的连接,如果Name Server超过2分钟没有收到心跳,则Name Server断开与Broker的连接。


Topic

Topic,即为发布或者订阅的主题,topic一般由多个队列组成,队列会平均的散列到多个Broker上面。Producer的发送机制会保证消息尽量平均的散列到所有队列上面去,最终的效果是所有的消息会平均的落在每个Broker上面。

Tag属于子Topic,主要的作用是给业务提供更大的灵活性,用以分流信息。


Producer

Producer,即消息的生产者,负责生产消息,producer的和Name server集群中随机的一个节点建立长连接,定期从nameServer中获取Topic路由信息,并向提供topic服务的master broker建立长连接,并定时向master发送心跳。producer会发布消息到master上面,然后由master同步给所有的slave。

Producer每隔30s从Name server获取所有topic队列的最新情况,这意味着如果Broker不可用,Producer最多30s能够感知,在此期间内发往Broker的所有消息都会失败。

Producer每隔30s向所有关联的broker发送心跳,Broker每隔10s中扫描所有存活的连接,如果Broker在2分钟内没有收到心跳数据,则关闭与Producer的连接。


Consumer

Consumer,即消息的消费者,负责消费消息,consumer与nameserver集群中的随机一个节点建立长连接,定期的从nameServer中获取topic路由信息,并向提供Topic服务的Master、Slave建立长连接,并且定时向Master、Slave发送心跳。Consumer既可以从Master上面订阅消息,也可以从Slave上面订阅消息,订阅规则由Broker配置决定。

Consumer每隔30s从Name server获取topic的最新队列情况,这意味着Broker不可用时,Consumer最多最需要30s才能感知。

Consumer每隔30s(由ClientConfig中heartbeatBrokerInterval决定)向所有关联的broker发送心跳,Broker每隔10s扫描所有存活的连接,若某个连接2分钟内没有发送心跳数据,则关闭连接;并向该Consumer Group的所有Consumer发出通知,Group内的Consumer重新分配队列,然后继续消费。


ConsumerGroup

ConsumerGroup,即消费者集群,多个消费者可以组成一个分组,拥有一个共同的分组名称,来共同消费一个topic下的消息,每个消费者消费部分消息。


Message

Message,即生产或者消费的消息,负载用户的数据并且在producer、broker和consumer之间传输。


Offset

消息在Broker上的每个分区都是组织成一个文件列表,消费者拉取数据的时候需要知道数据在文件中的偏移量,这个偏移量就是offset。Offset是一个绝对的偏移量,服务器会将offset转化为具体文件的相对偏移量。


目录
相关文章
|
2月前
|
消息中间件 存储 负载均衡
2024消息队列“四大天王”:Rabbit、Rocket、Kafka、Pulsar巅峰对决
本文对比了 RabbitMQ、RocketMQ、Kafka 和 Pulsar 四种消息队列系统,涵盖架构、性能、可用性和适用场景。RabbitMQ 以灵活路由和可靠性著称;RocketMQ 支持高可用和顺序消息;Kafka 专为高吞吐量和低延迟设计;Pulsar 提供多租户支持和高可扩展性。性能方面,吞吐量从高到低依次为
183 1
|
3月前
|
消息中间件 Java Kafka
初识Apache Kafka:搭建你的第一个消息队列系统
【10月更文挑战第24天】在数字化转型的浪潮中,数据成为了企业决策的关键因素之一。而高效的数据处理能力,则成为了企业在竞争中脱颖而出的重要武器。在这个背景下,消息队列作为连接不同系统和服务的桥梁,其重要性日益凸显。Apache Kafka 是一款开源的消息队列系统,以其高吞吐量、可扩展性和持久性等特点受到了广泛欢迎。作为一名技术爱好者,我对 Apache Kafka 产生了浓厚的兴趣,并决定亲手搭建一套属于自己的消息队列系统。
120 2
初识Apache Kafka:搭建你的第一个消息队列系统
|
4月前
|
消息中间件 中间件 Kafka
解锁Kafka等消息队列中间件的测试之道
在这个数字化时代,分布式系统和消息队列中间件(如Kafka、RabbitMQ)已成为日常工作的核心组件。本次公开课由前字节跳动资深专家KK老师主讲,深入解析消息队列的基本原理、架构及测试要点,涵盖功能、性能、可靠性、安全性和兼容性测试,并探讨其主要应用场景,如应用解耦、异步处理和限流削峰。课程最后设有互动答疑环节,助你全面掌握消息队列的测试方法。
|
6月前
|
图形学 人工智能 C#
从零起步,到亲手实现:一步步教你用Unity引擎搭建出令人惊叹的3D游戏世界,绝不错过的初学者友好型超详细指南 ——兼探索游戏设计奥秘与实践编程技巧的完美结合之旅
【8月更文挑战第31天】本文介绍如何使用Unity引擎从零开始创建简单的3D游戏世界,涵盖游戏对象创建、物理模拟、用户输入处理及动画效果。Unity是一款强大的跨平台游戏开发工具,支持多种编程语言,具有直观编辑器和丰富文档。文章指导读者创建新项目、添加立方体对象、编写移动脚本,并引入基础动画,帮助初学者快速掌握Unity开发核心概念,迈出游戏制作的第一步。
377 1
|
6月前
|
消息中间件 传感器 缓存
为什么Kafka能秒杀众多消息队列?揭秘它背后的五大性能神器,让你秒懂Kafka的极速之道!
【8月更文挑战第24天】Apache Kafka作为分布式流处理平台的领先者,凭借其出色的性能和扩展能力广受好评。本文通过案例分析,深入探讨Kafka实现高性能的关键因素:分区与并行处理显著提升吞吐量;批量发送结合压缩算法减少网络I/O次数及数据量;顺序写盘与页缓存机制提高写入效率;Zero-Copy技术降低CPU消耗;集群扩展与负载均衡确保系统稳定性和可靠性。这些机制共同作用,使Kafka能够在处理大规模数据流时表现出色。
84 3
|
20天前
|
消息中间件 存储 缓存
kafka 的数据是放在磁盘上还是内存上,为什么速度会快?
Kafka的数据存储机制通过将数据同时写入磁盘和内存,确保高吞吐量与持久性。其日志文件按主题和分区组织,使用预写日志(WAL)保证数据持久性,并借助操作系统的页缓存加速读取。Kafka采用顺序I/O、零拷贝技术和批量处理优化性能,支持分区分段以实现并行处理。示例代码展示了如何使用KafkaProducer发送消息。
|
4月前
|
消息中间件 存储 运维
为什么说Kafka还不是完美的实时数据通道
【10月更文挑战第19天】Kafka 虽然作为数据通道被广泛应用,但在实时性、数据一致性、性能及管理方面存在局限。数据延迟受消息堆积和分区再平衡影响;数据一致性难以达到恰好一次;性能瓶颈在于网络和磁盘I/O;管理复杂性涉及集群配置与版本升级。
185 1
|
4月前
|
消息中间件 Java Kafka
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
83 1
|
6月前
|
消息中间件 Java Kafka
Kafka不重复消费的终极秘籍!解锁幂等性、偏移量、去重神器,让你的数据流稳如老狗,告别数据混乱时代!
【8月更文挑战第24天】Apache Kafka作为一款领先的分布式流处理平台,凭借其卓越的高吞吐量与低延迟特性,在大数据处理领域中占据重要地位。然而,在利用Kafka进行数据处理时,如何有效避免重复消费成为众多开发者关注的焦点。本文深入探讨了Kafka中可能出现重复消费的原因,并提出了四种实用的解决方案:利用消息偏移量手动控制消费进度;启用幂等性生产者确保消息不被重复发送;在消费者端实施去重机制;以及借助Kafka的事务支持实现精确的一次性处理。通过这些方法,开发者可根据不同的应用场景灵活选择最适合的策略,从而保障数据处理的准确性和一致性。
433 9
|
6月前
|
消息中间件 负载均衡 Java
"Kafka核心机制揭秘:深入探索Producer的高效数据发布策略与Java实战应用"
【8月更文挑战第10天】Apache Kafka作为顶级分布式流处理平台,其Producer组件是数据高效发布的引擎。Producer遵循高吞吐、低延迟等设计原则,采用分批发送、异步处理及数据压缩等技术提升性能。它支持按消息键值分区,确保数据有序并实现负载均衡;提供多种确认机制保证可靠性;具备失败重试功能确保消息最终送达。Java示例展示了基本配置与消息发送流程,体现了Producer的强大与灵活性。
103 3

热门文章

最新文章