互联网大厂为什么不用MQ实现订单到期关闭？

订单相关的处理，是在任何系统中都是非常核心的内容，订单超时关闭，则是整个订单流程中一个分支，用户下完单，该订单已被创建但用户未支付，若超过规定时间内仍未付款，则关闭该订单并回滚库存及优惠券、积分等资源；若用户支付成功，则进入待发货状态，等待商家后续发货。除此之外，像用户下单后自动推送消息、商家发货后系统自动收货、用户签收后系统自动评价等等都是类似的业务场景。比较常见的到期关闭实现方式有如下几种:

• 定时任务

• RabbitMQ死信队列

• RabbitMQ延迟消息插件

• RocketMQ延迟消息

• Redis过期监听

• Redission + Redis

如上就是当前比较主流的订单过期的处理方案，因为所用组件不同，对应具体的实现方案也是不同的。

• 定时任务的优点是容易上手，可靠选择组件较多，缺点是时间不够精准，对DB会造成较大压力。

• RabbitMQ的优点是性能好，但是数据量大的话，会非常消耗内容和CPU

• RocketMQ的优点是选择过期时间阈值多，缺点就是存在延时，过期时间不能自定义。

• redis的过期监听使用较少，不能保证key过期可以立即删除，并有一定的延迟。

• Redission+redis的方法是基于内存的，同样存在较多问题。

具体不同的处理方案的详细技术内容，我们下节再详细讨论。

那么，我们再聊一聊我们本次的内容：

互联网大厂为什么不用MQ实现订单到期关闭？

使用消息队列（MQ）的延迟消息来实现订单的到期关闭功能确实是一种可行的方案，但是他还是有很多局限性的，尤其是在订单量特别大的时候。

消息队列是一种高效处理异步消息的技术手段，广泛应用于系统解耦、流量削峰和异步处理等场景。然而，当涉及到特定的业务逻辑，比如订单到期自动关闭这种定时和精确控制业务流程的场景时，实际上，很多大型互联网企业往往选择其他技术方案而非MQ。

对于大公司来说，确实在订单到期关闭这一场景中用MQ的比较少,他们一般会自己搞一个TOC，全称为:TimeOutCenter，这个也是基于定时任务来实现订单关闭的，其首要满足的也是低延时，高效率。

其实用MQ的延迟消息实现订单的到期关闭并不是一种特别好的方案，尤其是在数据量比较大的情况下。主要存在以下几个问题：

• 资源占用与成本：如果系统中存在大量订单，为每一个订单都创建一个延迟消息可能会导致消息队列中积压大量的消息，这不仅增加了消息队列的资源消耗，也可能导致增加成本，尤其是在使用云服务提供商的消息队列服务时。

• 延迟消息的限制（重要）：首先并不是所有的消息队列服务都支持延迟消息，即使有一些支持，也可能对消息的延迟时间有限制。例如，某些服务可能限制延迟时间的最大值，这可能无法满足所有订单的到期关闭需求。（尤其是一些B类采购订单，关闭时间可能会比较长）

• 可靠性问题（重要）：虽然消息队列一般来说可靠性较高，但是也没办法做到100%不丢消息，所以在极端情况下，会有丢消息的风险。

• 精确性问题：消息的投递延迟是比较常见的一种情况，这可能会导致订单关闭操作不够精确。

• 大量无效消息（重要）：使用MQ实现订单到期关闭就要把订单放到MQ中，但是大部分订单会提前取消或者完成支付，这就会导致很多无效的消息。

• 扩展性问题：随着系统规模的扩大，依赖于消息队列的延迟消息来处理订单到期可能遇到扩展性问题。系统可能需要更复杂的消息队列管理策略和更高效的资源利用策略来应对不断增长的订单量。

这里尤其是可靠性及无效消息的问题比较明显，所以在一个订单量比较大的场景，不是特别建议用MQ实现订单的到期关闭。因为对于大厂来说，可靠性压倒一切。

我们具体来分析下大厂不使用MQ的背后的原因。

1、一致性和准确性要求

订单到期自动关闭功能要求系统能准确判断订单是否到期，并且在指定时间内完成订单状态的更新。使用MQ可能面临消息延迟或者顺序错乱的风险，这样可能会导致订单关闭的行为不够及时或者不一致，从而影响用户体验和业务数据的准确性。

2、业务流程的复杂性

订单状态的管理是一个复杂的业务流程，涉及到库存控制、支付状态同步、退款处理等多个环节。MQ主要解决的是消息传输问题，并不能很好地处理这种复杂逻辑和多状态的管理，特别是在需要确保事务性和数据一致性的场景下。

3、可靠性与监控难度

尽管现代MQ系统提供了高可靠性保障，但在一些非常关键的业务流程中，比如订单处理，任何微小的错误都可能对企业造成巨大损失。使用MQ增加了系统的复杂度，对监控和错误排查提出了更高的要求。如果消息队列出现问题，可能会导致订单状态更新延迟或失败，给业务运营带来问题。

4、定时任务更合适

针对订单到期自动关闭这种场景，使用定时任务更为直接且可靠。定时任务可以保证在特定时间内以预定的频率检查订单状态，并执行关闭操作，这样既保证了处理的及时性，也简化了业务逻辑的实现。现代的分布式任务调度框架，如Quartz、XXL-Job等，提供了丰富的定时策略和良好的可用性保障，能够满足大规模分布式系统的需求。

5、系统设计的权衡

系统设计总是关于权衡的，没有一成不变的最佳实践。对于订单到期自动关闭这样的功能，主要考虑的是准确性、一致性和系统的简洁性。而MQ虽然在处理高并发、系统解耦等方面有显著优势，但在这个特定场景下并不是最理想的选择。大型企业在选择技术方案时，总是围绕业务的核心需求进行思考，综合考虑系统的可维护性、可靠性和性能等多方面因素。因此，在面对如订单到期自动关闭这种高要求的业务逻辑时，更倾向于使用定时任务这种更为直接和可控的方案，而不是选择MQ。

以上为全部内容。

以上为全部内容。

更多技术内容，欢迎扫码关注10W+技术社区。