MQ

消息队列，本质是一个队列，先进先出，只不过队列中存放的内容是message而已。

为啥学习MQ

1.流量消峰

如果一个订单系统最多每秒能处理一万次订单，正常情况下我们下单1秒后就能返回结果。但是在高峰期，如果有两万次下单操作，系统是处理不了的，只能限制订单超过一万后不允许用户下单。使用消息队列做缓冲，我们可以取消一万笔订单的限制，把一秒内下的订单分散成一段时间来处理，通过排队逐一处理消息，这时有些用户可能在下单十几秒后才能收到下单成功的操作，但是比不能下单的体验要好。

2.应用解耦

电商应用为例，应用中有订单系统、库存系统、物流系统、支付系统。用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出现了故障，都会导致下单操作异常。当转变成基于消息队列的方式后，系统间调用的问题会减少很多。比如物流系统发生故障，需要几分钟来修复。在这几分钟时间里，物流系统要处理的内存被缓存在消息队列中，用户的下单操作可以正常完成。当物流系统恢复后，继续处理订单信息即可。下单用户感受不到物流系统的故障，提升系统的可用性。

3.异步处理

 如果A调用B，B需要花很长时间执行。但是A需要指定B什么时候执行完。

传统方式：

1.A等一段时间去调用B的查询api接口去查询B是否执行完。

2.A提供一个回调api接口，B执行完后调用A的回调api通知A服务。

使用消息队列：

A调用B后，只需要监听B处理完成的消息，当B处理完成后，会发送一条消息给MQ,MQ会将此消息转发给A服务。这样A服务既不能循环调用B的查询api，也不用提供回调api。A服务还能及时的到异步处理成功的消息。

MQ的分类

1.ActiveMQ

比较老，维护少，很少使用高吞吐量场景。

2.Kafka

为大数据而生的消息中间件。百万级TPS的吞吐量。性能卓越，单机写入TPS越百万条/s。

Kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据。

Kafka Web管理界面Kafka-Manager。

在日志领域比较成熟。大数据领域实时计算以及日志采集应用广泛。

缺点：Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息的响应时长变长，消费失败不支持重试，也就是容易丢失消息。支持消息顺序，但是一台代理宕机后，就会产生消息乱序，社区更新较慢。

适用场景：产生大量数据的数据收集业务，大型公司建议使用，是日志采集功能的首选。

3.RocketMQ

阿里巴巴开源产品，java语言编写，设计时候参考了Kafka,并做出自己的改进。被阿里巴巴广泛应用于订单、交易、充值、流计算、消息推送、日志流式处理，binglog分发等场景。

单机吞吐量十万级，可用性非常高，分布式架构，消息可以做到0丢失，mq功能较为完善，还是分布式的，扩展性好，支持10亿级别的消息堆积，不会因为堆积导致性能下降，源码是java可以自己阅读的源码，定制自己公司的MQ。

缺点：支持的客户语言不多，目前是java和C++，其中C++不成熟。社区活跃度一般，没有在MQ核心中去实现JMS等接口，有些系统要迁移需要修改大量代码。

适用场景：为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，在大量交易涌入时，后端可能无法及时处理的情况。在阿里双11已经经历了多次考验。高并发场景。

4.RabbitMQ

使用AMQP高级消息队列协议基础上完成的，可复用的企业消息系统，是最主流的消息中间件之一。由于erlang语言的高并发特性，性能较好。吞吐量到万级，功能比较完备、健壮、稳定、易用、跨平台、支持多种语言：Python,Ruby,.NET,java,jms,c,php,ActionScript,xmpp,stomp等。

支持ajax文档齐全，开源提供的管理界面非常好，社区活跃度高，更新频率高。

缺点：商业版需要收费，学习成本高。

适用场景：erlang语言本身的并发优势，性能好，时效性微秒级，如果数据量没那么大，中小型公司优选。