MessageQueue Intro
什么是MQ
- MQ全称是Message Queue，消息的队列，因为是队列，所以遵循FIFO 先进先出的原则，它是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ是一种非常常见的上下游"逻辑解耦+物理解耦"的消息通信服务
为什么使用MQ
流量削峰：解决高并发问题
- 例如秒杀活动，可能会在短时间内产生大量请求同时打到服务端，如果后端对每个请求都进行数据库读写操作，定会造成服务器压力过大，产生服务异常甚至不可用。我们可以通过使用MQ实现流量缓冲，将所有请求先放入消息队列中，服务端每次处理业务先从消息队列获取，从而实现流量削峰，解决高并发问题
应用解耦：提升系统可用性
- 例如电商应用中有订单系统、库存系统、物流系统、支付系统，当用户创建订单后，先后调用库存系统、物流系统、支付系统，任何一个子系统出了故障，都会造成下单失败。引入消息队列后，系统间耦合调用的问题会减少，任何一个子系统出现故障都不会影响用户下单，子系统故障恢复后，会继续处理消息，提升系统可用性。
异步处理：提升响应速度
- 当用户在客户端提交了一个同步请求，后端处理需要耗时很久才能响应，这对用户体验来说无疑是致命的。如果说用户并不关心请求是否处理完成，对于一些耗时的非事务性的业务处理，可以使用消息队列异步请求的方式，将请求信息放入消息队列，直接返回客户端响应，后端监听队列自行处理，提升响应速度
常见的MQ
Kafka
- 大数据领域内的消息传输，则绕不开Kafka，这款为大数据而生的消息中间件，以其百万级TPS的吞吐量名声大噪
- 优点：单机写入TPS约在百万条/秒，最大的优点，就是吞吐量高。时效性ms级可用性非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用，消费者采用Pull方式获取消息，消息有序，通过控制能够保证所有消息被消费且仅被消费一次；有优秀的第三方Kafka Web管理界面Kafka-Manager；在日志领域比较成熟，被多家公司和多个开源项目使用；主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集场景中大规模使用。
- 缺点：单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，Load越高，发送消息响应时间变长，使用短轮询方式，实时性取决于轮询间隔时间，消费失败不支持重试；支持消息顺序，但是一台代理宕机后，就会产生消息乱序，社区更新较慢
RabbitMQ
- 2007年发布，是一个在AMQP（高级消息队列协议）基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。
- 优点：由于erlang语言的高并发特性，性能较好；吞吐量到万级，MQ功能比较完备、健壮、稳定、易用、跨平台、支持多种语言，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX文档齐全；开源提供的管理界面非常棒，用起来很好用，社区活跃度高，更新频率相当高。
- 缺点：商业版需要收费，学习成本较高
RocketMQ
- 2007年发布，是一个在AMQP（高级消息队列协议）基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。
- 优点：由于erlang语言的高并发特性，性能较好；吞吐量到万级，MQ功能比较完备、健壮、稳定、易用、跨平台、支持多种语言，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX文档齐全；开源提供的管理界面非常棒，用起来很好用，社区活跃度高，更新频率相当高。
- 缺点：商业版需要收费，学习成本较高
ActiveMQ
- ActiveMQ是一款非常古老的MQ。
- 优点：单机吞吐量万级，时效性ms级，可用性高，基于主从架构实现高可用性，消息可靠，丢失数据的概率较低。
- 缺点：官方社区现在对ActiveMQ 5.x维护越来越少， 高吞吐量场景较少使用。