生存有时是层峦叠嶂的旷野，有时又是起伏不定的山陵，但只有心怀酷爱，就可逾越世间山河大海。

在之前的业务中，应用了Kafka和RabbitMQ两种音讯队列，这篇文章来做一个总结。

音讯队列中间件是分布式系统中重要的组件，次要实现异步音讯，利用解耦，流量削峰及音讯通信等性能。

上面举例说明在理论利用中音讯队列是如何应用的。

音讯队列利用场景

1、异步解决

以用户注册，并且须要注册邮件和短信为例。

用户注册后，须要发送注册邮件和注册短信。传统的做法有两种：串行和并行形式。如下图所示：

1）串行形式：将注册信息写入数据库胜利后，发送注册邮件，再发送注册短信。以上三个工作全副实现后，返回给客户端。

2）并行形式：将注册信息写入数据库胜利后，发送注册邮件的同时，发送注册短信。以上三个工作实现后，返回给客户端。与串行的差异是，并行的形式能够进步解决的工夫。

假如三个业务节点每个应用50毫秒钟，不思考网络等其余开销，则串行形式的工夫是150毫秒，并行的工夫可能是100毫秒。

因为CPU在单位工夫内解决的申请数是肯定的，假如CPU1秒内吞吐量是100次。

则串行形式1秒内CPU可解决的申请量是7次（1000ms/150ms），并行形式解决的申请量是10次（1000ms/100ms）

小结：如以上案例形容，传统的形式零碎的性能（并发量，吞吐量，响应工夫）会有瓶颈。如何解决这个问题呢？

引入音讯队列，将不是必须的业务逻辑，异步解决。革新后的架构如下：

依照以上约定，用户的响应工夫相当于是注册信息写入数据库的工夫，也就是50毫秒。注册邮件，发送短信写入音讯队列后，间接返回，因而写入音讯队列的速度很快，根本能够疏忽，因而用户的响应工夫可能是50毫秒。

因而架构扭转后，零碎的吞吐量进步到每秒20 QPS。比串行进步了3倍，比并行进步了两倍。

2、利用解耦

以用户下单购买业务为例。

用户下单后，订单零碎须要告诉库存零碎。传统的做法是，订单零碎调用库存零碎的接口。如下图

传统模式的毛病：

1）如果库存零碎无法访问，则订单减库存将失败，从而导致订单失败。

2）订单零碎与库存零碎耦合。

如何解决以上问题呢？引入利用音讯队列后的计划，如下图：


1）订单零碎：用户下单后，订单零碎实现长久化解决，将音讯写入音讯队列，返回用户订单下单胜利。

2）库存零碎：订阅下单的音讯，采纳拉/推的形式，获取下单信息，库存零碎依据下单信息，进行库存操作。

如果：在下单时库存零碎不能失常应用。也不影响失常下单，因为下单后，订单零碎写入音讯队列就不再关怀其余的后续操作了。实现订单零碎与库存零碎的利用解耦。

3、流量削峰

流量削峰也是音讯队列中的罕用场景，个别在秒杀或团抢流动中应用宽泛。

秒杀流动，个别会因为流量过大，导致流量暴增，利用挂掉。为解决这个问题，须要在利用前端退出音讯队列。

1）能够管制流动的人数。

2）能够缓解短时间内高流量压垮利用。

1）用户的申请，服务器接管后，首先写入音讯队列。如果音讯队列长度超过最大数量，则间接摈弃用户申请或跳转到谬误页面。

2）秒杀业务依据音讯队列中的申请信息，再做后续解决。

4、音讯通信

音讯通信是指，音讯队列个别都内置了高效的通信机制，因而也能够用作音讯通信。比方实现点对点音讯队列，或者聊天室等。

以上理论是音讯队列的两种音讯模式，点对点或公布订阅模式。

罕用音讯队列

ActiveMQ、RabbitMQ、RocketMQ、Kafka比拟

生产者消费者模式（Producer-Consumer）

ActiveMQ-反对，RabbitMQ-反对，RocketMQ-反对，Kafka-反对。

公布订阅模式（Publish-Subscribe）

ActiveMQ-反对，RabbitMQ-反对，RocketMQ-反对，Kafka-反对。

申请回应模型（Request-Reply）

ActiveMQ-反对，RabbitMQ-反对，RocketMQ-不反对，Kafka-不反对。

API齐备性

ActiveMQ-高，RabbitMQ-高，RocketMQ-高，Kafka-高。

多语言反对

ActiveMQ-反对，RabbitMQ-反对，RocketMQ-只反对JAVA，Kafka-反对。

单机吞吐量

ActiveMQ-万级，RabbitMQ-万级，RocketMQ-万级，Kafka-十万级。

音讯提早

ActiveMQ-无，RabbitMQ-微秒级，RocketMQ-毫秒级，Kafka-毫秒级。

可用性

ActiveMQ-高（主从），RabbitMQ-高（主从），RocketMQ-十分高（分布式），Kafka-十分高（分布式）。

音讯失落

ActiveMQ-低，RabbitMQ-低，RocketMQ-实践上不会失落，Kafka-实践上不会失落。

文档的齐备性

ActiveMQ-高，RabbitMQ-高，RocketMQ-高，Kafka-高。

提供疾速入门

ActiveMQ-有，RabbitMQ-有，RocketMQ-有，Kafka-有。

社区活跃度

ActiveMQ-高，RabbitMQ-高，RocketMQ-中，Kafka-高。

商业反对

ActiveMQ-无，RabbitMQ-无，RocketMQ-阿里云，Kafka-阿里云。

ActiveMQ、RabbitMQ、RocketMQ、Kafka总体来说

ActiveMQ

历史悠久的开源我的项目，曾经在很多产品中失去利用，实现了JMS1.1标准，能够和spring-jms轻松交融，实现了多种协定，不够笨重（源代码比RocketMQ多），反对长久化到数据库，对队列数较多的状况反对不好。

RabbitMQ

它比Kafka成熟，反对AMQP事务处理，在可靠性上，RabbitMQ超过Kafka，在性能方面超过ActiveMQ。

RocketMQ

RocketMQ是阿里开源的消息中间件，目前在Apache孵化，应用纯Java开发，具备高吞吐量、高可用性、适宜大规模分布式系统利用的特点。

RocketMQ思路起源于Kafka，但并不是简略的复制，它对音讯的牢靠传输及事务性做了优化，目前在阿里团体被广泛应用于交易、充值、流计算、音讯推送、日志流式解决、binglog散发等场景，撑持了阿里屡次双十一流动。

因为是阿里外部从实际到产品的产物，因而外面很多接口、API并不是很广泛实用。其可靠性毋庸置疑，而且与Kafka一脉相承（甚至更优），性能强劲，反对海量沉积。
Kafka

Kafka设计的初衷就是解决日志的，不反对AMQP事务处理，能够看做是一个日志零碎，针对性很强，所以它并没有具备一个成熟MQ应该具备的个性。

Kafka的性能（吞吐量、tps）比RabbitMQ要强，如果用来做大数据量的疾速解决是比RabbitMQ有劣势的。