之前写过关于ActiveMQ的学习笔记,然后面试时被问到MQ时依然不知道从哪开始说起,并且我发现即使写了ActiveMQ相关的学习笔记,然后并没什么卵用,依然忘的比较彻底.
然后我就意识到我的学习方法不太对,因为我对于MQ的认识只是停留在了很浅的一个层面,只是简单的认为它是一个存储消息的容器,需要用到的时候对MQ进行存取操作就行了.
然而如果我先从MQ开始入手学习,在学习ActiveMQ或者RabbitMQ时,我只需要记住他们的一些特点即可,这样会轻松很多并且更容易理解,所以这篇文章也是学习MQ的笔记.
参考链接关于MQ的几件小事
MQ(message queue)的概念:
消息的传输过程中的保存消息的容器.
MQ的优势:
1.解耦:
可以举个例子,例如当用户下单后,同时需要进行的步骤有在库存系统中将库存减一,客户系统中该用户的信息更新,订单系统需要生成一个订单等等,
假设没有MQ的话,需要分别调用库存系统,客户系统,订单系统中的方法,将数据作为参数传入,这就造成了比较强的依赖性,三个系统中也有大量的业务逻辑代码,**多个不相关系统因为需要同一个参数聚集到了一起,**只要出现一个问题就会导致其他系统都受影响.
而通过MQ则只需要1步,将消息发送到MQ中即可,这样的话大大降低了代码的耦合度,即使库存系统出现错误也不会影响到其他模块.
2.异步:
还是上面的例子,如果没有MQ,三个或者更多系统的业务代码会依次执行且需要等待处理结果,响应时间长,用户体验差.
而通过MQ则不需要等待,直接发送到MQ后即可返回给用户结果,而其它系统可以同时从MQ中获取数据消费,效率更高. 而且就算后续出了异常,用户也不知道,可以偷偷处理~~. 想必大家都遇到过下单成功后查询不到的问题吧哈哈.
3.扩展性
上边两个特点也能侧面展现出这个优势,当需要新增模块的时候,例如我添加物流系统,需要订单号,可以直接去MQ中获取即可,而不是将业务代码添加在源代码中.也可以理解为提高数据的可复用性
4.削峰
当访问量激增时,例如促销活动会导致并发量比较大,促销会生成大量的订单,此时会针对订单关联的系统和数据库造成访问压力,通过MQ可以将压力转移到MQ中,而MQ会根据自己的消费能力消费数据,保证了下游系统的稳定性,这样当我们在优化稳定性的时候可以优先针对上游(访问入口)和MQ(集群)进行优化.
消费者确认模式:
JMS提供的3中模式：
auto_acknowledge：
消费者接收到消息后自动确认。
client_acknowledge
client端确认模式，手动确认。
dups_ok_acknowledge
一条消息可以被多次消费，为了确保“一次且仅仅一次发送语义”。影响MQ性能。
缺点
从上面的总结可以看出来,通过MQ会导致整个系统对MQ的依赖性非常强,当MQ出现问题时会造成整个系统瘫痪,上面提到的削峰针对于下游系统稳定性高了,但是并发压力集中在了MQ上,因此当访问压力过大时可以通过集群保证MQ的稳定性.
数据一致性: 上面也提到过,例如用户下单后,返回下单成功通知,下游的库存系统在减1库存操作时出现异常,这样就出现数据不一致的问题,
来源：CSDN
作者：programmer_hard
链接：https://blog.csdn.net/programmer_hard/article/details/104799502