前言:实际项目中经常遇到消息消费失败了,要进行消息的重发.比如支付消息消费失败后,要分不同时间段进行N次的消息重发提醒. 本文模拟场景 当金额少于100时,消息消费成功 当金额大于100,小于200时,会进行3次重发,第一次1秒:第二次2秒:第三次3秒. 当金额大于200时,消息消费失败,会进行5次重发,第一次1秒:第二次2秒:第三次3秒:第四次4秒:第五次5秒.重试五次后,消息自动进入死信队列,在死信队列存活60秒后消失. 代码实例 特别注意代码与配置文件中的注释,各个使用说明都已经详细写在配

在遇到与第三方系统做对接时,MQ无疑是非常好的解决方案(解耦.异步).但是如果引入MQ组件,随之要考虑的问题就变多了,如何保证MQ消息能够正常被业务消费.所以引入MQ消费失败情况下,自动重试功能是非常重要的.这里不过细讲MQ有哪些原因会导致失败. MQ重试,网上有方案一般采用的是,本地消息表+定时任务,不清楚的可以自行了解下. 我这里提供一种另外的思路,供大家参考.方案实现在RabbitMQ(安装延迟队列插件)+.NET CORE 3.1 设计思路为: 内置一个专门做重试的队列,这个队列是一个延

之前使用MQ的时候是通过封装成dll发布Nuget包来使用,消息的发布和消费都耦合在使用的站点和服务里,这样会造成两个问题: 1.增加服务和站点的压力,因为每次消息的消费就意味着接口的调用,这部分的压力都加在了使用的站点和服务的机器上. 2.增加修改的复杂性,如果我们需要加两条消费日志,都需要再发布一个版本重新通过dll引用. 所以我们需要做以下两方面的工作: 1.MQ的接收拆分为Windows服务,通过zokeerper实现主从防止单点故障. 2.MQ的消费这里做成单独的WebApi服务. 这

rabbitMQ是一个在AMQP协议标准基础上完整的,可服用的企业消息系统.他遵循Mozilla Public License开源协议.采用 Erlang 实现的工业级的消息队列(MQ)服务器. RabbitMQ的官方站:http://www.rabbitmq.com/        AMQP(高级消息队列协议) 是一个异步消息传递所使用的应用层协议规范,作为线路层协议,而不是API(例如JMS),AMQP 客户端能够无视消息的来源任意发送和接受信息.AMQP的原始用途只是为金融界提供一个可以彼

rabbitMQ是一个在AMQP协议标准基础上完整的,可服用的企业消息系统.他遵循Mozilla Public License开源协议.采用 Erlang 实现的工业级的消息队列(MQ)服务器. RabbitMQ的官方站:http://www.rabbitmq.com/        AMQP(高级消息队列协议) 是一个异步消息传递所使用的应用层协议规范,作为线路层协议,而不是API(例如JMS),AMQP 客户端能够无视消息的来源任意发送和接受信息.AMQP的原始用途只是为金融界提供一个可以彼

Celery介绍和基本使用 Celery 是一个 基于python开发的分布式异步消息任务队列,通过它可以轻松的实现任务的异步处理, 如果你的业务场景中需要用到异步任务,就可以考虑使用celery, 举几个实例场景中可用的例子: 1)你想对100台机器执行一条批量命令,可能会花很长时间 ,但你不想让你的程序等着结果返回,而是给你返回 一个任务ID,你过一段时间只需要拿着这个任务id就可以拿到任务执行结果, 在任务执行ing进行时,你可以继续做其它的事情.2)你想做一个定时任务,比如每天检测一下你

一:确认种类 RabbitMQ的消息确认有两种.一种是消息发送确认,用来确认生产者将消息发送给交换器,交换器传递给队列的过程中消息是否成功投递.发送确认分为两步,一是确认是否到达交换器,二是确认是否到达队列.第二种是消费接收确认.确认消费者是否成功消费了队列中的消息. 二:消息发送确认 (1)ConfirmCallback 通过实现ConfirmCallBack接口,消息发送到交换器Exchange后触发回调. 使用该功能需要开启确认,spring-boot中配置如下:  spring.rabb

应用场景 之前我们已经通过<Spring Cloud Stream消费失败后的处理策略(一):自动重试>一文介绍了Spring Cloud Stream默认的消息重试功能.本文将介绍RabbitMQ的binder提供的另外一种重试功能:重新入队. 动手试试 准备一个会消费失败的例子,可以直接沿用前文的工程,也可以新建一个,然后创建如下代码的逻辑: @EnableBinding(TestApplication.TestTopic.class) @SpringBootApplication pub

应用场景 前两天我们已经介绍了两种Spring Cloud Stream对消息失败的处理策略: 自动重试:对于一些因环境原因(如:网络抖动等不稳定因素)引发的问题可以起到比较好的作用,提高消息处理的成功率. 自定义错误处理逻辑:如果业务上,消息处理失败之后有明确的降级逻辑可以弥补的,可以采用这种方式,但是2.0.x版本有Bug,2.1.x版本修复. 那么如果代码本身存在逻辑错误,无论重试多少次都不可能成功,也没有具体的降级业务逻辑,之前在深入思考中讨论过,可以通过日志,或者降级逻辑记录的方式把错

