MQ - 01 消息队列发展史&MQ通用架构

已于 2023-09-27 09:08:05 修改
阅读量1w 收藏 1
点赞数 1
分类专栏： 【小工匠聊架構】 文章标签： 架构 MQ 消息队列
于 2023-09-18 07:30:00 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/yangshangwei/article/details/132868863
版权
本文介绍了消息队列的发展历程，从ActiveMQ到RabbitMQ、Kafka、RocketMQ和Pulsar，分析了MQ的发展趋势和选型考虑因素。文章探讨了消息与流的融合，并对四款主流消息队列的特性和适用场景进行了对比，建议根据业务需求选择RocketMQ用于业务消息，Kafka用于流场景。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

文章目录

在这里插入图片描述

导图

在这里插入图片描述

Pre

MQ - 闲聊MQ一二事儿 （Kafka、RocketMQ 、Pulsar ）

MQ 发展史

在这里插入图片描述

基于 JMS 协议发展出来的 ActiveMQ 因为功能和稳定性问题，用的人比较少

ActiveMQ 项目最初是由 LogicBlaze 的创始人于 2004 年创建的，支持完成 JMS 规范的消息队列。因为生态、功能定

了解本专栏 订阅专栏 解锁全文 超级会员免费看
MQ - 35 四款MQ的架构设计与实现的对比
小工匠
09-29 9890
4 款主流消息队列所支持的功能清单在上面的表格中，你会发现一个现象，Pulsar 支持的功能最多，RabbitMQ 和 RocketMQ 其次，Kafka 支持的功能最少。原因和它们自身的定位和发展历史有关。接下来我们从功能出发，来分析一下这 4 款主流消息队列的原理和使用方式。先来个说明，这节课中的每个部分都是独立的，你可以挑感兴趣的内容进行学习。总结下来，你会发现不同消息队列在功能方面的支持是很不一样的，侧重点各有不同。但是同一个功能的底层实现原理，大家的思路基本是一致的。
消息队列的前世今生:技术演进与发展历程大揭秘
最新发布
AI天才研究院
05-23 773
消息队列的前世今生:技术演进与发展历程大揭秘 作者：禅与计算机程序设计艺术 1. 背景介绍 1.1 为什么需要消息队列？ 在信息系统高速发展的今天，软件架构越来越复杂，系统之间交互的频率和数据量也越来越大。传统
MQ - 闲聊MQ一二事儿 （Kafka、RocketMQ 、Pulsar ）
小工匠
07-24 1万+
ookeeper 是 cp 强一致架构的一种，其内部使用 zab 算法，进行信息同步和容灾，在信息量较小的情况下，性能较好，当信息交互变多，因为同步带来的性能损耗加大，性能和吞吐量降低。kafka 的整体性能收到了 topic 数量的限制，这和底层的存储有密不可分的关系，我们上面讲过，当消息来的时候，底层数据使用追加写入的方式，顺序写盘，使得整体的写性能大大提高，但这并不能代表所有情况，当我们 topic 数量从几个变成上千个的时候，情况就有所不同了。所以，针对不同场景选择合适的产品是非常关键的。
01 消息队列介绍
Java是世界上最好的语言
12-18 478
01 消息队列 Pt1 什么是MQ？ MQ（消息队列），是一种跨进程的通信服务，用于上下游系统传递消息。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程通信，进行分布式系统的集成。 MQ具有以下特点： 独立运行的服务。生产者和消费者都需要和MQ服务建立连接才能通信。 采用队列的数据结构，具有FIFO特性。 具有发布订阅模型。 Pt2 为什么用MQ？ 服务通信有很多种方式，尤其是在微服务大行其道的年代，基于HTTP、TCP、RPC、Spring.
消息队列20年：腾讯专家沉淀的MQ设计精要
QcloudCommunity的博客
07-12 637
作者是腾讯 TDMQ 初创团队的成员，在多年的业务中台的实践中，也频繁地使用到了 MQ，比如最常见的消息推送，异常信息的重试等等，对消息队列有深刻的了解。此篇文章，作者会站在时间维度讲解这二十年每款 MQ 诞生的背景以及解决了何种问题，让你能够更加清晰地了解到 MQ 的底层逻辑，帮助你学习今后可能会出现的新架构。欢迎阅读~
消息队列发展历史
梦回故里
01-09 1129
1983，Teknekron 提出了总线思想，设计了The Infomation Bus 1990-1993，IBM公司实现了WebSphere MQ 1997，Teknekron 实现了TIBCO 1997, 微软实现了MSMQ 2001，java提出了JMS模型 2003，apache提出了activemq 2004，出现了AMQP规范 2007，RabbitMQ诞生 2011，Kafka诞生，消息队列处理能力显著提升 ...
1、架构-服务架构演进史
qq_29434541的博客
05-05 1340
所谓的“后微服务时代”指的是在微服务架构广泛应用并成熟之后，行业开始探索更进一步的架构模式和技术，以解决微服务在实际应用中遇到的一些挑战，如服务管理的复杂性、数据一致性问题、服务间通信的开销等。在后微服务时代，人们探讨和采纳了一些新的概念和技术，以优化和超越传统微服务架构的限制。
MQ - 42 消息中台：搭建企业内部统一的消息服务
小工匠
10-12 9197
MQ - 02 基础篇_通讯协议我们知道了协议分为公有协议和私有协议。公有协议有 MQTT、AMQP、OpenMessaging 等等，主流消息队列一般会设计自己的私有协议，比如 Kafka 协议、Pulsar 协议、RocketMQ 的 Remoting 协议等。另外消息队列从使用场景的角度看，分为了消息和流两个方向。所以在业务架构中，一般会同时使用多种消息队列来满足不同的使用场景。但是同时使用多款消息队列，从业务视角来看会增加学习和使用成本，从公司视角看会增加运维和资源成本。
百度贴吧架构变迁史.pptx
03-03
数据切分策略被采用，将数据业务垂直划分，单机设置多副本，并利用消息队列（MQ）确保不同业务数据的一致性。这一阶段，贴吧开始引入LAMP（Linux、Apache、MySQL、PHP）架构，选择PHP作为主要开发语言，因为PHP有C/...
小工匠聊架构文章一览【不间断持续更新】
热门推荐
小工匠
11-12 8万+
文章摘要 本文系统梳理了微服务架构与分布式技术的核心知识体系，包含三大板块： 微服务布道系列：详细解析从单体架构到服务化的演进路径，涵盖服务注册发现、RPC调用、监控追踪等12个核心主题； 分布式理论篇：深入剖析CAP定理、BASE理论、Paxos算法等分布式系统基石理论； 分布式实战篇：聚焦事务、服务、缓存、存储四大场景，提供两阶段提交、TCC模型、热点key治理等20余种解决方案。文中配有清晰的技术架构图，每个主题均附详细技术文章链接，形成完整的技术图谱。
布道微服务_11监控系统选型与常见方案
小工匠
05-25 7万+
Pre 布道微服务_06微服务调用的监控中我们聊了聊监控系统的实现原理，简单来说主要包含 数据收集 数据传输 数据处理 数据展示 不同的监控系统实现方案，在这四个环节所使用的技术方案不同，适合的业务场景也不一样。 主流方案分类 （集中式日志 VS 时序数据库） 目前，比较流行的开源监控系统实现方案主要有两种： 以ELK为代表的集中式日志解决方案 以Graphite、TICK和Prometheus等为代表的时序数据库解决方案 接下来，我们简单总结下这几个常见的监控系统实现方案，谈谈它们的实现原..
布道微服务_15服务路由规则及实现
小工匠
05-29 4万+
文章目录Pre什么是服务路由服务路由的应用场景分组调用灰度发布流量切换读写分离服务路由的规则条件路由脚本路由获取服务路由的方式本地配置配置中心管理动态下发区别小结 Pre 布道微服务_14常见的五种负载均衡算法实现及其应用场景中了解了常用的客户端负载均衡算法，它帮我们解决了服务消费者如何从众多可用的服务节点中选取一个最合适的节点发起调用的问题。 但在业务中经常还会遇到这样的场景，比如服务 A 部署在北京、上海、广州三个数据中心，所有的服务节点按照所在的数据中心被分成了三组，那么服务 A 的消费者在发起调
布道微服务_17服务调用失败的解决方案
小工匠
05-30 4万+
文章目录Pre服务调用失败的处理手段超时重试双发熔断小结 Pre 我们知道，微服务相比于单体应用最大的不同之处在于，服务的调用从同一台机器内部的本地调用变成了不同机器之间的远程方法调用，但是这个过程也引入了两个不确定的因素。 一个是调用的执行是在服务提供者一端，即使服务消费者本身是正常的，服务提供者也可能由于诸如 CPU、网络 I/O、磁盘、内存、网卡等硬件原因导致调用失败，还有可能由于本身程序执行问题比如 GC 暂停导致调用失败。 另一个不确定因素是调用发生在两台机器之间，所以要经过网络传输，
布道微服务_16服务端故障的紧急避险措施
小工匠
05-29 4万+
文章目录Pre常见故障常见故障之应对措施集群故障之应对措施1. 限流2. 降级 Pre 单体应用改造成微服务的一个好处是可以减少故障影响范围，故障被局限在一个微服务系统本身，而不是整个单体应用都崩溃。那么具体到一个微服务系统，如果出现了故障，应该如何处理呢？ 常见故障 首先，回顾一下微服务系统可能出现故障的种类，主要有三种故障。 集群故障 微服务系统一般都是集群部署的，根据业务量大小而定，集群规模从几台到甚至上万台都有可能。一旦某些代码出现 bug，可能整个集群都会发生故障，不能提供对外提供服务。
布道微服务_12服务追踪系统选型与常见方案
小工匠
05-27 4万+
Pre 布道微服务_07服务调用追踪中我们饿聊了服务追踪系统的原理以及实现，简单回顾一下服务追踪系统的实现，主要包括三个部分。 埋点数据收集，负责在服务端进行埋点，来收集服务调用的上下文数据。 实时数据处理，负责对收集到的链路信息，按照 traceId 和 spanId 进行串联和存储。 数据链路展示，把处理后的服务调用数据，按照调用链的形式展示出来。 如果要自己从 0 开始实现一个服务追踪系统，针对以上三个部分都必须有相应的解决方案。 首先需要在业务代码的框架层开发调用拦截程序，在调用..
布道微服务_14常见的五种负载均衡算法实现及其应用场景
小工匠
05-27 4万+
Pre 假设订阅了一个别人的服务，从注册中心查询得到了这个服务的可用节点列表，而这个列表里包含了几十个节点，这个时候该选择哪个节点发起调用呢？那我们聊聊关于客户端负载均衡算法的问题吧。 为什么要引入负载均衡算法呢？主要有两个原因： 一个是要考虑调用的均匀性，也就是要让每个节点都接收到调用，发挥所有节点的作用； 另一个是要考虑调用的性能，也就是哪个节点响应最快，优先调用哪个节点。 常见的负载均衡算法 随机算法 随机算法，顾名思义就是从可用的服务节点中，随机挑选一个节点来访问。 在实现时，随机算法通..
布道微服务_13识别存活的服务节点几种解决方案
小工匠
05-27 4万+
[布道微服务_04服务的注册与发现](https://artisan.blog.youkuaiyun.com/article/details/123614001)中聊到注册中心原理的时候，以开源注册中心 ZooKeeper 为例，描述了它是如何管理注册到注册中心的节点的存活的。 ZooKeeper 判断注册中心节点存活的机制其实就是**注册中心摘除机制**，服务消费者以注册中心中的数据为准，当服务端节点有变更时，注册中心就会把变更通知给服务消费者，服务消费者就会调用注册中心来拉取最新的节点信息。 这种机制在大
布道微服务_10注册中心与RPC框架的选型
小工匠
03-22 4万+
文章目录开源注册中心Nacos其他关注的问题高可用性数据一致性CAP 三者不能被同时满足选型经验RPC框架选型 开源注册中心 Nacos 毫无疑问，现在就选Nacos即可 其他 Eureka 、Consul等 关注的问题 高可用性 实现方式主要有两个 集群部署 多机房部署 数据一致性 为了保证注册中心的高可用性，注册中心的部署往往都采用集群部署，并且还通常部署在不止一个数据中心。 那问题来了 多个数据中心之间如何保证数据一致？如何确保访问数据中心中任何一台机器都能得到正确的数据？ 说到这里就
布道微服务_04服务的注册与发现
小工匠
03-20 4万+
文章目录Pre注册中心原理注册中心实现方式注册中心 API集群部署目录存储服务健康状态检测服务状态变更通知白名单机制小结 Pre 布道微服务_03服务的发布和引用中我们聊了聊 服务发布和引用常用的三种方式 RESTful API XML 配置 IDL 文件 那下一个问题 ，如果我们已经使用其中一种方式发布了一个服务，并且部署好了服务，那调用这个服务，怎么知道部署服务的这台机器的地址呢？ 类比生活中的地图场景，地图会告诉我们目的地的地址 。 在分布式系统里， 这里就是注册中心， 将部署服务的机器
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小小工匠

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值