MQ消息队列的12点核心原理总结

1. 消息生产者、消息者、队列
  • 消息生产者Producer:发送消息到消息队列。
  • 消息消费者Consumer:从消息队列接收消息。
  • Broker:概念来自与Apache ActiveMQ,指MQ的服务端,帮你把消息从发送端传送到接收端。
  • 消息队列Queue:一个先进先出的消息存储区域。消息按照顺序发送接收,一旦消息被消费处理,该消息将从队列中删除。
2.设计Broker主要考虑

1)消息的转储:在更合适的时间点投递,或者通过一系列手段辅助消息最终能送达消费机。

2)规范一种范式和通用的模式,以满足解耦、最终一致性、错峰等需求。

3)其实简单理解就是一个消息转发器,把一次RPC做成两次RPC。发送者把消息投递到broker,broker再将消息转发一手到接收端。

总结起来就是两次RPC加一次转储,如果要做消费确认,则是三次RPC。

3. 点对点消息队列模型

点对点模型 用于 消息生产者 和 消息消费者 之间 点到点 的通信。

点对点模式包含三个角色:

  • 消息队列(Queue)
  • 发送者(Sender)
  • 接收者(Receiver)

每个消息都被发送到一个特定的队列,接收者从队列中获取消息。队列保留着消息,可以放在 内存 中也可以 持久化,直到他们被消费或超时。

特点

每个消息只有一个消费者(Consumer)(即一旦被消费,消息就不再在消息队列中) 发送者和接收者之间在时间上没有依赖性 接收者在成功接收消息之后需向队列应答成功

4. 发布订阅消息模型Topic

发布订阅模型包含三个角色:

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

多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。

特点

  • 每个消息可以有多个消费者:和点对点方式不同,发布消息可以被所有订阅者消费
  • 发布者和订阅者之间有时间上的依赖性。
  • 针对某个主题(Topic)的订阅者,它必须创建一个订阅者之后,才能消费发布者的消息。
  • 为了消费消息,订阅者必须保持运行的状态。
5.点对点和发布订阅的区别

生产者发送一条消息到队列queue,只有一个消费者能收到。

发布者发送到topic的消息,只有订阅了topic的订阅者才会收到消息。

6. 消息的顺序性保证

基于Queue消息模型,利用FIFO先进先出的特性,可以保证消息的顺序性。

7. 消息的ACK机制

即消息的Ackownledge确认机制,

为了保证消息不丢失,消息队列提供了消息Acknowledge机制,即ACK机制,当Consumer确认消息已经被消费处理,发送一个ACK给消息队列,此时消息队列便可以删除这个消

息了。如果Consumer宕机/关闭,没有发送ACK,消息队列将认为这个消息没有被处理,会将这个消息重新发送给其他的Consumer重新消费处理。

8.最终一致性的设计思路

主要是用“记录”和“补偿”的方式。

本地事务维护业务变化和通知消息,一起落地,然后RPC到达broker,在broker成功落地后,RPC返回成功,本地消息可以删除。否则本地消息一直靠定时任务轮询不断重发,这样就保证了消息可靠落地broker。

broker往consumer发送消息的过程类似,一直发送消息,直到consumer发送消费成功确认。

我们先不理会重复消息的问题,通过两次消息落地加补偿,下游是一定可以收到消息的。然后依赖状态机版本号等方式做判重,更新自己的业务,就实现了最终一致性。

如果出现消费方处理过慢消费不过来,要允许消费方主动ack error,并可以与broker约定下次投递的时间。

对于broker投递到consumer的消息,由于不确定丢失是在业务处理过程中还是消息发送丢失的情况下,有必要记录下投递的IP地址。决定重发之前询问这个IP,消息处理成功了吗?如果询问无果,再重发。

事务:本地事务,本地落地,补偿发送。本地事务做的,是业务落地和消息落地的事务,而不是业务落地和RPC成功的事务。消息只要成功落地,很大程度上就没有丢失的风险。

9. 消息的事务支持

消息的收发处理支持事务,例如:在任务中心场景中,一次处理可能涉及多个消息的接收、处理,这应该处于同一个事务范围内,如果一个消息处理失败,事务回滚,消息重新回到队列中。

10. 消息的持久化

消息的持久化,对于一些关键的核心业务来说是非常重要的,启用消息持久化后,消息队列宕机重启后,消息可以从持久化存储恢复,消息不丢失,可以继续消费处理。

11. 消息队列的高可用性

在实际生产环境中,使用单个实例的消息队列服务,如果遇到宕机、重启等系统问题,消息队列就无法提供服务了,因此很多场景下,我们希望消息队列有高可用性支持,例如

RabbitMQ的镜像集群模式的高可用性方案,ActiveMQ也有基于LevelDB+ZooKeeper的高可用性方案,以及Kafka的Replication机制等。

12.消息队列的选型和应用场景

具体请参考:高并发架构系列:分布式之消息队列的特点、选型、及应用场景详解

来源:http://www.1994july.club/seo/?p=2800

原文地址:https://www.cnblogs.com/1994july/p/12057026.html

时间: 2024-10-27 01:12:37

MQ消息队列的12点核心原理总结的相关文章

阿里云ACE共创空间——MQ消息队列产品测试

