正文

请到「今天看啥」查看全文

2）调远程系统下订单成本较高，且因为网络等因素，不稳定，攒一批一起发送。

3）任务处理类的系统，先把用户发起的任务请求接收过来存到消息队列中，然后后端开启多个应用程序从队列中取任务进行处理。

三、使用消息队列有什么好处？

3.1、提高系统响应速度

使用了消息队列，生产者一方，把消息往队列里一扔，就可以立马返回，响应用户了。无需等待处理结果。

处理结果可以让用户稍后自己来取，如医院取化验单。也可以让生产者订阅（如：留下手机号码或让生产者实现listener接口、加入监听队列），有结果了通知。获得约定将结果放在某处，无需通知。

3.2、提高系统稳定性

考虑电商系统下订单，发送数据给生产系统的情况。电商系统和生产系统之间的网络有可能掉线，生产系统可能会因维护等原因暂停服务。如果不使用消息队列，电商系统数据发布出去，顾客无法下单，影响业务开展。两个系统间不应该如此紧密耦合。应该通过消息队列解耦。同时让系统更健壮、稳定。

异步化、解耦、消除峰值

以上三点其实可以用一个例子来解释——设想有一款MMO游戏，没有人肉写的缓存层或者ORM，所有逻辑节点都直连MySQL，逻辑节点内除了要关注场景、战斗、交互等复杂逻辑以外，还要有个拼SQL语句的模块，想想简直是蛋疼。先考虑一下这样设计的弊端所在：

1. 逻辑节点与Db的交互会有大量IO，即使把与Db交互的模块耦合在逻辑节点内，其实现对你来说是黑盒，如果内部是同步实现的，那就直接卡你游戏主逻辑，就因为一次存盘操作，玩家们都掉线了，服务器也可以关掉了。

2. 那么我们改进一下，针对1的情况，可以把这个模块做到一个线程里挂在逻辑节点上。这样其实逻辑节点跟这个Db前端模块的交互就会基于一个比较原始的消息队列。但是这样还有一个坏处，那就是这两种任务一种是计算密集的（玩家的逻辑处理）、一种是IO密集的（只负责写入读取MySQL），搞到一个节点中，扩展起来会非常麻烦，而且耦合度太高。比如说现在发现场景放单节点上有瓶颈，要按场景分节点，那么这种挂在上面的数据模块怎么跟其他场景的交互呢？

3. 峰值的问题。在分布式系统中，一次分布式事务关联的是多个节点，其中每一个节点出现问题都会成为整个事务处理流程中的瓶颈。如果逻辑节点与数据库之间没有一个起到缓冲作用的节点，那就是每次操作都要访问数据库，对于MMO来说，一个玩家上线load几百K数据，一个服10万个玩家上线已经足够搞垮一个mysql节点了。如果直接搞垮还是比较好的结果，至少是前面的玩家确实登录上去了并且可以正常游戏，后面的玩家登录不上。但是很可惜，十年前开始流行的C10K说法就是在讲：并发量上来之后，会造成chain reaction，大量的并发不会直接挂掉你的mysql节点，但是会拖慢速度，降低吞吐量，一个玩家的请求由于处理时间太长，导致玩家放弃重试，但是对于后端来说，对该玩家之前的处理过程消耗的资源就全部浪费了，陷入恶性循环。

请到「今天看啥」查看全文