lovoo的博客

RabbitMQ死信队列（Dead-Letter Exchange，简称DLX）是一种特殊类型的交换机，用于处理在队列中无法被消费的消息。当消息无法被消费时，它会被转发到死信队列中，以便进一步处理。消息无法被消费者处理：例如，如果消费者崩溃或消息的格式不正确，则无法处理消息。此时，消息将被发送到死信队列进行进一步处理。消息的优先级较低：如果消息的优先级较低，则可能无法在队列中得到及时处理。在这种情况下，消息也会被发送到死信队列中，以确保它最终被处理。

exchange根据指定的路由规则将消息路由到相应的队列中，这个规则可以是基于消息内容的，也可以是基于其他属性的。提供基本的最终一致性实现：RabbitMQ可以帮助实现面向服务的架构（SOA），通过消息队列来通信，从而实现不同服务之间的解耦，并确保最终一致性。实现应用程序之间的异步和解耦：通过使用消息队列，应用程序可以通过读写消息来实现通信，无需直接调用彼此，从而减少了对彼此的直接依赖。实现RPC调用：通过使用消息队列，可以在分布式系统中实现RPC调用，从而实现不同服务之间的通信。

RabbitListener 标注在方法上，直接监听指定的队列，此时接收的参数需要与发送市类型一致；而 @RabbitHandler 标注在类上，表示当有收到消息的时候，就交给该类中的方法处理。另外，在实际开发过程中，您可能需要参考具体的编程语言和消息队列客户端库的文档，以了解如何正确地使用 basicNack 和 basicReject 方法。需要注意的是，虽然 RabbitMQ 通过上述方式来保证消息的可靠性，但在一些极端情况下，如网络故障、硬件故障等，仍然可能发生消息丢失的情况。

Dead Letter Exchange其实就是一种普通的exchange，和创建其他exchange没有两样。只是在某一个设置Dead Letter Exchange的队列中有消息过期了，会自动触发消息的转发，发送到Dead Letter Exchange中去。一个消息被Consumer拒收了，并且reject方法的参数里requeue是false。也就是说不会被再次放在队列里，被其他消费者使用。消息的TTL到了，消息过期了。队列的长度限制满了。排在前面的消息会被丢弃或者扔到死信路由上。

订单系统需要通知库存系统，如果想要解锁库存，可以通过stock.locked路由键发送一个消息给交换机stock-event-exchange,消息内容包括哪个订单、哪些商品、多少库存。订单取消和订单回滚。下订单成功，订单过期没有支付被系统自动取消、被用户手动取消。下订单成功，库存锁定成功，接下来的业务调用失败，导致订单回滚；之前锁定的库存就要自动解锁。库存锁定，sql执行锁定锁定。

例如，可以将用户订阅的消息发送到一个延时队列中，并设置一个延迟时间(例如1小时),然后在延迟时间到达后，将消息从队列中取出并推送给用户。例如，可以将需要定期执行的任务发送到一个延时队列中，并设置一个延迟时间(例如每天),然后在延迟时间到达后，将任务从队列中取出并执行。然后，我们发送了一条消息到这个队列中，接着模拟了一个消费失败的场景，将消息转发到DLX和DLQ中。动态路由：您可以使用延时队列来实现动态路由的功能，将消息发送到延时队列中，并设置一定的路由规则，以实现消息在特定时间后被路由到不同的目标队列中。

/交换机//路由//消息队列 }@Service@Slf4j@Resourcelog.info("发送消息。。。。。。");} }

前言在目前大型的商城项目中，订单的提交涉及到的功能比较多，如，商品查询、库存锁定、积分加减、价格比对、促销优惠等等功能，这些功能分布在不同的模块，需要通过远程调用实现，这时就涉及实现数据的一致性问题。如果哪一个模块失效或崩溃，部份模块成功提交了数据，但崩溃模块没有更新相应的数据，就会导致数据的不一致。由于订单模块是并发量最大的模块，像淘宝双十一的时候，每秒都可能几百万个订单，如果采用seata这种AC的模式，会将订单提交变成串行，严重导致数据的堵塞。在此，我们可以采取柔性策略，尽量保证数据的有效性，然后通

前言在并发量大的商城项目中，如果同时有一百万的用户同时下单，那么我们如何保证数据的一致性的同时，又要保证数据库服务器不崩溃？目前最好的方法是采用rabbitMQ进行处理，把所有的订单先暂存在rabbitMQ的消息队列中，然后监听rabbitMQ，获取对应的消息，然后根据数据库的处理能力将消息进行分批次处理，完美解决了并发问题。一、概述大多应用中，可通过消息服务中间件来提升系统异步通信、扩展解耦能力消息服务中两个重要概念： 消息代理（message broker）和目的地（destination）