消息队列MQ的运用场景

提到MQ，就必须要说下现在主流的MQ，大概有四个，Active MQ，Rabbit MQ，RocketMQ和kafkaMQ。先说下各自的特点

ActiveMQ : 单机吞吐量级别为万级别的（以下都是单机），延时在ms级别，基于主从架构实现高可用，消息可靠性为低丢失；

RabbitMQ : 吞吐量与activemq一样为万级别的，但是这种消息队列延时特别低，为微秒级别的，而且消息基本不丢失，可用于高并发，现在这种MQ用的比较普遍，个人开发和小公司都是可以的。

RocketMQ ： 吞吐量为10万级别的，可以支持大量的topic，消息可靠性可以通过参数配置优化做到丢失率为0，延时在ms级别，基于分布式架构。

KafkaMQ ：吞吐量也是10万级别的，但是在topic上面，一旦过多就会导致吞吐量大幅度降低，高可用性基于主从架构，经过配置参数优化也可以做到0丢失。目前主要用大公司用于实时计算和日记采集。

消息队列我所了解到的是三种应用场景（优势），解耦，异步，削峰。

解耦：降低系统代码之间耦合性，比如说BC系统需要用到A系统里面的数据，A系统写了程序接口将数据发送给BC系统，但是当C系统突然不需要了，改为D系统需要，那么A系统就必须重写接口，当系统越来越大，A系统的负责人有可能就会累死。。。而且A系统与其他系统高度耦合，如果其他系统突然出现故障，A系统还需要重发，保证数据的高可用性。

所以使用MQ后，A系统只需要将数据发送到MQ中，谁需要调用就直接从消息队列中拿就行。

异步 ： 当对一条数据进行操作时，A系统接受请求在自己本地写入数据库内，时间大概30ms，同时BCD三个系统还需要记录该条数据写入数据库，每个系统大概300ms，那么用户在请求操作后，需要等待将近1000ms，一般做的系统都会在200ms内，会造成用户体验不是很好。使用MQ，将数据写入其中，时间将会大大减少，提高了用户体验，然后再慢慢消费，等结束后返回个ack标志。

削峰：假设我们自己写的系统处理数据的并发量为1000条/s，但是在中午11点-下午2点是网站的访问高峰期，同时操作，每秒的请求并发数量激增到2万，我们的系统基本就可以崩溃了，可以想想我们在大学里每次选课，系统都会崩掉的场景。可是高峰期一过，并发量就有会大幅度降低，这时候我们采用MQ，将请求写入到MQ中，等高峰期过去之后，A系统再从MQ中将积累的消息解决掉。