weixin_45063957的博客

1、消息丢失问题 消息可靠性问题 针对以上消息可能丢失的三种情况； 生产者弄丢了数据 生产者将数据发送到 RabbitMQ 的时候，可能数据就在半路给搞丢了，因为网络问题啥的，都有可能。 此时可以选择用 RabbitMQ 提供的事务功能，就是生产者发送数据之前开启 RabbitMQ 事务channel.txSelect，然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务channel.txRollback，然后重试发送消息；如果收到了消息，

幂等性：用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。举个最简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额发现多扣钱了，流水记录也变成了两条。在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是再响应客户端的时候也有可能出现网络中断或者异常等等。 重复消费问题：消费者在消费MQ中的消息时，MQ已把消息发送给消费者，

在生产环境中由于一些不明原因，导致rabbitmq重启，在RabbitMQ重启期间生产者消息投递失败，导致消息丢失，需要手动处理和恢复。于是，我们开始思考，如何才能进行RabbitMQ的消息可靠投递呢？特别是在这样比较极端的情况，RabbitMQ集群不可用的时候，无法投递的消息该如何处理呢？ 代码框架: 需要一个回调接口，当消息发出去后交换机没有被接收，就会触发回调接口，然后将消息重发。 # 交换机确认消息 spring.rabbitmq.publisher-confirm-type=c...

延迟队列是死信队列的一种，如果通过过期时间来设置死信，且普通队列没有消费者，就成了延迟队列。 生产者发送消息 ---> 到达普通队列 ---> 等待过期时间 ---> 进入死信队列 ----> 被死信消费者消费。 创建两个队列QA和QB，两者队列TTL分别设置为10S和40S，然后在创建一个交换机X和死信交换机Y，它们的类型都是direct，创建一个死信队列QD。 QC的存活时间由生产者确定 代码实现上面这张图： @Configuration public c..

先从概念解释上搞清楚这个定义，死信，顾名思义就是无法被消费的消息，字面意思可以这样理解，一般来说，producer将消息投递到broker或者直接到queue里了，consumer从queue取出消息进行消费，但某些时候由于特定的原因导致queue中的某些消息无法被消费，这样的消息如果没有后续的处理，就变成了死信，有死信自然就有了死信队列。 应用场景:为了保证订单业务的消息数据不丢失，需要使用到RabbitMQ的死信队列机制，当消息消费发生异常时，将消息投入死信队列中.还有比如说: 用户在商城下单成功并点击

交换机 队列里面的消息只能被消费一次，如果一个消息需要多次消费，就需要用到交换机，通过将交换机绑定到队列上。 用到交换机的模式叫做发布订阅模式。 将交换机绑定多个队列，实现消息的多次消费。 交换机的功能主要有两个，第一个是接收生产者的消息，第二个是推送到绑定的队列。 之前的简单模式，第一个参数交换机类型用的是一个空串表示。 绑定： 实现交换机与队列的一个捆绑关系 发布订阅模式相当于广播模式，一个发布，多个接收。 交换机的几种类型：直接(direct), 主题(topic...

简单的生产者消费者演示 生成者生产消息到消息队列中，消费者再从消息队列中获取消息来进行消费。 public class Producer { public static final String QUEUE_NAME = "HELLO"; public static void main(String[] args) { // 创建一个连接工厂 ConnectionFactory factory = new ConnectionFacto...

消息队列的主要功能：流量削峰、 如果订单系统最多能处理一万次订单，这个处理能力应付正常时段的下单时绰绰有余，正常时段我们下单一秒后就能返回结果。但是在高峰期，如果有两万次下单操作系统是处理不了的，只能限制订单超过一万后不允许用户下单。使用消息队列做缓冲，我们可以取消这个限制，把一秒内下的订单分散成一段时间来处理，这时有些用户可能在下单十几秒后才能收到下单成功的操作，但是比不能下单的体验要好。 应用解耦： 异步处理： 常用的消息队列： kafka：通常是大数据的处理 Ro...