如何保证MQ消息必达

此文章属于笔记,原属58沈剑

一、MQ消息必达,架构上的两个核心设计点:

  1. 消息落地
  2. 消息超时、重传、确认
  3. 四大部件:发送端 接收端 服务端 固化存储组成

二、上半场消息必达以及消息重复问题

  1. 上半场的流程

    1. 发送端MQ-client 将消息发送给服务端MQ-server
    2. 服务端MQ-server将消息落地
    3. 服务端MQ-server 回ACK(表示确认) 2.如果3丢失 发送端在超时后,又会发送一遍,此时重发是MQ-client发起的,消息处理的是MQ-server 为了避免2 重复落地,对每条MQ消息系统内部需要生成一个inner-msg-id,作为去重和幂等的依据,这个内部消息ID 的特点是
    4. 全局唯一
    5. MQ生成,具备业务无关性,对消息发送方和消息接收

三、下半场的消息必达以及消息重复问题

  1. 下半场的流程

    1. 服务端将消息发给MQ-client
    2. MQ-client将消息消费 并通知MQ-server
    3. MQ-server 落地消息删除
  2. 需要强调的是,接收端MQ-client回ACK消息是MQ-client主动发起的,因为MQ-server不知道接收端何时消费完。 3.如果5丢失,那么在超时后MQ-server会重新发送消息,此时可能导致MQ-client收到重复消息,为了保证业务的幂等性,业务消息中,必须有一个biz-id,作为去重的依据,这个业务ID的特性是
    1. 对于同一个业务场景,全局唯一
    2. 由业务消息发送方生成,业务相关
    3. 由业务消费方消费判断重复问题,以保证幂等

四、总结

MQ为了保证消息必达,消息上下半场均可能发送重复消息,如何保证消息的幂等性呢

  1. 上半场,MQ-server生成inner-msg-id,保证上半场幂等 此ID全局唯一,业务无关,由MQ保证,对上下MQ-client屏蔽
  2. 下半场,由发送方带入biz-id 业务方接受并判断重复问题,保证幂等,这个ID对单业务唯一,业务相关,对MQ透明 结论 幂等性,不仅对MQ有要求,对业务上下游也有要求
时间: 2024-10-05 02:57:44

如何保证MQ消息必达的相关文章

WebSphere MQ消息通道管理总结

WebSphere MQ作为IBM软件家族的消息传输中间件产品,以其出色的特性和功能在业界享有盛誉.WebSphere MQ独特的安全机制.简便快速的编程风格.卓越不凡的稳定性.可扩展性和跨平台性,以及强大的消息通讯能力,使得它在银行.电信,还是在交通运输.政府机关等各行各业,赢得了很高的市场份额.在中国,WebSphere MQ同样拥有广泛的用户基础和许许多多的成功案例.它不仅具有跨平台.跨网络的特性,而且以其特有的先进机制保证对消息的"Once and Once only"的传输,

中间件 | mq消息队列解说

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

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

1. 消息生产者.消息者.队列 消息生产者Producer:发送消息到消息队列. 消息消费者Consumer:从消息队列接收消息. Broker:概念来自与Apache ActiveMQ,指MQ的服务端,帮你把消息从发送端传送到接收端. 消息队列Queue:一个先进先出的消息存储区域.消息按照顺序发送接收,一旦消息被消费处理,该消息将从队列中删除. 2.设计Broker主要考虑 1)消息的转储:在更合适的时间点投递,或者通过一系列手段辅助消息最终能送达消费机. 2)规范一种范式和通用的模式,以满

mq消息消费

消息消费以组的的模式开展: 一个消费组内可以包含多个消费者,每一个消费组可订阅多个主题: 消费组之间有集群模式与广播模式两种消费模式:集群模式-主题下的同一条消息只允许被其中一个消费者消费.广播模式-主题下的同一条消息将被集群内的所有消费者消费一次.集群模式下消息队列负载机制遵循一个通用的思想:一个消息队列同一时间只允许被一个消息消费者消费,一个消费者可以消费多个消息队列. 消息服务器与消费者之间的消息传送也有两种方式 推模式,拉模式:拉模式-消费端主动发起啦消息请求.推模式-消息到达服务器后,

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

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

jmockit 中文网 mq消息生产者

RocketMQ是我们常用的消息中间件,在运行单元测试时,我们可能不需要真正发送消息(除非是为了测试发送消息),也不想因为连结不上RocketMQ的Broker,NameServer而影响单元测试运行.   那我们该如何Mock RocketMQ消息生产者呢?  请看例子: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 //RocketMQ消息生产者 Mock  public class RocetMQProduce

如何保证MQ的顺序性?比如Kafka

三.如何保证消息的顺序性 1. rabbitmq 拆分多个queue,每个queue一个consumer,就是多一些queue而已,确实是麻烦点:或者就一个queue但是对应一个consumer,然后这个consumer内部用内存队列做排队,然后分发给底层不同的worker来处理 2. kafka 写入一个partition中的数据一定是有序的,生产者在写的时候 ,可以指定一个key,比如指定订单id作为key,这个订单相关数据一定会被分发到一个partition中去.消费者从partition

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

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

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

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