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

已于 2023-09-27 09:08:05 修改 769 收藏
分类专栏： 【小工匠聊架構】 文章标签： 架构 MQ 消息队列
于 2023-09-18 07:30:00 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/yangshangwei/article/details/132868863
版权
了解本专栏 订阅专栏 解锁全文 超级会员免费看
阅读终点，创作起航，您可以撰写心得或摘录文章要点写篇博文。去创作
小小工匠
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
订阅专栏
mq-http-nodejs-sdk:阿里云消息队列(MQ) Http Nodejs SDK
05-30
MQ Nodejs HTTP SDK Alyun MQ 文档： : 阿里云MQ控制台： ://ons.console.aliyun.com 安装 添加依赖@aliyunmq/mq-http-sdk ，从获取最新版本 npm install --save 注意：nodejs >= 7.6.0 文档 笔记 Http 消费者只支持定时器 msg（少于 3 天），无论 msg 是从 http 还是 tcp 协议产生的。 仅在特殊服务器集群中支持订购。 样本（github） 示例（code.aliyun.com） 发布消息 消费消息 交易讯息 发布订单消息 消费订单消息
Z-MQ-01烟雾浓度传感器,mq2烟雾传感器报警浓度,C/C++
08-09
烟雾浓度传感器Z-MQ-01
rabbitmq-producer:Rabbit MQ-ConsumerProducer消息队列
03-06
rabbitmq-producer:Rabbit MQ-ConsumerProducer消息队列
get-msg-from-MQ-using-java.rar_MQ_java mq_java 消息队列_mq get
09-14
java客户端从MQ队列接收消息的三种方法
Go-MQ-消息队列代理支持http2
08-14
MQ - 消息队列代理支持http2。a simple in-memory message broker
常用消息队列介绍和对比
朝雨忆轻尘
07-30 540
消息队列是分布式应用间交换信息的重要组件，消息队列可驻留在内存或磁盘上, 队列可以存储消息直到它们被应用程序读走。 通过消息队列，应用程序可以在不知道彼此位置的情况下独立处理消息，或者在处理消息前不需要等待接收此消息。 所以消息队列可以解决应用解耦、异步消息、流量削锋等问题，是实现高性能、高可用、可伸缩和最终一致性架构中不可以或缺的一环。 现在比较常见的消息队列产品主要有ActiveMQ、R...
应用消息队列设计可以解决哪些实际问题？
纸上得来终觉浅，绝知此事要躬行
03-29 1万+
消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。消息中间件到底该如何
一文带你入门了解“零之禅“消息队列ZeroMQ
董哥的黑板报
05-08 1万+
一、ZeroMQ概述 ZeroMQ（又名ØMQ，MQ，或zmq）看起来像一个可嵌入的网络库，但其作用就像一个并发框架 ZeroMQ类似于标准Berkeley套接字，其提供了各种传输工具，如进程内、进程间、TCP和组播中进行原子消息传送的套接字 你可以使用各种模式实现N对N的套接字连接，这些模式包括：扇出、发布-订阅、任务分配、请求-应答 ZeroMQ的速度足够快，因此可充当集群产品的结构 ...
小工匠聊架构文章一览【不间断持续更新】
热门推荐
小工匠
11-12 3万+
文章目录超高并发设计技术杂谈 超高并发设计 小工匠聊架构-超高并发秒杀系统设计 01_总体原则和架构演进 小工匠聊架构-超高并发秒杀系统设计 02_数据的动静分离 小工匠聊架构-超高并发秒杀系统设计 03_热点数据的处理 小工匠聊架构-超高并发秒杀系统设计 04_流量削峰设计 小工匠聊架构-超高并发秒杀系统设计 05_服务端性能优化 小工匠聊架构-超高并发秒杀系统设计 06_数据一致性 小工匠聊架构-超高并发秒杀系统设计 07_Plan B 的设计 技术杂谈 小工匠聊架构-写给研发工程师的全链路压测 小
布道微服务_15服务路由规则及实现
小工匠
05-29 3万+
文章目录Pre什么是服务路由服务路由的应用场景分组调用灰度发布流量切换读写分离服务路由的规则条件路由脚本路由获取服务路由的方式本地配置配置中心管理动态下发区别小结 Pre 布道微服务_14常见的五种负载均衡算法实现及其应用场景中了解了常用的客户端负载均衡算法，它帮我们解决了服务消费者如何从众多可用的服务节点中选取一个最合适的节点发起调用的问题。 但在业务中经常还会遇到这样的场景，比如服务 A 部署在北京、上海、广州三个数据中心，所有的服务节点按照所在的数据中心被分成了三组，那么服务 A 的消费者在发起调
布道微服务_11监控系统选型与常见方案
小工匠
05-25 3万+
Pre 布道微服务_06微服务调用的监控中我们聊了聊监控系统的实现原理，简单来说主要包含 数据收集 数据传输 数据处理 数据展示 不同的监控系统实现方案，在这四个环节所使用的技术方案不同，适合的业务场景也不一样。 主流方案分类 （集中式日志 VS 时序数据库） 目前，比较流行的开源监控系统实现方案主要有两种： 以ELK为代表的集中式日志解决方案 以Graphite、TICK和Prometheus等为代表的时序数据库解决方案 接下来，我们简单总结下这几个常见的监控系统实现方案，谈谈它们的实现原..
布道微服务_16服务端故障的紧急避险措施
小工匠
05-29 3万+
文章目录Pre常见故障常见故障之应对措施集群故障之应对措施1. 限流2. 降级 Pre 单体应用改造成微服务的一个好处是可以减少故障影响范围，故障被局限在一个微服务系统本身，而不是整个单体应用都崩溃。那么具体到一个微服务系统，如果出现了故障，应该如何处理呢？ 常见故障 首先，回顾一下微服务系统可能出现故障的种类，主要有三种故障。 集群故障 微服务系统一般都是集群部署的，根据业务量大小而定，集群规模从几台到甚至上万台都有可能。一旦某些代码出现 bug，可能整个集群都会发生故障，不能提供对外提供服务。
布道微服务_17服务调用失败的解决方案
小工匠
05-30 3万+
文章目录Pre服务调用失败的处理手段超时重试双发熔断小结 Pre 我们知道，微服务相比于单体应用最大的不同之处在于，服务的调用从同一台机器内部的本地调用变成了不同机器之间的远程方法调用，但是这个过程也引入了两个不确定的因素。 一个是调用的执行是在服务提供者一端，即使服务消费者本身是正常的，服务提供者也可能由于诸如 CPU、网络 I/O、磁盘、内存、网卡等硬件原因导致调用失败，还有可能由于本身程序执行问题比如 GC 暂停导致调用失败。 另一个不确定因素是调用发生在两台机器之间，所以要经过网络传输，
布道微服务_12服务追踪系统选型与常见方案
小工匠
05-27 3万+
Pre 布道微服务_07服务调用追踪中我们饿聊了服务追踪系统的原理以及实现，简单回顾一下服务追踪系统的实现，主要包括三个部分。 埋点数据收集，负责在服务端进行埋点，来收集服务调用的上下文数据。 实时数据处理，负责对收集到的链路信息，按照 traceId 和 spanId 进行串联和存储。 数据链路展示，把处理后的服务调用数据，按照调用链的形式展示出来。 如果要自己从 0 开始实现一个服务追踪系统，针对以上三个部分都必须有相应的解决方案。 首先需要在业务代码的框架层开发调用拦截程序，在调用..
布道微服务_13识别存活的服务节点几种解决方案
小工匠
05-27 3万+
[布道微服务_04服务的注册与发现](https://artisan.blog.csdn.net/article/details/123614001)中聊到注册中心原理的时候，以开源注册中心 ZooKeeper 为例，描述了它是如何管理注册到注册中心的节点的存活的。 ZooKeeper 判断注册中心节点存活的机制其实就是**注册中心摘除机制**，服务消费者以注册中心中的数据为准，当服务端节点有变更时，注册中心就会把变更通知给服务消费者，服务消费者就会调用注册中心来拉取最新的节点信息。 这种机制在大
布道微服务_14常见的五种负载均衡算法实现及其应用场景
小工匠
05-27 3万+
Pre 假设订阅了一个别人的服务，从注册中心查询得到了这个服务的可用节点列表，而这个列表里包含了几十个节点，这个时候该选择哪个节点发起调用呢？那我们聊聊关于客户端负载均衡算法的问题吧。 为什么要引入负载均衡算法呢？主要有两个原因： 一个是要考虑调用的均匀性，也就是要让每个节点都接收到调用，发挥所有节点的作用； 另一个是要考虑调用的性能，也就是哪个节点响应最快，优先调用哪个节点。 常见的负载均衡算法 随机算法 随机算法，顾名思义就是从可用的服务节点中，随机挑选一个节点来访问。 在实现时，随机算法通..
布道微服务_10注册中心与RPC框架的选型
小工匠
03-22 3万+
文章目录开源注册中心Nacos其他关注的问题高可用性数据一致性CAP 三者不能被同时满足选型经验RPC框架选型 开源注册中心 Nacos 毫无疑问，现在就选Nacos即可 其他 Eureka 、Consul等 关注的问题 高可用性 实现方式主要有两个 集群部署 多机房部署 数据一致性 为了保证注册中心的高可用性，注册中心的部署往往都采用集群部署，并且还通常部署在不止一个数据中心。 那问题来了 多个数据中心之间如何保证数据一致？如何确保访问数据中心中任何一台机器都能得到正确的数据？ 说到这里就
布道微服务_04服务的注册与发现
小工匠
03-20 3万+
文章目录Pre注册中心原理注册中心实现方式注册中心 API集群部署目录存储服务健康状态检测服务状态变更通知白名单机制小结 Pre 布道微服务_03服务的发布和引用中我们聊了聊 服务发布和引用常用的三种方式 RESTful API XML 配置 IDL 文件 那下一个问题 ，如果我们已经使用其中一种方式发布了一个服务，并且部署好了服务，那调用这个服务，怎么知道部署服务的这台机器的地址呢？ 类比生活中的地图场景，地图会告诉我们目的地的地址 。 在分布式系统里， 这里就是注册中心， 将部署服务的机器
布道微服务_01单体到服务化的演进
小工匠
03-17 3万+
文章目录小白的困惑 ？？？What概念单体vs微服务服务化微服务 小白的困惑 ？？？ 提到微服务等新技术，大部分人的反应先是惊喜，继而无奈。 惊喜的是新技术能带来非常多的遍历，无奈的是团队规模和能力又反过来制约了我们采用新技术。 我梳理下几个通用的困惑 微服务是架构师的事儿，业务开发不用关心？ 我们的业务体量有必要上微服务吗？ 微服务特别复杂，没个一个相当的研发团队是不是就无法落地？ … 首先我们梳理一下一般的软件演进过程哈 首先一个新产品，一开始团队规模也不大，想着快速迭代，采用了单体应用的架构
javamq消息队列
最新发布
07-27
JavaMQ（Java Message Queue）是一个基于Java语言开发的消息队列系统。它提供了一种可靠的异步通信机制，用于在分布式系统中传递消息。 JavaMQ使用发布-订阅模型，它将消息发送方称为"发布者"，将消息接收方称为"订阅者"。发布者将消息发送到消息队列中，而订阅者则从队列中获取消息进行处理。这种模型可以实现解耦，发布者和订阅者之间不需要直接通信，而是通过消息队列进行中间传递。 JavaMQ提供了一些重要的特性，包括： 1. 可靠性：JavaMQ确保消息的可靠传递。即使在系统故障或网络中断的情况下，消息也不会丢失。 2. 持久化：JavaMQ可以将消息持久化到磁盘上，以防止系统故障导致消息丢失。 3. 事务支持：JavaMQ支持事务，可以保证消息的原子性，即要么全部发送成功，要么全部失败。 4. 高性能：JavaMQ具有高吞吐量和低延迟的特点，能够处理大量的消息并快速地进行传递。 5. 扩展性：JavaMQ可以通过增加消息队列的数量来实现横向扩展，以满足系统的需求。 总的来说，JavaMQ是一个功能强大的消息队列系统，可用于构建可靠的分布式系统，并实现异步通信和解耦。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

小小工匠

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

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

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

打赏作者

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

抵扣说明：

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

余额充值