谈消息队列

聊聊消息队列相关的东西，内容局限于我们为什么要用消息队列，消息队列究竟解决了什么问题，消息队列的选型。

为了更容易的理解消息队列，我们首先通过一个开发场景来切入。

不使用消息队列的场景

首先，我们假设A同学负责订单系统的开发，B、C同学负责开发积分系统、仓储系统。我们知道，在一般的购物电商平台上，我们下单完成后，积分系统会给下单的用户增加积分，然后仓储系统会按照下单时填写的信息，发出用户购买的商品。

那问题来了，积分系统、仓储系统如何感知到用户的下单操作?

你可能会说，当然是订单系统在创建完订单之后调用积分系统、仓储系统的接口了K，直接调用接口的方式在目前来看没有什么问题。于是B、C同学就找到A同学，说让他在订单完成后，调用一下他们的接口来通知一下积分系统和仓储系统，来给用户增加积分、发货。A同学想着，就这两个系统，应该还好，OK我给你加了。

但是随着系统的迭代，需要感知订单操作的系统也越来越多，从之前的积分系统、仓储系统2个系统，扩充到了5个。每个系统的负责同学都需要去找A同学，让他人肉的把对应系统的通知接口加上。然后就因为加了这一个接口，又需要把订单重新发布一遍。

这对A同学来说实际上是很痛苦的一件事情，因为A同学有自己的任务、排期，一有新系统就需要去添加通知接口，发布服务，会打乱A的开发计划，增加开发量。同时还需要去梳理在开发期间，新增的代码到底能不能够上线。一旦不能上线，但是又没有检查到，上线就直接炸了以看到，整个的调用链路加长了，更别提，在同步调用中，如果其余的系统发生了错误，或者是调用其他系统的时候出现了网络抖动，核心的下单流程就会被阻塞住，甚至会在下单的界面提示提示用户出错，整个的购物体验又被拉低了一个档次。更何况，在实际的业务中，调用链比这个长的多。

可能有人会说了， 这不就是个同步调用问题嘛?订单系统的核心逻辑，我还是采用同步来处理，但是后续的通知我采用异步的方式，用线程池去处理，这样调用链路不就恢复正常了?

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!