MQ消息队列概述及主流MQ分析

首先引入几个问题

1.概念：MQ是什么？

2.MQ的工作流程

3.为什么要使用MQ，MQ的作用

4.主流mq有哪些，各自优缺点

MQ（消息队列）

介绍

全称Message Queue，是在消息的传输过程中保存消息的容器，多用于分布式系统之间 进行通信。消息队列就是基础数据结构中的“先进先出”的一种数据机构。想一下，生活中买东西，需要排队，先排的人先消费，就是典型的“先进先出”。所以得出结果：MQ是一种先进先出的保存消息的容器。

MQ的工作流程

【1】发送端 MQ-Product （消息生产者）将消息发送给 MQ-server；
【2】MQ-server 将消息落地，持久化到数据库等；
【3】MQ-server 回 ACK 给 MQ-Producer；
【4】MQ-server 将消息发送给消息接收端 MQ-Consumer （消息消费者）；
【5】MQ-Consumer 消费接收到消息后发送 ACK 给 MQ-server；
【5】MQ-server 将落地消息删除；

MQ解决什么问题

MQ是一直存在，不过随着微服务架构的流行，成了解决微服务之间问题的常用工具。

1> 应用解耦

以电商应用为例，应用中有订单系统、库存系统、物流系统、支付系统。用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障，都会造成下单操作异常。

当转变成基于消息队列的方式后，系统间调用的问题会减少很多，比如物流系统因为发生故障，需要几分钟来修复。在这几分钟的时间里，物流系统要处理的数据被缓存在消息队列中，用户的下单操作可以正常完成。当物流系统恢复后，继续处理订单信息即可，中单用户感受不到物流系统的故障。提升了系统的可用性。

2> 异步提速

ABCD四个系统，A系统收到一个请求，需要在自己本地写库，还需要往BCD三个系统写库，A系统自己写本地库需要3ms，往其他系统写库相对较慢，B系统200ms ，C系统350ms，D系统400ms，这样算起来，整个功能从请求到响应的时间为30ms+300ms+350ms+300ms=980ms,如果用了MQ，用户发送请求到A系统耗时30ms，A系统发送三条消息到MQ，假如耗时50ms，用户从发送请求到相应30ms+50ms=80ms，用户的体验非常好。

3> 流量削峰
举个实例，2020年爆发的这场新冠病毒，导致各大线上商城APP里面的口罩被抢购一空，在这种情况下，JD商城开启了一场每晚八点的抢购3Q口罩的活动，每天下午三点进行预约，晚上八点抢购，从JD商城刚上线这个活动，我连续抢了近一个周，也算是见证了一个百万并发量系统从出现问题到完善的一个过程，最初第一天，我抢购的时候，一百多万预约，到八点抢购估计也能有百万的并发量，可是第一天，到八点我抢的时候，由于并发量太高，直接把JD服务器弄崩了，直接报了异常，可能JD在上线这个活动的时候也没能够想到会有那么高的并发，打了一个猝不及防，但是这只是在前一两天出现报异常的情况，后面却没有再出现异常信息，到后来再抢购只是响应的时间变得很慢，但是JD系统并没有崩溃，这种情况下一般就是用了MQ（或者之前用了MQ，这次换了个吞吐量级别更高的MQ），也正是利用了MQ的三大好处之一——削峰。
JD系统每天0—19点，系统风平浪静，结果一到八点抢购的时候，每秒并发达到百万，
假设JD数据库没秒能处理1.5w条并发请求（并非实际数据，主要为了举例）,到八点抢购的时候，每秒并发百万，这直接导致系统异常，但是八点一过，可能也就几万用户在线操作，每秒的请求可能也就几百条，对整个系统毫无压力
 

MQ的劣势

（1） 系统可用性降低
系统引入的外部依赖越多，系统稳定性就越差。一旦MQ宕机，就会对业务产生影响，必须保证MQ的高可用。

（2） 系统复杂性提高
MQ的加入大大增加了系统的复杂性，需要保证消息没有被重复消费、处理好消息丢失的情况、保证消息传递的顺序性。

（3）一致性问题
对于MQ中传来的消息数据，如果A、B系统处理成功了，C系统处理失败了，如果保证数据处理的一致性？

使用MQ需要满足的条件

（1）生产者不需要从消费者处 获得反馈。引入消息队列之前的直接调用，其接口的返回值应该为空，才能使下层的动作还没做，上层当成做完了继续往后走，使异步成为可能；

（2）容许短暂的不一致性；

四大主流MQ（kafka、ActiveMQ、RabbitMQ、RocketMQ）各自的优缺点

目前业界四大主流的MQ有kafka、ActiveMQ、RabbitMQ、RocketMQ。

特性	ActiveMQ	RabbitMQ	RocketMQ	kafka
单机吞吐量	万级，吞吐量比RocketMQ和Kafka要低了一个数量级	万级，吞吐量比RocketMQ和Kafka要低了一个数量级	10万级，RocketMQ也是可以支撑高吞吐的一种MQ	10万级别，这是kafka最大的优点，就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic数量对吞吐量的影响			topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic	topic从几十个到几百个的时候，吞吐量会大幅度下降所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源
时效性	ms级	微秒级，这是rabbitmq的一大特点，延迟是最低的	ms级	延迟在ms级以内
可用性	高，基于主从架构实现高可用性	高，基于主从架构实现高可用性	非常高，分布式架构	非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据		经过参数优化配置，可以做到0丢失	经过参数优化配置，消息可以做到0丢失
功能支持	MQ领域的功能极其完备	基于erlang开发，所以并发能力很强，性能极其好，延时很低	MQ功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准
优劣势总结	非常成熟，功能强大，偶尔会有较低概率丢失消息，社区活跃度低	erlang语言开发，性能极其好，延时很低；吞吐量到万级，功能完备而且开源提供的管理界面非常棒，社区相对比较活跃，RabbitMQ确实吞吐量会低一些，掌控很弱，基本依赖于开源社区的快速维护和修复bug。而且rabbitmq集群动态扩展会很麻烦。主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。	接口简单易用，大规模吞吐，性能好，分布式扩展也，社区维护还可以，可靠性和可用性都是ok的，可以支撑大规模的topic数量，支持复杂MQ业务场景而且一个很大的优势在于，基于java	核心功能少，高吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量而且kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集

至此，mq概述到此结束，感谢观看，希望对你有所帮助。