之前写了几篇关于Spring Cloud Stream使用中的常见问题,比如: 如何处理消息重复消费 如何消费自己生产的消息 下面几天就集中来详细聊聊,当消息消费失败之后该如何处理的几种方式.不过不论哪种方式,都需要与具体业务结合,解决不同业务场景可能出现的问题. 今天第一节,介绍一下Spring Cloud Stream中默认就已经配置了的一个异常解决方案:重试! 应用场景 依然要明确一点,任何解决方案都要结合具体的业务实现来确定,不要有了锤子看什么问题都是钉子.那么重试可以解决什么问题呢?由

rabbitMQ是一个在AMQP协议标准基础上完整的,可服用的企业消息系统.他遵循Mozilla Public License开源协议.采用 Erlang 实现的工业级的消息队列(MQ)服务器. RabbitMQ的官方站:http://www.rabbitmq.com/        AMQP(高级消息队列协议) 是一个异步消息传递所使用的应用层协议规范,作为线路层协议,而不是API(例如JMS),AMQP 客户端能够无视消息的来源任意发送和接受信息.AMQP的原始用途只是为金融界提供一个可以彼

项目中的MQ: #rabbitmq spring.rabbitmq.host=127.0.0.1 主机 spring.rabbitmq.port=5672 端口 spring.rabbitmq.username=guest 用户名 spring.rabbitmq.password=guest 密码 spring.rabbitmq.virtual-host=/ #\u6D88\u8D39\u8005\u6570\u91CF spring.rabbitmq.listener.simple.concu

MQ(消息队列)作为现代比较流行的技术,在互联网应用平台中作为中间件,主要解决了应用解耦.异步通信.流量削锋.服务总线等问题,为实现高并发.高可用.高伸缩的企业应用提供了条件. 目前市面比较流行的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等,而每种产品又有着独特的着重点,可根据业务需要进行选择. 这里有对主流MQ的优缺点的一些描述与比较. 安装 1.下载Erlang 官网下载,安装完成配置环境变量 2.安装RabbitMq 官网下载,直

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

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

应用场景 上一篇<Spring Cloud Stream消费失败后的处理策略(一):自动重试>介绍了默认就会生效的消息重试功能.对于一些因环境原因.网络抖动等不稳定因素引发的问题可以起到比较好的作用.但是对于诸如代码本身存在的逻辑错误等,无论重试多少次都不可能成功的问题,是无法修复的.对于这样的情况,前文中说了可以利用日志记录消息内容,配合告警来做补救,但是很显然,这样做非常原始,并且太过笨拙,处理复杂度过高.所以,我们需要需求更好的办法,本文将介绍针对该类问题的一种处理方法:自定义错误处理逻

Spring boot集成Rabbit MQ使用初体验 1.rabbit mq基本特性 首先介绍一下rabbitMQ的几个特性 Asynchronous Messaging Supports multiple messaging protocols, message queuing, delivery acknowledgement, flexible routing to queues, multiple exchange type. 异步消息 支持多种消息传递协议,消息排队,传递确认,灵活路

消息手动确认模式的几点说明 监听的方法内部必须使用channel进行消息确认,包括消费成功或消费失败 如果不手动确认,也不抛出异常,消息不会自动重新推送(包括其他消费者),因为对于rabbitmq来说始终没有接收到消息消费是否成功的确认,并且Channel是在消费端有缓存的,没有断开连接 如果rabbitmq断开,连接后会自动重新推送(不管是网络问题还是宕机) 如果消费端应用重启,消息会自动重新推送 如果消费端处理消息的时候宕机,消息会自动推给其他的消费者 如果监听消息的方法抛出异常,消息会按照

Rabbit MQ 学习(一)基础入门 简介 RabbitMQ 简介 为什么选择 RabbitMQ RabbitMQ 的模型架构是什么? AMQP 协议是什么? AMQP 常用命令 概念 生产者和消费者 队列 交换器.路由键.绑定 RabbitMQ 运转流程,消息从生产者发出到消费者这一过程要经历一些什么? Connection 和 Channel 简介 RabbitMQ 简介 在介绍 RabbitMQ 之前实现要介绍一下MQ,MQ 是什么?MQ 全称是 Message Queue,可以理解为消

为什么会需要消息队列(MQ)? 一.消息队列概述消息队列中间件是分布式系统中重要的组件,主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构.目前使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ 二.消息队列应用场景以下介绍消息队列在实际应用中常用的使用场景.异步处理,应用解耦,流量削锋和消息通讯四个场景. 2.1异步处理场景说明:用户注册后,需要发注册邮件和注册短信.传统的做法有两种 1.串行的方