消费失败如何处理？
|
、介绍 在介绍消息中间件 MQ 之前，我们先来简单的了解一下，为何要引用消息中间件。 例如，在电商平台中，常见的用户下单，会经历以下几个流程。 当用户下单时，创建完订单之后，会调用第三方支付平台，对用户的账户金额进行扣款，如果平台支付扣款成功，会将结果通知到对应的业务系统，接着业务系统会更新订单状态，同时调用仓库接口，进行减库存，通知物流进行发货! 试想一下，从订单状态更新、到扣减库存、通知物流发货都在一个方法内同步完成，假如用户支付成功、订单状态更新也成功，但是在扣减库存或者通知物流发货步骤失败了，那么就会造成一个问题，用户已经支付成功了，只是在仓库扣减库存方面失败，从而导致整个交易失败! 一单失败，老板可以假装看不见，但是如果上千个单子都因此失败，那么因系统造成的业务损失，将是巨大的，老板可能坐不住了! 因此，针对这种业务场景，架构师们引入了异步通信技术方案，从而保证服务的高可用，大体流程如下：订单系统收到支付平台发送的扣款结果之后，会将订单消息发送到 MQ 消息中间件，同时也会更新订单状态。 在另一端，由仓库系统来异步监听订单系统发送的消息，当收到订单消息之后，再操作扣减库存、通知物流公司发货等服务! 在优化后的流程下，即使扣减库存服务失败，也不会影响用户交易。 正如《人月神话》中所说的，软件工程，没有银弹! 当引入了 MQ 消息中间件之后，同样也会带来另一个问题，假如 MQ 消息中间件突然宕机了，导致消息无法发送出去，那仓库系统就无法接受到订单消息，进而也无法发货! 针对这个问题，业界主流的解决办法是采用集群部署，一主多从模式，从而实现服务的高可用，即使一台机器突然宕机了，也依然能保证服务可用，在服务器故障期间，通过运维手段，将服务重新启动，之后服务依然能正常运行! 但是还有另一个问题，假如仓库系统已经收到订单消息了，但是业务处理异常，或者服务器异常，导致当前商品库存并没有扣减，也没有发货! 这个时候又改如何处理呢? 今天我们所要介绍的正是这种场景，假如消息消费失败，我们应该如何处理? 二、解决方案 针对消息消费失败的场景，我们一般会通过如下方式进行处理：
（编辑：甘孜站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
