MQ 的相关概念

MQ(message queue)：本质是个FIFO 先入先出的队列，还是一种跨进程的通信机制，用于上下游传递消息

1.MQ作用：
(1)流量消峰：在流量高峰期，使用消息队列做缓冲
(2)应用解耦：
耦合：一笔订单数据->（库存系统+物流系统+支付系统），任何一个子系统出了故障，都会造成下单 *** 作异常
解耦：一笔订单数据->MQ->（库存系统、物流系统、支付系统）,比如物流系统因为发生故障,数据被<缓存>在消息队列中，当物流系统恢复后，继续处理订单信息即可，下单用户感受不到物流系统的故障，提升系统的可用性
(3)异步处理
A调用B (B需要花费很长时间执行), A需要知道B什么时候可以执行完
一般方法(不优雅)：(1).A过一段时间去调用B的查询api查询，(2).A提供一个callback api，B执行完之后调用api通知A服务
消息总线：监听B处理完成的消息，当B处理完成后，会发送一条消息给MQ，MQ会将此消息转发给A服务(菜鸟驿站)

2.MQ的分类：
(1)ActiveMQ
单机吞吐量万级，时效性 ms 级，可用性高
维护少，高吞吐量场景较少使用
(2)Kafka
吐量高，在大数据领域的实时计算以及日志采集被大规模使用
Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，社区更新较慢
(3)RocketMQ
单机吞吐量十万级,可用性非常高，分布式架构,消息可以做到 0 丢失，支持 10 亿级别的消息堆积，不会因为堆积导致性能下降
支持的客户端语言不多，目前是 java 及 c++，其中 c++不成熟；社区活跃度一般
(4)RabbitMQ
由于 erlang 语言的高并发特性，性能较好；吞吐量到万级，支持多种语言，社区活跃度高；更新频率相当高
商业版需要收费,学习成本较高

3.MQ的选择：
(1)Kafka
Kafka 主要特点是基于 Pull 的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集
和传输，适合产生大量数据的互联网服务的数据收集业务。大型公司建议可以选用，如果有日志采集功能，
肯定是首选kafka了
(2)RocketMQ
天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削
峰，在大量交易涌入时，后端可能无法及时处理的情况。RoketMQ 在稳定性上可能更值得信赖，这些业务
场景在阿里双 11 已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择 RocketMQ
(3)RabbitMQ
结合 erlang 语言本身的并发优势，性能好时效性微秒级，社区活跃度也比较高，管理界面用起来十分
方便，如果你的数据量没有那么大，中小型公司优先选择功能比较完备的RabbitMQ