请阐述利用消息队列处理延迟任务的实现方式，具体场景是订单超过30分钟未支付需要自动取消。

回答思路

1. 【回答框架 1】延迟任务本质是事件在满足时间条件后才被消费。基于消息队列的常见实现有四种：RabbitMQ的TTL加死信队列、RocketMQ的延迟消息、Kafka的时间轮或分层时间轮、以及通过Redis过期键通知或Redisson延迟队列。核心思路是把任务和到期时间绑定，到期后投递到消费队列。
2. 【回答框架 2】订单取消场景适合用延迟消息：下单时发送延迟30分钟的取消消息，消息到期后消费端查询订单状态，若仍为未支付则执行取消。需要注意消费端必须做幂等和状态校验，因为消息可能重复投递或业务状态已变化。
3. 【回答框架 3】各方案对比：RabbitMQ TTL+死信队列实现简单但对延迟精度和吞吐有局限，且多个不同延迟时间需配置多个队列；RocketMQ原生延迟消息支持固定等级，如30分钟可映射为延迟等级，使用方便但延迟等级粒度有限；Kafka本身无延迟消息，需要自研时间轮，灵活且吞吐高但复杂度高；Redis方案轻量但可靠性受持久化影响。
4. 【回答框架 4】实际选型要结合延迟精度、消息可靠性、运维成本。对于订单取消，若使用RocketMQ可直接用延迟消息，若用RabbitMQ可采用TTL+死信队列并处理消息堆积和队列膨胀。生产环境通常还需配合定时任务兜底扫描超时未取消的订单，保证最终一致性。
5. 【关键点 1】消息队列实现延迟任务的核心是延迟消息或TTL+死信队列，本质是将到期时间与消息绑定。
6. 【关键点 2】消费端必须记录唯一标识和状态，执行幂等处理，避免重复取消或误取消。
7. 【关键点 3】基于时间轮的方案适合任意延迟时间和海量任务，但需自行实现并考虑持久化。
8. 【关键点 4】订单取消场景需要保证可靠投递和最终一致性，建议用消息队列与兜底定时任务结合。
9. 【易错点 1】不要认为延迟消息一定能严格按时触发，不同实现延迟精度有差异，需接受一定的误差。
10. 【易错点 2】TTL+死信队列方案中，若队列只设置单个TTL会影响吞吐，需合理分区并监控死信队列堆积。
11. 【易错点 3】Redis方案的持久化依赖可能导致消息丢失，生产环境要启用RDB/AOF且考虑主从切换带来的延迟。