前两天我们已经介绍了两种Spring Cloud Stream对消息失败的处理策略：
消息中间件基于队列模型实现异步/同步传输数据 作用：可以实现支撑高并发、异步解耦、流量削峰、降低耦合度。
我们还是基于上篇《Spring Boot系列——7步集成RabbitMQ》的demo代码来说。
主启动类RabbitMq01Application：实现ApplicationRunner接口
在微服务架构中，我们常常使用异步化的手段来提升系统的 吞吐量 和 解耦 上下游，而构建异步架构最常用的手段就是使用 消息队列(MQ)，那异步架构怎样才能实现数据一致性呢？本文主要介绍如何使用RocketMQ的事务消息来解决一致性问题。
系统处理方式，因消息中间件不同而异。如果应用没有配置错误处理，那么error将会被传播给binder，binder将error回传给消息中间件。消息中间件可以丢弃消息、requeue（重新排队，从而重新处理）或将失败的消息发送给DLQ(死信队列)。
消息发送的几种模式 4种交换器类型 Direct Exchange: 直连交换器 小结：直连交换器发送消息会根据路由和交换机的绑定关系发送到队列 如果交换器名称为"",将使用默认交换器 默认交换器不会绑定任何队列，mq会直接把route_key当做queue名称去查找 Fanout Exchange: 分发交换器（扇出交换器） 小结: 分发交换器发送消息会分发至所有和其有绑定的队列中，这样消息会被多个消费者
在函数调用的过程中，可能有多种原因导致函数调用失败。不同的错误类型以及调用方式（同步调用、异步调用）都会影响重试策略。实际业务生产中，有很多开发者对这里的策略有疑惑，本文将全面解读 Serverless 异步队列重试策略，并对多种使用场景提供相关的配置建议。 错误类型 在函数调用的过程中，可能有多种原因导致函数调用失败。错误类型分为以下几类： 一、调用错误 调用错误发生在函数实际执行前。以下情形均会产生调用错误： 调用请求错误。例如传入的 Event 数据结构过大、入参不符合要求、函数不存在等。 调用方错
Spring Cloud Stream is a framework for building message-driven microservice applications.
生产者发送6条消息, messageData分别为1, 2, 3, 4, 5, 6
高级消息队列协议（AMQP）是面向消息的中间件的平台中立的线级协议。Spring AMQP项目将核心Spring概念应用于基于AMQP的消息传递
SCS 在 3.x 做了很大的改动，废除了诸如 @StreamListener、@Input、@Output 等类，保留了 Binder、Binding，并提供了批量消费的支持。 本着学新不学旧的原则，本文将介绍 SCS 3.x 相关内容。 由于关于 spring cloud stream kafka 的文档比较充足，本文就此为例介绍 SCS。
12//设置消息发送ack，默认noneconnectionFactory.setPublisherConfirmType(CachingConnectionFactory.ConfirmType.CORRELATED);
两种方式各有优劣，打电话可以立即得到响应，但是你却不能跟多个人同时通话。发送邮件可以同时与多个人收发邮件，但是往往响应会有延迟。
RabbitMQ是流行的开源消息队列系统，使用erlang语言开发，由于其社区活跃度高，维护更新较快，性能稳定，深得很多企业的欢心（当然，也包括我现在所在公司【手动滑稽】）。
过期时间TTL表示可以对消息设置预期的时间，在这个时间内都可以被消费者接收获取；过了时间之后消息将自动被删除。
如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
http://192.168.1.6:15672 默认账号:guest / guest
producer向broker发送消息后，没有收到broker的ack时，rocketmq会自动重试。重试的次数可以设置，默认为2次
Spring-Kafka 提供消费重试的机制。当消息消费失败的时候，Spring-Kafka 会通过消费重试机制，重新投递该消息给 Consumer ，让 Consumer 重新消费消息 。
RabbitMQ的重回队列解决了RabbitMQ由于异常情况导致消息收不到的原因，但是一般在企业不怎么实用重回队列，更多使用的是死信队列的机制，这样来保障消费端能够接收到具体的消息，其实本质上都是为了消息消费者这层的可靠性的保障机制。
今天的 IT 系统正在生成、收集和处理比以往更多的数据。而且，他们正在处理高度复杂的流程（正在自动化）以及跨越典型组织边界的系统和设备之间的集成。同时，预计 IT 系统的开发速度更快、成本更低，同时还具有高可用性、可扩展性和弹性。 为了实现这些目标，开发人员正在采用架构风格和编程范式，例如微服务、事件驱动架构、DevOps 等。正在构建新的工具和框架来帮助开发人员实现这些期望。 开发人员正在结合事件驱动架构 (EDA) 和微服务架构风格来构建具有极强可扩展性、可用、容错、并发且易于开发和维护的系统。 在本文
今天下游同事反馈，有一些以取消的订单库存还原异常了，导致部分商品库存没有还原。查日志发现没有收到还原消息，但是查看发送方是可以确认消息是已经发了的，那么是什么原因导致消费者没有收到，或者收到后没有处理消息呢。最后发现这些消息的状态都是NOT_ONLINE，原因是服务挂了，重启之后便可以重新消费了。让我们看看这个调查过程。
死信队列,英文缩写DLX,Dead Letter Exchange(死信交换机),当消息成为Dead message(消息过期)后,可以被重新发送到另一个交换机,这个交换机就算是DLX,其实死信交换机(队列)和正常交换机(队列)没有什么区别
前几天领导突然宣布几年前停用的电商项目又重新启动了，带着复杂的心情仔细赏阅“儿时”的代码，心中的酸楚只有自己能够体会。
原本想开个Spring Cloud Stream系列文章连载，写Spring Cloud Stream算是个人夙愿了——首先这是个人非常喜欢的组件，它屏蔽了各种MQ的差异，统一了编程模型（可以类比成基于MQ通信圈的”Spring Data”）；其次个人实体书《Spring Cloud 与 Docker 微服务架构实战》没有包含这部分内容也是一大遗憾；更重要的是，这货细节其实挺多，而且上手是稍微有一点曲线的。
死信队列，英文缩写：DLX 。Dead Letter Exchange（死信交换机），当消息成为Dead message后，可以被重新发送到另一个交换机，这个交换机就是DLX。
前面介绍了RabbitMq的几种模式，这篇文章主要介绍死信队列的使用和实际应用场景订单超时怎么和死信队列结合。
nack()与reject()的区别是：reject()不支持批量拒绝，而nack()可以.
当消息在一个队列中变成一个死信之后，它将被重新publish到另一个交换机上，这个交换机我们就叫做死信交换机，死信交换机将死信投递到一个队列上就是死信队列。具体原理如下图：
场景一：物联网系统经常会遇到向终端下发命令，如果命令一段时间没有应答，就需要设置成超时。
昨天试了半天为啥监听不到死信队列的消息，原因是打开方式不对，还有死信队列就一条消息，没意思。
本文是《RabbitMQ精讲系列》中第十七：RabbitMQ消息中间件技术精讲17 高级篇十 死信队列
在消息队列选型时，我们调研了市场上比较常用ActiveMQ，RabbitMQ，RocketMQ，Kafka。
已经被加入到死信队列中了, 为啥是3呢, 应为我之前测试了两次, 这个时候, 如果是写业务的话, 就可以通过消费死信队列的消息, 完成消费失败的, 或者过期的补偿了~
本文给大家介绍一下在 Spring Boot 项目中如何集成消息队列 RabbitMQ，包含对 RibbitMQ 的架构介绍、应用场景、坑点解析以及代码实战。
其实借助RocketMQ-Dashboard就能高效的排查，里面有很多你想象不到的功能
ActiveMQ 支持同步、异步两种发送的模式将消息发送到 Broker，模式的选择对发送延时有巨大的影响。producer 能达到怎样的产出率(产出率=发送数据总量/时间)主要受发送延时的影响，使用异步发送可以显著的提高发送的性能。ActiveMQ 默认使用异步发送通的模式：除非明确指定使用同步发送的方式或者在未使用事务的前提下发送持久化的消息，这两种情况都是同步发送的。 如果没有使用事务且发送的是持久化的消息，每一次发送都是同步发送的且会阻塞 producer 直到 Broker 返回一个确认，表示消息己经被安全的持久化到磁盘。确认机制提供了消息安全的保障，但同时会阻塞客户端带来了很大的延时。很多高性能的应用，允许在失败的情况下有少量的数据丢失。如果你的应用满足这个特点，你可以使用异步发送来提高生产率，即使发送的是持久化的消息。 异步投递可以最大化 produer 端的发送效率。通常在发送消息量比较密集的情况下使用异步发送，它可以很大的提升 producer 性能；不过这也带来了额外的问题，就是需要消耗较多的 Client 端内存同时也会导致 Broker 端性能消耗增加；此外它不能有效的确保消息的发送成功。
最近看到了我在Github上写的rabbitmq-examples陆续被人star了，就想着写个rocketmq-examples。对rabbitmq感兴趣的小伙伴可以看我之前的文章。下面把RocketMQ的各个特性简单介绍一下，这样在用的时候心里也更有把握
前面一文Java整合RabbitMQ实现生产消费（7种通讯方式），本文基于SpringBoot实现RabbitMQ中的死信队列和延迟队列。
今天我们重点聊聊使用 Spring Event 最为关键的几个问题。这是我司线上生产环境实际踩坑后，总结的极为宝贵的经验！
面试训练营的同学，前几天面试小米，都三面了，本来以为稳了，但没想到最后还是挂了。
之前我们已经通过《Spring Cloud Stream消费失败后的处理策略（一）：自动重试》一文介绍了Spring Cloud Stream默认的消息重试功能。本文将介绍RabbitMQ的binder提供的另外一种重试功能：重新入队。
当消息在一个队列中变成一个死信之后，如果配置了死信队列，它将被重新publish到死信交换机，死信交换机将死信投递到一个队列上，这个队列就是死信队列。
消息发送成功返回确认消息，那就能确保消息不丢失。如果发送失败了，mq-client就尝试自动重试，避免网络抖动导致发送丢失。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
