目录:
为什么需要使用消息队列
当流量短时间暴增的时候,假设正常情况下一台服务器的qps(每秒的请求量)是300,突然某个明星出轨的事情上热搜了,qps暴增到3000,导致其中某些稍微脆弱的服务器先跪了,那么剩下的服务器就要承担更多的流量(跪了的服务器的流量被分到了其他剩下的服务器上),服务器承受的压力越来越大,然后就一台一台地跪了。
相信大家都知道,对于存储系统而言(比如MySQL,MongoDB等),正常情况下的写入压力、更新压力是大于查询压力的,而恰好,微博的评论短时间轰炸,后端集群只要有一个环节扛不住就很容易瘫痪了,这时候用户看到的结果就是——操作无响应。
这时给在线服务加一个消息中间件是个不错的选择。
什么是消息中间件?
这里我们做一个抽象,把产生消息的用户比喻成生产者,把服务器集群比喻成消费者(操作系统的概念)。
我们在生产者和消费者之间加了一个中间件——消息队列,用它可以来干嘛呢?
它是来做消息转发的,当请求过来之后,不是直接发给服务器,而是发给消息队列,然后消息队列把消息中转一下再发给服务器。
队列的功能:
- 消息队列可以把消息分类,分别下发,比如点赞、评论和转发,各自走各自的通道。
- 消息队列可以暂存消息。当用户的请求到达消息队列以后,消息队列就给用户发出响应,显示评论成功,即使这时候该评论还没写入数据库,可是用户是不感知的。当流量暴增的时候,生产者生成的消息大于消费者的处理能力,消息就会先被暂存在消息队列里,然后消费者全力去处理,这样就避免了服务器压力过大。消息队列并不是全部存储在内存中,也是可以写入硬盘的,所以能存储很大量的消息。
RabbitMQ使用
应用场景:
以常见的订单系统为例,用户点击【下单】按钮之后的业务逻辑可能包括:扣减库存、生成相应单据、发红包、发短信通知。在业务发展初期这些逻辑可能放在一起同步执行,随着业务的发展订单量增长,需要提升系统服务的性能,这时可以将一些不需要立即生效的操作拆分出来异步执行,比如发放红包、发短信通知等。这种场景下就可以用 MQ ,在下单的主流程(比如扣减库存、生成相应单据)完成之后发送一条消息到 MQ 让主流程快速完结,而由另外的单独线程拉取MQ的消息(或者由 MQ 推送消息),当发现 MQ 中有发红包或发短信之类的消息时,执行相应的业务逻辑。
队列,生产者,消费者
队列是RabbitM