消息队列：解耦、异步、削峰，现有MQ对比以及新手入门该如何选择MQ?看，未来的博客-mq比较

本文大量引用了ImapBox博主：晨兮要努力的博客：消息队列作用（解耦、异步、削峰），目测是个小姐姐了。看这个文章还要有点设计模式的基础哈哈
以及参考了ImapBox博客专家：ithuangqing的博客：编码之外，一文搞懂什么是消息队列！
他们写的都很好。然后我是学C++的，在群里天天看大佬们聊RabbitMQ、RocketMQ、Kafka，我觉得我得入门并实践一下，拉近和大佬们的距离。
文末还会放上一些我找到C++使用MQ的资料。

什么是消息队列（MQ）?

其实字面意思很清楚了，存放消息的队列。
由于它的应用场景在服务器方面被重新定义而名声大噪，它的价值也被由原先的通信而重新定义，成为高并发场景下，分布式系统解耦合，任务异步，流量削峰的利器。

其实消息队列属于一种中间件。

解耦合

• 传统做法
  • 传统的做法是，订单系统调用库存系统的接口。如下图：
    
  • 传统模式的缺点：假如库存系统无法访问，则订单减库存将失败，从而导致订单失败，订单系统与库存系统耦合

如何解决以上问题呢？

• 使用消息队列
  • 引入应用消息队列后的方案，如下图：
    
• 订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功
• 库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作
• 在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦.

举个新例子：

比如说某一个系统A要与其他系统打交道（即调用其中的方法），如果其它系统改变或者新增系统，那么A系统都会改变，这样的话耦合度比较高，比较麻烦。

使用消息队列来解决这个问题。

我们A系统将产生的数据发入消息队列中，其它的系统再去消息队列来进行消费，那么其他系统的减少或者新增系统即与A系统关系不大了，这样来实现解耦的功能。

异步

场景说明：用户注册后，需要发注册邮件和注册短信

• 传统做法

  • 串行：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信
    

  • 并行：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信
    

其实让我想我也就只能想到并行。

• 使用消息队列
  • 将不是必须的业务逻辑，异步处理。改造后的架构如下：

举个新例子

某一个用户使用系统A，但是A要调用系统B,C,D,但是每一个系统返回的时间是不一样的，你必须要等待全部返回后才可以响应用户。

如果我们这里采用消息队列，当用户发送请求后，我们把数据传给消息队列，然后再直接响应给用户我已经发送了信息。

流量削峰

场景说明：商品秒杀业务，一般会因为流量过大，导致流量暴增，应用挂掉

• 传统做法

  • 限制用户数量

• 使用消息队列

  • 用户的请求，服务器接收后，首先写入消息队列，秒杀业务
    

举个新例子

比如平常用户的请求我们会直接访问数据库，在大量用户过来的时候，这样的话我们会对数据库照常比较大的压力

在这里我们增加一个消息队列，这样的话不管你请求来多少，我先存入消息队列，然后我再让系统慢慢的处理你的请求（如右图），这样很好的减缓了数据库的访问压力。

有哪些消息队列？

当下比较流行的，其实也就三种：

RabbitMQ RocketMQ Kafka 

RabbitMQ

RabbitMQ在一开始是很强势的，也就是曾经很辉煌，当然，现在也不赖，只不过由于一些后起之秀，光芒不胜从前了，毕竟后来的也很优秀，RabbitMQ它的特点你需要记住：

开箱即用 轻量级 易于部署和使用 支持灵活的路由配置 客户端支持的编程语言是最多的（至少目前是） …… 

不足之处嘛：

使用Erlang语言编写（这是个啥语言我之前真不知道，这就导致一个大问题，想要二次开发与扩展，以及遇到问题的话，解决的成本都比较高啊） 对消息堆积支持的不友好（消息队列就是进行消息收发的啊，大量的消息扔进RabbitMQ的话，它的性能表现就不那么好了） 性能相比较RocketMQ和Kafka是最差的 

RocketMQ

RocketMQ属于明星产品啊，它是阿里巴巴搞出来的，后来捐赠给了Apache基金会，2017年成了其顶级项目，阿里内部也是使用的它。

可以说，RocketMQ是一款综合变现都很不错的消息队列产品，无论是性能还是稳定性，亦或是可靠性，RocketMQ表现的都很不错，反正吧，这家伙是越来越首欢迎了。

Kafka

它一开始是为了用于处理海量日志的，所以啊，它与大数据关系颇深，它在处理海量日志啊，或者是监控信息，以及流计算这些的时候，无疑是最好的选择。

而且Kafka可以说是与周边开源产品兼容最好的一个中间件，也就是说，几乎所有的相关开源软件系统都会优先支持Kafka。

另外它使用java和Scala编写，在性能，稳定性和可靠性上也都表现优异，这么一看，这家伙好像是集万众宠爱于一身啊，妥妥的老大啊，各方面都很优异啊。

但是它对消息是进行异步批量进行处理的，这就带来一个问题，延迟比较高，这点他是比不上RocketMQ。

该如何选择呢？

作为一个新手，我问了群里的大佬们，得到一个答案：学后面两个。

首先对于RabbitMQ，我们讲到它的时候，可能最先想到的就是它的轻量，开箱即用易于维护，所以基于这个特点，如果你的项目需要用到消息队列，但是消息队列又不是你系统的主角，那么RabbitMQ是一个不错的选择。

当然，如果对于你的系统，消息队列扮演着重要的角色，对性能，稳定性以及可靠性等都有一定的要求，更重要的是你需要使用消息队列来处理在线业务场景，那么你最好选择RocketMQ，因为它优越的低延迟，以及优秀的稳定性绝对会给你给力的表现。

如果你是需要处理海量的信息，业务涉及大数据，流计算等，那么这样的情况下，Kafka无疑是最好的选择了。

所以嘛，我选择的是RocketMQ

目前我手上的资料

目前我有一份Racket的中文手册，ImapBox下载的。
有一套C++使用Rocket的Demo，ImapBox下载的。
还有一些：

rocketmq的linux下C++版demo RocketMQ延迟消息的代码实战及原理分析 RabbitMQ入门，我是动了心的 kafka全操作精讲 

又需要可以私信我