如何设计一个订单超过5分钟不支付就自动去掉订的设计？都有哪些方案？

实现订单在超过5分钟不支付就自动取消的功能，可以通过多种方案来设计。以下是一些常见的解决方案：

1. 定时任务（Cron Job）： 创建一个定时任务，定期扫描数据库中创建时间超过5分钟且未支付的订单，然后将这些订单状态更新为取消。这可以通过设置Cron作业来完成，这些作业可以每分钟运行一次以检查过期订单。

2. 延迟队列（Delayed Queue）： 当创建一个订单时，将这个订单的ID和过期时间（当前时间加上5分钟）一起放入支持延迟消息的消息队列中（如RabbitMQ的Delayed Message Plugin或者Kafka的延迟队列）。当消息到期时，队列会自动将这个消息发送到消费者那里，消费者接收到后检查订单状态并进行取消操作。

3. 数据库定时器（Database Scheduler）： 如果你使用的数据库支持定时事件（例如MySQL的Event Scheduler），你可以创建一个数据库级别的定时器来定时检查并取消超时订单。

4. 分布式定时任务（Distributed Scheduling Framework）： 使用分布式任务调度框架（如Quartz, Hangfire, or Celery）来调度定时任务，这些任务会定时检查并处理过期的订单。

5. 应用层定时器（Application-Level Timer）： 在应用层面，使用编程语言内置的定时器API（例如Java的ScheduledExecutorService，或者Python的sched模块）来设置一个5分钟后执行的定时任务，任务的责任是检查和取消订单。

6. 过期时间（TTL）： 对于某些NoSQL数据库，比如Redis，你可以为每个订单设置一个TTL（Time to Live），当键过期时触发一个事件，利用这个事件去检查订单是否需要被取消。

7. 前端轮询： 在不涉及后端逻辑复杂性的情况下，也可以通过前端JavaScript轮询，每隔一段时间（例如1分钟）向后端发送一个请求，查询订单支付状态。如果发现订单超时，前端可以提示用户订单已取消，并发送请求到后端完成订单取消操作。

每种方案都有其优缺点，你应该根据你的系统架构、性能需求和维护复杂性来选择最合适的方案。在实施任何方案时，都要确保系统的容错性、一致性和并发问题得到妥善处理，以避免产生未预料的状态或数据不一致问题。

支持延迟队列的消息队列中间件有多个，下面是一些流行的支持延迟队列的消息队列系统：

1. RabbitMQ： RabbitMQ 本身不直接支持延迟队列，但是可以通过安装插件rabbitmq_delayed_message_exchange来实现延迟消息的功能。此外，还可以通过TTL（Time-To-Live）和死信队列组合来模拟延迟队列。

2. Apache Kafka： Kafka 1.0及以后版本支持延迟消息，通过使用KafkaStreams API或者Consumer API的轮询方法结合消息的时间戳属性来实现消息的延迟处理。

3. ActiveMQ： ActiveMQ 支持延迟和计划消息发送。可以在消息属性中设置延迟时间，ActiveMQ会在指定的延迟后将消息发送到目标队列或主题。

4. Amazon SQS（Simple Queue Service）： AWS 的 SQS 提供了原生的延迟队列功能。在创建队列时可以设置队列中所有消息的默认延迟时间，也可以在发送每条消息时单独设置延迟时间。

5. Azure Service Bus： Azure Service Bus 也支持延迟消息。发送者可以设置消息的ScheduledEnqueueTimeUtc属性来指定消息应该在何时被处理。

6. Aliyun RocketMQ： 阿里云的 RocketMQ 也提供了延迟队列的功能，允许发送者指定消息的延迟级别，消息会在一段时间后被消费者消费。

7. Tencent Cloud CMQ（Cloud Message Queue）： 腾讯云的 CMQ 支持消息延时功能，可以在发送消息时设置延时时间，消息会在指定时间后才能被消费。

8. DelayQueue（Java并发包中的类）： 虽然不是一个中间件，但Java的DelayQueue类实现了BlockingQueue接口，可以用来实现内存里的延迟队列。适合在单个JVM内部使用。

上面列出的是一些主流的支持延迟队列的消息中间件，每个中间件都有其特定的实现方式和特点。在选择合适的消息队列时，需要根据项目需求、性能要求、成本和运维等多方面因素进行综合考虑。