一、什么是消息队列?
消息队列,一般我们会简称它为MQ(Message Queue),它本质就是一个消息转发器,一个不赚差价的“中间商”。
先说一下队列,应该都很熟悉,队列 = 一种按顺序排好队的数据结构。
- 把数据放到消息队列叫做“生产者”
- 从消息队列里边取数据叫做“消费者”
二、为什么要用消息队列?
主要解决了三个问题
- 异步
- 解耦
- 削峰
1.首先异步,在我们平常接口和方法调用的时候,需要一个一个按顺序调用,那对于一个重要的业务功能来说,可能调用的链路特别长...
链路长了就慢了...
其实有些流程我们可以同时执行,我去执行保存支付明细的同时也可以执行保存会员卡积分信息,然后加个会员等级,加个业绩什么的,是吧。
正常的流程我们似乎没办法同时执行,怎么办?异步
收银后把结果推送到消息队列中,下游其它服务订阅这个消息,收到消息执行加积分,加等级,加业绩...
2.解耦,像下图中收银订单流程,业绩、库存、欠款...这么多业务,每增加一个都需要改动代码,而且其中只要有一个出现报错,其它流程就无法正常流转,那使用体验是不是很差?
而且排查问题的时候,一个方法调用一个方法,都得找到自闭好么。
用了消息队列,耦合问题迎刃而解。
3.削峰,我们都知道,服务器有容纳请求的一个上限,redis、mysql,各自的容忍度不同,那如果全部一起接收,那肯定会把服务器打挂。
redis能来十万,mysql两千就GG...
咋办?把请求内容丢消息队列中呗,每次消费1000条,慢慢的保存到数据库中,这样,系统就能平稳的抗住了短时间的高峰请求!
三、用消息队列会产生什么问题?
消息队列是用爽了,那问题也随之而来,我们都知道,技术是把双刃剑,解决问题的同时也会产生很多问题,那我们攻城狮这个岗位就是解决问题的。所以,遇到问题不要方,一个个解决。
可能会出现哪些问题呢?
- 消息丢失
- 重复消费
- 消息积压
1.消息丢失有很多情况:
怎么解决?
2.同一条消息重复消费,可能导致很多问题产生,比如加积分,100加了十次...,扣款扣了十次...
我们可以给消息加上唯一的编号,消费的时候进行判断,如果用了就剔除这条消息,没用就继续使用!
3.消息发出去了,消费者挂了,mq队列中积压了大量的数据,怎么办?
其实除了以上问题,可能还会出现很多问题。
数据一致性(这么多个系统,如果某个系统出问题,其它系统数据也得回滚,分布式事务)
可用性(系统本身可能没有问题,MQ挂了,积分不加了,扣款不扣了?祭天吧)
...