一.产品背景消息队列是阿里巴巴集团自主研发的专业消息中间件. 产品基于高可用分布式集群技术,提供消息订阅和发布.消息轨迹查询.定时(延时)消息.资源统计.监控报警等一系列消息云服务,是企业级互联网架构的核心产品. MQ 目前提供 TCP .MQTT 两种协议层面的接入方式,支持 Java.C++ 以及 .NET 不同语言,方便不同编程语言开发的应用快速接入 MQ 消息云服务. 用户可以将应用部署在阿里云 ECS.企业自建云,或者嵌入到移动端.物联网设备中与 MQ 建立连接进行消息收发,同时本地开

MQ(消息队列)常见的应用场景解析

前言 j提高系统性能首先考虑的是数据库的优化,之前一篇文章<数据库的使用你可能忽略了这些>中有提到过开发中,针对数据库需要注意的事项.但是数据库因为历史原因,横向扩展是一件非常复杂的工程,所有我们一般会尽量把流量都挡在数据库之前. 不管是无限的横向扩展服务器,还是纵向阻隔到达数据库的流量,都是这个思路.阻隔直达数据库的流量,缓存组件和消息组件是两大杀器. MQ简介 MQ,Message queue,消息队列,就是指保存消息的一个容器.具体的定义这里就不类似于数据库.缓存等,用来保存数据的.当然

Spring Boot:使用Rabbit MQ消息队列

综合概述 消息队列 消息队列就是一个消息的链表,可以把消息看作一个记录,具有特定的格式以及特定的优先级.对消息队列有写权限的进程可以向消息队列中按照一定的规则添加新消息,对消息队列有读权限的进程则可以从消息队列中读走消息,而消息队列就是在消息的传输过程中保存消息的容器,你可以简单的把消息队列理解为类似快递柜,快递员(消息发布者)往快递柜(消息队列)投递物件(消息),接受者(消息订阅者)从快递柜(消息队列)接收物件(消息),当然消息队列往往还包含一些特定的消息传递和接收机制. 消息队列作为分布式系

中间件 | mq消息队列解说

消息队列 1.1 什么是消息队列 我们可以把消息队列比作是一个存放消息的容器,当我们需要使用消息的时候可以取出消息供自己使用.消息队列是分布式系统中重要的组件,使用消息队列主要是为了通过异步处理提高系统性能和削峰.降低系统耦合性.目前使用较多的消息队列有ActiveMQ,RabbitMQ,Kafka,RocketMQ. 1.2 为什么要用消息队列 使用消息队列主要有两点好处: 1.通过异步处理提高系统性能(削峰.减少响应所需时间; 2.降低系统耦合性.[结合你自己的项目来回答] 1.2.1 通过

MQ消息队列之MSMQ

主要参考文章: 消息队列(Message Queue)简介及其使用

SpringBoot日记——MQ消息队列整合(二)

基于第一篇文章搭建好环境以后,我们这篇文章继续介绍如何在springboot中使用RabbitMQ. 1).单播:添加好pom文件和自定义配置后,来看: @Autowired RabbitTemplate rabbitTemplate; @Test public void contextLoads() { // 对象被默认JAVA序列化发送,参数:Exchange,routingKey,消息 rabbitTemplate.convertAndSend("exchange.direct"

MQ消息队列(2)—— Java消息服务接口(JMS)

一.理解JMS   1.什么是JMS?         JMS即Java消息服务(Java Message Service)应用程序接口,API是一个消息服务的标准或者说是规范,允许应用程序组件基于JavaEE平台创建.发送.接收和读取消息.它使分布式通信耦合度更低,消息服务更加可靠以及异步性. 我们可以简单的理解:两个应用程序之间需要进行通信,我们使用一个JMS服务,进行中间的转发,通过JMS 的使用,我们可以解除两个程序之间的耦合. JMS不是消息队列,更不是某种消息队列协议.JMS是Jav

MQ(消息队列)学习

转自: http://book.51cto.com/art/201502/466288.htm         为什么我们需要MQ? 而这就是MQ :一个高效的可嵌入库,它解决了大部分应用程序需要解决的问题,变得在网络上有良好的可伸缩性,而没有多少成本. 具体做法是: 它在后台线程异步处理I/O.这些线程使用无锁数据结构与应用程序线程进行通信,所以并发MQ 应用程序不再需要锁.信号量,或其他等待状态. 组件可以动态地来去自如,而MQ 会自动重新连接.这意味着你可以以任何顺序启动组件.你可以创建“

MQ消息队列在软件开发中的作中

MQ的作用是非常之大的. 1.解耦. 当一个大型的系统.比如,商城系统.包括以下的功能: 1.发邮件 2.发短信 3.抽奖 4.搜索等 如果你都用一台服务器,做到一个程序里,代码会非常庞大,不利于维护.同时一台服务器的机器性能也跟不上. 我们用MQ来做,它们之间的通信,直接用MQ. 2.销峰. 假如你的秒杀活动,同时有一大批人在抢购,这个时候,如果你每个人都等待走完整的流程,那么系统会非常的延迟.我们也没有办法保证一定是按顺序执行的.有可能会多买,两个用户同时中奖等,数据不完.如果我们可以把用户