初识消息队列

168

消息中间件的使用已经越来越广泛，基本上具有一定规模的系统都会用到它，在大数据领域也是个必需品，但为什么使用它呢？一个技术的广泛使用必然有它的道理。

—

背景与问题

以前一些传统的系统，基本上都是“用户——系统——数据库”一条线，拿下单做例子，用户下单，系统接受并处理请求，把数据存到数据库。

这样的好处就是简单，但随着需求越来越多，用户量越来越大，系统需要承载的压力就越大；如果需要扩展系统，修改代码，牵一发动全身，麻烦滴很。

消息队列可以解决这些问题，它是一个存放消息的队列，生产者往队列推数，消费者从队列取数。它的的优点：解耦、异步、削峰。

—

解耦

一个系统一般都有很多个模块，但业务发展起来，系统的体量就跟着变大，就需要多做几个模块，然而每拓展一个模块就要多各种调用。

以一个交易系统为例，当完成一次交易，系统需要通知推荐系统、广告系统等。当多出一个模块，系统就要增加一个调用，从而需要修改代码。

要是你觉得改改代码不麻烦，可是改完，后面有一个模块出问题了咋办，一点一点排查，改错地方了还影响到了其他模块。

如果增加消息中间件，各个模块只需要完成各自的工作，然后将消息发到消息队列，由其他模块去取或者消息队列推送，就可以解决耦合的问题了。至于怎么获得消息，这个后面会讲。

—

异步

传统系统的话，一条路走到底，比如购买商品，完了扣除优惠券，再给你积点分。这每个流程可能就花一点时间，但合起来就很久了。

加上消息队列，我直接完成我的工作，再给队列，队列再通知其他模块，这不仅省事儿，还减少了不必要的时间浪费。

—

削峰

还是以传统系统为例，当并发量大的时候直接怼到数据库，数据库承受的压力得多大呀这是。

欸，那就加个消息队列，把请求扔到消息队列，慢慢处理。因为是队列嘛，先来后到，所以可能比较慢，但至少服务器压力得到了缓解。只要不崩，一切好说，慢就慢呗（划掉）

—

缺点

技术嘛，总是有好有坏，刚才说了它的优点，现在简单唠唠它的缺点。

首先，降低了系统的可用性，好好的一个系统，加一个中间件，如果它挂了，后面不得凉凉。

为了防止它挂掉或者挂掉了修复它，是不是得维护？是不是增加了运维成本？

不仅如此，还要考虑数据一致性问题，以及重复消费的问题，还要保证消息的可靠传输。要考虑的东西有多少，系统的复杂性就有多高。

—

消费模式

消息队列一般有两种消费模式，一种是点对点模式，一种是发布订阅模式。

点对点是一种一对一的模式，一般消息只由一个消费者消费，导致消息没法复用；

发布订阅模式是一种常见的模式。消费者订阅，当有消息来的时候通知消费者。这种模式也分为两种情况，一种是由消息队列推送，类似公众号订阅一样，只要消费者订阅了，消息一来就推给订阅了的消费者。

但是这种方法也有缺点，因为消费者的处理速度不一样，有快有慢，容易出现问题。比如消息队列推送的速度为100M/s，消费者A处理速度为10M/s，消费者B处理速度为500M/s，这时候A就崩了，对于B来说，又造成资源浪费。

所以由消费者主动拉取的方式诞生了，由消费者主动拉数据，解决了上面的问题，但技术有优点的同时，一般都存在缺点。由于消费者要主动拉取，需要维护一个长轮洵去询问队列，但当遇到长时间没有消息的情况，就造成了资源浪费。

简单介绍了一下消息队列以及它的优缺点，并且大概讲了它的消费模式，之后有时间我会写写Kafka的一些东西，如果喜欢，点赞关注不迷路！

文章转载自大数据的奇妙冒险，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。