★ FEATURED ARTICLE 做支付订单超时自动关单、电商秒杀预约提醒、延迟重试这类需求时我第一反应就是RabbitMQ的TTL加死信队列组合。这套方案比定时任务轮询更实时比Redis过期回调更可靠可以说是消息中间件场景里最经典的延迟任务解法。很多人知道TTL是消息过期死信是投递失败但把它们组合成延迟队列时要踩的坑、要避的雷网上讲得并不系统。这篇内容我把完整的原理拆解、两种实现方案对比、代码示例和排查经验一次性说透适合正在做延迟任务、消息重试或者刚接触RabbitMQ想深入理解消息流转的开发者。1. 延迟队列应用场景与整体设计思路拆解1.1 为什么需要延迟队列而不直接轮询数据库先聊聊最核心的问题延迟任务为什么不用定时任务扫表很多团队一开始做订单超时关单都是起一个定时任务每隔一分钟扫一次订单表把超过30分钟未支付的订单状态改成已关闭。这个方案在数据量小的时候没问题但一旦订单量上来扫描全表或者大范围索引的性能消耗会急剧上升。更麻烦的是定时任务的间隔决定了延迟精度1分钟扫一次用户的订单可能超时59秒才被关闭体验上差一点没关系但如果是抢购库存释放、优惠券过期回收这种高时效场景分钟级的延迟误差是不可接受的。还有一层问题是业务耦合。定时任务里要写查订单、判断超时、改状态、释放库存这一大堆逻辑每增加一个延迟业务就要在任务代码里加一段分支时间长了这个任务类就变成一个大杂烩。而用消息队列的延迟能力每个业务只需要定义自己的队列、自己的消费者互不干扰扩展成本极低。RabbitMQ的TTL加死信方案解决的就是这一类问题你有N个业务都需要过一段时间再处理并且这个时间可以精确到秒级甚至毫秒级那就可以用一套消息中间件能力统一承接。1.2 为什么选TTL加死信这套组合拳这套组合的核心思路很巧妙消息本身不直接进入消费者要消费的队列而是先进入一个被称为延迟缓冲的队列在这个队列里设置消息过期时间TTL消息到期后因为无人消费触发死信机制被投递到真正的业务消费队列由消费者处理。一句话概括就是利用RabbitMQ消息过期无人消费就进死信的特性把过期当作一种延时触发信号。这样做的优势有几个。第一不需要引入额外的中间件组件。像RocketMQ、Kafka这类消息队列有原生的延迟队列功能或者有些方案会引入Redis、时间轮等额外组件。但RabbitMQ本身自带TTL和死信能力不需要额外部署任何服务。第二消息的延迟时间是精准的。TTL的计时是消息进入队列的时刻开始的毫秒级精确。比如你设置消息TTL为5000毫秒那么从它进入缓冲队列到被投递到死信队列基本就是5秒精度远超定时任务。第三这套机制完全兼容RabbitMQ的消息确认、持久化等特性消息不会因为宕机丢失。只要队列和消息都设置了持久化即使RabbitMQ服务重启消息也会在重启后重新计时并最终进入死信队列被消费。第四延迟时间可控粒度非常细。既可以给单条消息设置TTL也可以给整个队列设置默认TTL甚至两者可以组合使用灵活适配不同类型的延迟需求。2. TTL与死信交换机核心原理解析2.1 消息TTL的两种设置方式TTL全称Time To Live也就是消息的存活时间。RabbitMQ支持两种设置方式理解它们的区别是后面方案选型的关键。第一种是队列级TTL。在声明队列时通过参数x-message-ttl指定单位是毫秒。这个队列里所有消息如果没有在指定时间内被消费都会被判定为过期。队列级TTL的优点是规则统一一个队列里的所有消息使用同一个延迟时间管理简单性能表现也更好。第二种是消息级TTL。生产者发送消息时在消息属性里通过expiration字段指定这条消息的过期时间。每条消息可以设置不同的延迟时间非常灵活满足同一个队列里不同消息需要不同延迟时间的需求。这里有个容易踩坑的细节当队列级TTL和消息级TTL同时存在时较短的那个生效。另外消息级TTL有个重要的坑——如果先进入队列的消息设置了较长的TTL而后进入的消息设置了较短的TTL那么后进入的消息虽然过期时间更早但它必须排在先进入的消息后面等待弹出这就是后面要说的队列头阻塞问题也就是消息无序问题。后面我会专门展开讲这里先记住这个结论。2.2 死信交换机的工作机制死信交换机英文是Dead Letter Exchange简称DLX。一个消息在以下几种情况下会被判定为死信消息被消费者使用basicNack或basicReject拒绝并且requeue参数设置为 false也就是不重新放回队列。消息在队列中存活时间超过了设置的TTL也就是消息过期。队列的消息数量超过了最大长度限制最早的消息会被丢弃或转死信。当消息成为死信后RabbitMQ会把这条消息重新发布到指定的交换机上这个交换机就是死信交换机。死信交换机的本质就是一个普通交换机跟业务交换机没有区别只是它的角色是接收死掉的消息。要让一个队列具备死信能力需要在声明这个队列时指定三个参数x-dead-letter-exchange死信消息发送到的交换机名称。x-dead-letter-routing-key死信消息发送到死信交换机时使用的路由键。如果不设置默认使用原消息的routing key。x-dead-letter-ttl这个参数是源码层面支持、但很少被单独使用的通常配合队列TTL实现业务上一般不需要手动设置。消息进入死信交换机后会按照死信交换机与其他队列的绑定关系路由到对应的死信队列中等待消费者消费。整个流转链路实际上是业务交换机 → 业务队列设置TTL和死信参数 → 死信交换机 → 死信队列 → 消费者。2.3 消息流转的几个关键判断很多人看到死信机制会下意识认为死信就是消息处理失败被扔掉这个理解不全面。死信只是消息被判了死刑但执行死刑的方式可以是投递到另一个队列让其他消费者处理。正是因为这种二次投递特性才让延迟队列有了实现基础。还有一个关键判断是一个队列可以同时是另一个队列的死信目标。比如A队列的死信交换机指向B队列而B队列自己又设置了死信参数指向C队列。这样消息可以形成多级链路的延迟也就是一级到期后进入下一级下一级如果还设置了TTL再到期再进入再下一级。这在一些需要多级延迟确认的场景中会有奇效但也要格外留意链路过长带来的排查困难。3. 延迟队列的两种实现方案与实操选型3.1 方案A单队列消息级TTL实现多级延迟第一种方案的思路是只创建一个延迟缓冲队列所有延迟消息不管延迟多久都投到这个队列里每条消息通过expiration参数单独设置自己的过期时间。举个例子订单支付超时业务和秒杀预约提醒业务共用同一个延迟队列。订单超时消息设置TTL为30分钟预约提醒消息设置TTL为10分钟。两条消息先后进入队列预约提醒消息排在订单超时消息后面。RabbitMQ的消息投递是从队列头部开始的也就是说队列头部的订单超时消息虽然还没到30分钟但它堵在队列头部后面10分钟的预约提醒消息就出不来。只有当头部消息达到30分钟被投递到死信队列后预约提醒消息才轮到队头再从当前时间开始计算剩余TTL。这个队列头阻塞现象直接导致后面短TTL的消息的实际延迟时间被前面长TTL的消息无限拉长。如果有大量长TTL消息堆积短TTL消息的延迟精度会严重恶化。所以这个方案的适用条件是延迟时间类型不多且不存在明显的TTL长短混杂情况。如果你明确知道自己的队列里所有消息延迟时间都差不多这个方案最简单只需要一个缓冲队列加一个死信队列。3.2 方案B多队列队列级TTL实现精准延迟第二种方案是为每个延迟级别单独创建一个缓冲队列。比如需要5秒延迟、30秒延迟、30分钟延迟就分别创建三个延迟缓冲队列每个队列声明时设置不同的x-message-ttl值。生产者在发送消息时根据业务需要的延迟时间将消息发送到对应的缓冲队列。因为每个队列里的所有消息TTL相同且队列之间互不影响所以不存在队列头阻塞问题。消息到期后被投递到同一个死信交换机或者各自的死信队列中消费者从死信队列拉取消息处理。这个方案的优点是延迟精准、逻辑清晰、排查容易。缺点是如果延迟级别很多需要创建的队列就会成倍增加。你在设计延迟级别时要克制一般业务场景3到5个延迟级别足够覆盖大多数需求比如延迟5秒用于支付结果补偿查询延迟30秒用于消息推送重试延迟30分钟用于订单自动关单。这里我直接给出选型建议延迟时间种类小于等于3个、量级差异明显的场景用方案B延迟时间类型很少且每条消息延迟时间完全随机、对精度要求不高的场景可以退而求其次选方案A。绝大多数生产环境我推荐方案B管理成本虽然高一点但行为可预测出问题好排查。3.3 两种方案对比速查对比维度方案A单队列消息级TTL方案B多队列队列级TTL队列数量延迟队列和死信队列各1个每个延迟级别各2个队列延迟精度受队头阻塞影响高并发下精度差精度高各队列独立计时延迟灵活性每条消息可不同延迟时间只能使用预先定义好的延迟级别实现复杂度低中生产推荐度不推荐用于高低混杂场景推荐用于生产环境4. 完整代码实现与参数配置细节4.1 延迟队列声明的核心参数我用Spring Boot加RabbitMQ的典型写法来演示。无论用哪种语言核心逻辑都一样就是设置好交换机和队列的参数。先定义三个关键组件业务交换机、延迟缓冲队列、死信交换机与死信队列。延迟缓冲队列是整个机制的心脏它要同时配置TTL参数和死信参数。Configuration public class RabbitDelayConfig { public static final String DELAY_EXCHANGE delay.exchange; public static final String DELAY_QUEUE_5S delay.queue.5s; public static final String DELAY_QUEUE_30S delay.queue.30s; public static final String DEAD_EXCHANGE dead.exchange; public static final String DEAD_QUEUE dead.queue; public static final String DEAD_ROUTING_KEY dead.routing.key; Bean public DirectExchange delayExchange() { return new DirectExchange(DELAY_EXCHANGE); } Bean public DirectExchange deadExchange() { return new DirectExchange(DEAD_EXCHANGE); } Bean public Queue delayQueue5s() { MapString, Object args new HashMap(); // 队列级TTL单位毫秒5秒 args.put(x-message-ttl, 5000); // 死信交换机 args.put(x-dead-letter-exchange, DEAD_EXCHANGE); // 死信路由键 args.put(x-dead-letter-routing-key, DEAD_ROUTING_KEY); return new Queue(DELAY_QUEUE_5S, true, false, false, args); } Bean public Queue delayQueue30s() { MapString, Object args new HashMap(); args.put(x-message-ttl, 30000); args.put(x-dead-letter-exchange, DEAD_EXCHANGE); args.put(x-dead-letter-routing-key, DEAD_ROUTING_KEY); return new Queue(DELAY_QUEUE_30S, true, false, false, args); } Bean public Queue deadQueue() { return new Queue(DEAD_QUEUE, true); } Bean public Binding delayBinding5s() { return BindingBuilder.bind(delayQueue5s()) .to(delayExchange()).with(delay.5s); } Bean public Binding delayBinding30s() { return BindingBuilder.bind(delayQueue30s()) .to(delayExchange()).with(delay.30s); } Bean public Binding deadBinding() { return BindingBuilder.bind(deadQueue()) .to(deadExchange()).with(DEAD_ROUTING_KEY); } }这段配置里有个细节必须注意new Queue(DELAY_QUEUE_5S, true, false, false, args)的第二个参数是durable持久化第三个是exclusive排他第四个是autoDelete自动删除。生产环境持久化必须为true否则RabbitMQ重启队列就没了排他和自动删除都建议false防止队列被意外删除。args里的x-message-ttl用的是String还是Integer在Spring Boot里都行但建议直接传整型毫秒数避免类型转换的潜在问题。x-dead-letter-exchange指向的是一个普通的DirectExchange并没有特殊的死信交换机类型。RabbitMQ不会区分这是普通交换机还是这是死信交换机任何交换机都可以作为死信交换机。这个认知误区要纠正很多初学者以为死信交换机命名要带dead字样其实命名只是约定核心是参数配置正确。4.2 生产者发送消息的关键代码消息发送到延迟缓冲队列时路由键必须和绑定关系一致。比如要向5秒延迟队列发消息路由键就是delay.5s。Service public class DelayMessageSender { Autowired private RabbitTemplate rabbitTemplate; public void sendDelay5s(String message) { rabbitTemplate.convertAndSend( RabbitDelayConfig.DELAY_EXCHANGE, delay.5s, message, msg - { // 这里还可以继续设置消息级TTL覆盖队列默认TTL msg.getMessageProperties().setExpiration(5000); msg.getMessageProperties().setDeliveryMode(MessageDeliveryMode.PERSISTENT); return msg; }); } }这段代码里的setExpiration(5000)是消息级TTL。如果同时设置队列级TTL为5秒又设置消息级TTL为5秒两者相同没问题。但如果队列级是5秒消息级是10秒消息会在5秒时到期因为较短时间生效。要注意的是setExpiration接收的是字符串不是整型写错了类型会报错。setDeliveryMode(MessageDeliveryMode.PERSISTENT)设置消息持久化。如果你已经在队列上开启了持久化但消息本身没有持久化服务重启后消息依然会丢失。持久化要两头都设置队列持久化加消息持久化才能真正做到消息不丢失。这里还有一个Spring Boot特有的坑如果convertAndSend方法中只传message对象Spring会使用默认的消息转换器把对象序列化为字节数组。如果你传的是一个自定义对象务必要让对象实现Serializable接口否则生产消息时会抛出MessageConversionException。我一直建议简单场景直接传JSON字符串省去序列化框架配置的麻烦。4.3 消费者处理死信消息的要点消费者监听的是死信队列业务处理逻辑在这里实现。Component public class DeadQueueConsumer { RabbitListener(queues RabbitDelayConfig.DEAD_QUEUE) public void handleDeadMessage(Message message, Channel channel) throws Exception { long deliveryTag message.getMessageProperties().getDeliveryTag(); try { String content new String(message.getBody(), StandardCharsets.UTF_8); // 业务处理比如更新订单状态 System.out.println(延迟消息到期开始处理业务: content); // 手动确认 channel.basicAck(deliveryTag, false); } catch (Exception e) { // 处理失败拒绝消息并重新入队或死信 channel.basicNack(deliveryTag, false, false); } } }消费者这里必须打开手动确认模式。在Spring Boot中需要配置spring.rabbitmq.listener.simple.acknowledge-modemanual否则默认是自动确认消息一接收到就确认了如果业务处理失败消息就丢了。手动确认的三种处理方式要分清basicAck(deliveryTag, false)确认一条消息处理成功。basicNack(deliveryTag, false, true)拒绝消息并重新放回原队列。basicNack(deliveryTag, false, false)拒绝消息且不重新放回原队列。如果死信队列本身还设置了死信参数消息会进入下一级死信如果没有消息会被丢弃。在处理延迟任务失败时我建议用basicNack加requeuefalse配合死信队列自身的TTL参数做成延迟重试的链路而不是requeuetrue无限重试后者会在消费失败时导致消息在队列头反复出入造成死循环严重时拖垮整个队列。5. 生产环境配置与经验性避坑指南5.1 队列长度与过期消息的相互影响先理清一个概念队列长度限制和TTL过期是两个独立的机制但两者会相互影响。有些团队给业务队列设置了x-max-length比如最多存10万条消息新消息继续进入时最早的消息会被移除或者转为死信。如果这个队列同时设置了TTL那么队列头的过期消息在TTL到期前会一直占着位置可能挤掉后面的新消息。举个例子5秒延迟队列里进入了10万条消息这些消息都是5秒后到期但因为队列长度限制是5万条第5万零1条消息进入时第1条消息还没到5秒会被长度限制直接剔除。如果这条消息剔除时没有死信交换机它就直接消失了。我在实际项目中就遇到过这个情况用了x-max-length限制延迟队列长度结果大量延迟消息不明原因丢失排查了很久才发现是长度溢出触发丢弃逻辑。处理方式有两种一是延迟队列尽量不要设置长度限制因为延迟队列本身就是临时缓冲消息不会久留长度限制没有意义二是如果一定要限制确保延迟队列也设置了死信参数这样溢出的消息至少不会静默丢失而是进入死信链路方便排查。5.2 消息持久化与高可用配置的配合延迟消息的持久化是生产环境不可妥协的要求。RabbitMQ的持久化有三个维度交换机持久化durable、队列持久化durable、消息持久化deliveryMode2。三个维度缺一个都不能保证消息在服务重启后不丢失。在延迟队列场景中还有一点容易被忽略当消息因为TTL到期被投递到死信队列时这个过程本身也是通过交换机重新投递的如果死信交换机没有持久化投递动作可能失败。所以延迟队列、死信队列、业务交换机、死信交换机这四样全部都要设置持久化。另外如果你的RabbitMQ是集群部署建议开启镜像队列或仲裁队列。延迟队列虽然在正常情况下消息停留时间短但只要有积压消息就会在缓冲队列里长时间保存如果这个时间段内所在节点宕机没有镜像的话消息就直接丢了。5.3 消费能力与堆积监控延迟队列的消息到期后会瞬间涌入死信队列如果消费者处理速度跟不上死信队列会快速堆积。比如你设置了30分钟的延迟生产者在某个瞬间集中发送了大量消息30分钟后这些消息同时到期全部涌入死信队列消费者如果在那一刻只有一个实例且处理缓慢队列堆积就会飙升。监控上我建议盯三个指标死信队列的消息积压数量、消费者的未确认消息数、RabbitMQ连接数。Spring Boot的Actuator可以暴露RabbitMQ的指标也可以通过RabbitMQ管理界面直接查看队列的Ready消息数和Unacked消息数。如果Ready数持续上涨说明消费者消费不过来如果Unacked数很高说明消费者在处理中卡住了要检查业务逻辑是否在长时间执行阻塞。这里还延伸到消费者的横向扩展死信队列的消费者理论上可以部署多个实例分担消费压力。注意多个消费者监听同一个队列时消息是轮询分发的不存在单消费者抢锁问题所以放心加实例就行。但如果你的业务逻辑涉及分布式锁、数据库状态更新还是要注意并发重复处理的风险消息队列不保证只消费一次。5.4 设计延迟级别时的时间单位选择创建延迟队列时x-message-ttl的单位是毫秒。这个细节经常有人搞错把秒当毫秒填结果队列里消息秒级别全部过期进入死信队列业务还没处理就被提前消费了。我建议在配置类里用常量定义好延迟级别一眼看明白语义避免魔法数字。public class DelayLevel { public static final int SECONDS_5 5_000; public static final int SECONDS_30 30_000; public static final int MINUTES_30 30 * 60 * 1000; public static final int HOURS_2 2 * 60 * 60 * 1000; }另外还要注意过长的TTL配合队列头阻塞可能导致消息实际延迟时间远大于设置时间。有一种机制叫延迟消息过期重发布RabbitMQ官方不直接支持但有些团队会在消息中将过期时间放在header里先给一个很短的TTL比如1秒到期进入死信队列后消费者检查真正延迟时间是否已到如果没到再用剩余时间重新发送到延迟队列。这种方案能规避队列头阻塞实现非常精细的任意时间精度延迟但复杂度上升明显。我的建议是除非业务真的需要秒级任意精度延迟否则不要引入这种机制多级队列已经能覆盖绝大多数场景。6. 常见问题与排查技巧实录6.1 消息迟迟不进入死信队列这是大家遇到最多的问题延迟消息设置了TTL生产者也发送了RabbitMQ管理界面能看到消息在延迟队列里但到了设置的时间就是不进入死信队列。排查思路按顺序走第一步确认延迟队列是否设置了死信参数。在管理界面的Queue标签页点击队列名称查看Arguments是否符合预期。如果没有x-dead-letter-exchange参数消息过期后会被直接丢弃根本不会进入死信队列。这是最常见的配置遗漏。第二步确认死信路由键是否匹配。如果设置了死信交换机但死信交换机与死信队列的绑定关系里的路由键和x-dead-letter-routing-key不一致消息进不了死信队列。第三步确认消息是否真的过期了。管理界面上看消息的TTL设置或者在发送消息时打印日志确认expiration字段的值。第四步确认是否存在队列头阻塞。队列头有一条未过期的长TTL消息后面的短TTL消息即使已过期也不可能提前弹出。此时管理界面上看到的队列头部消息的老化时间就是阻塞原因。6.2 消息进死信队列但积压不消费死信队列有消息堆积消费者也启动了就是迟迟不消费。此时先看消费者的监听队列是否正确很多人配置了死信交换机、死信队列结果RabbitListener注解监听的是延迟队列而不是死信队列消息永远在原队列打转消费端毫无感知。再看消费者的acknowledge-mode是否设置为manual。如果没有手动确认消费者会一直停留在待确认状态不会拉取新消息。你可以看管理界面的Unacked数量如果Unacked曲线一直高并且不下降就是消费者处理线程阻塞了需要用jstack查看线程堆栈常见原因是消费逻辑里调用了外部接口但未设置超时时间导致线程挂死。还有一种情况比较坑消费者和RabbitMQ之间网络波动连接断开后Spring Boot的监听容器会自动重连但重连前RabbitMQ侧会保持连接一段时间不释放。如果消费端频繁断连消息会一直处于Unacked状态直到连接超时后才重新变为Ready。排查时看消费端日志有无连接重置异常。6.3 消息重复消费延迟队列消息到期进入死信队列消费者处理完业务后如果手动确认失败或者网络出现问题RabbitMQ会重新投递消息业务就重复执行了。延迟任务场景下重复消费是非常现实的威胁。比如订单超时关单这条消息如果被消费两次而业务逻辑是先检查订单状态再关闭第二次消费时订单已经是关闭状态直接返回就行这是天然的幂等设计。但如果你在消费者里做的是扣减库存、发送短信就必须在消费者侧引入幂等机制常见做法是使用Redis的setnx记录消息ID或者使用数据库唯一键约束。消息队列不提供恰好一次的消费语义这是架构层面上需要接受的事实。6.4 配置了死信但消息被子级队列二次延迟这是多级死信链路的坑。假设A延迟队列的死信交换机指向B队列而B队列本身也设置了TTL和死信参数。那么A队列消息到期后进入B队列B队列的TTL又启动计时消息又被延迟了一轮。如果你本意只是A到期后由B消费却忽略了B自身的TTL参数就会出现消息在B队列里又等待一段时间才被处理整体延迟时间翻倍。排查技巧是打开管理界面逐级看队列的Arguments参数尤其注意B队列是否也设置了x-message-ttl。我见过一个项目开发人员为了复用配置把同一套延迟参数模板用在了所有队列上导致消息在每一级都被延迟了5秒表面看链路是通的实际延迟全不符合预期。7. 延迟任务代码结构优化的几个建议如果看完上面的内容你已经在规划把自己的延迟任务迁移到这套方案上我再分享几个项目落地过程中的结构设计心得。第一把延迟级别统一收敛到一个枚举类里。不要在生产代码里写setExpiration(5000)这种魔法数字。枚举类统一管理延迟级别与路由键的映射关系新业务接入时只需要选延迟级别不需要理解队列细节。第二发送方封装一个延迟消息服务类所有的延迟消息发送统一走这个服务便于在入口做消息格式统一、消息ID注入、日志打印。这在后续排查消息全链路时价值极大否则每个业务自己调RabbitTemplate消息格式五花八门出了问题根本没法定位。第三消费者侧做好消息体结构设计。一条延迟消息应该至少包含业务类型、业务唯一标识、实际的业务载荷JSON。消费者拿到消息后先判断业务类型再分发到对应的处理方法避免为每个延迟业务单独创建死信队列减少队列数量。第四对延迟队列的关键参数和链路流程写一份维护文档。这个方案看着简单但在团队协作中很容易因为某个人调整了参数导致链路断掉。我在项目里就是吃了这个亏后来把每个队列的参数、连接关系、监控看板画出来之后排查效率提升了不止一倍。第五做好延迟队列的监控告警。死信队列积压数量、消费延迟时间、消息丢失数这三类指标建议接入监控平台设置阈值告警。延迟队列最怕的不是慢而是静默失效——消息压根没进入死信链路业务无感知用户却一直等不到结果。8. 一些实际经验与最后的提醒这套TTL加死信的延迟队列方案我在多个项目里落地过整体稳定性和效果都比定时任务扫表好得多。但要说最值得注意的经验一个是队列级TTL和消息级TTL的选择一定要结合消息特征另一个是延迟队列不要设置长度上限再一个就是手动确认和幂等处理必须一起到位缺一个都会出生产事故。实际操作中我还有个习惯每次配置新的延迟队列后会先用RabbitMQ管理界面的Publish Message功能手动发一条测试消息验证完整的消息流转链路。这样做的成本极低但能帮你提前发现路由键错误、绑定关系缺失这类低级问题。部署代码前花三分钟验证省去后面排查事故的几小时。如果你要接入新业务最稳妥的做法是先用最少的延迟级别跑通一条链路确认消费者手动确认和消息不丢失都符合预期后再逐步扩延迟级别和业务场景。延迟队列本身不复杂复杂的是链路组合和参数细节把基础链路跑通、理解每个参数的含义后面不管加多少业务都是水到渠成的事。
阅读完成 · 觉得有帮助？
