共计 2356 个字符，预计需要花费 6 分钟才能阅读完成。
也许在你们公司从没有使用过 MQ，也不知道这东西是用来干什么的，但是一旦你进入大公司你就会发现，这东西处处可见。今天就来说说 MQ 方面的东西，我公众号有 activemq 的 demo，大家可以自己去看看。
什么是 MQ
Message Queue 简称 MQ，中文消息队列。
“消息”是在两台计算机间传送的数据单位。消息可以非常简单，例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。
消息被发送到队列中。“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。
你可以把它理解为一个中间件，帮你完成多个系统或应用间的消息传递。
为什么要使用 MQ
首先它有3个核心，解耦, 异步, 削峰，因此我们可以想到以下使用场景：
你的系统要和多个系统发生关系，别的系统要从你这获取一些数据，今天 A 系统和你要这样的数据，明天B系统说你的数据有问题，后天C系统让你加个别的数据。你一个人要维护解决很多问题，忙得不可开交。而有了MQ，你就可以通过 Pub/Sub 发布订阅消息这么一个模型，系统就跟其它系统彻底解耦了。只要把消息放到队列里，其它系统就自己去处理自己需要的数据，自己不再考虑该给谁发送数据。比如：下完订单，不再去通知库存做同步处理。把该物品的信息放在队列中，库存自己去选择什么时候去处理计算自己的库存。
还是上面的例子，之前的流程，user浏览器端发起购物请求3ms，订单系统处理数据库300ms，之后库存系统处理数据库300ms，这样同步情况下加起来就要603ms。即使前端有加载提示框，等待时间超过300ms，人眼是能感受到这种延迟的，体验很不好，速度越快才能留住user。现在使用MQ采用异步消息处理，假如消息放进队列需要3ms，那么最终的响应时间是3+3=6ms，对于创建订单和库存计算user并不关心，这样极大的提高了响应时间。
一个大的网站或是应用，总会迎来访问量的高峰，可能是营销活动突然带来的大流量，或是节假日。比如双十一，购物人数突然猛增，并发数提高，数据库的压力突然增大，超出了每秒钟的处理能力，就会导致网站瘫痪。使用mq后，数据库可以不必立马处理这么多的请求，可以自己选择能承受的消息慢慢去处理。所有的消息积压在队列中，而不是同时积压到数据库。加入队列中积压了1亿条数据，而我的数据库只能每秒处理100万条数据，那我就每秒从队列中取出100万条来处理，始终不会超出阈值，这样数据库就不会被挤垮。把峰值慢慢消耗。
现在想想你为什么没有使用到mq吧？或是考略使用mq
使用后带来的威胁
任何事物都有它的两面性，既然有优点那也有缺点：
系统可用性降低
万一mq挂了，队列里面的数据没有了，其它系统数据还没处理完，这可咋整？
系统的复杂度提高了
你用个mq是爽了，其它系统也要对应的修改自己的系统，来消费队列中的消息。硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。
一致性问题
你订单系统操作成功了，但是库存系统却失败了，这样导致了数据的不一致。
所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了 10 倍。但是关键时刻，用，还是得用的。
主流的 MQ 产品
Kafka
ActiveMQ
RabbitMQ
特性
ActiveMQ
RabbitMQ
RocketMQ
Kafka
单机吞吐量
万级，比 RocketMQ、Kafka 低一个数量级
同 ActiveMQ
10 万级，支撑高吞吐
10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响
topic 可以达到几百 / 几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic
topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性
ms 级
微秒级，这是 RabbitMQ 的一大特点，延迟最低
ms 级
延迟在 ms 级以内
可用性
高，基于主从架构实现高可用
同 ActiveMQ
非常高，分布式架构
非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性
有较低的概率丢失数据
基本不丢
经过参数优化配置，可以做到 0 丢失
同 RocketMQ
功能支持
MQ 领域的功能极其完备
基于 erlang 开发，并发能力很强，性能极好，延时很低
MQ 功能较为完善，还是分布式的，扩展性好
功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用
上面表格来自：https://github.com/doocs/adva…
推荐使用
早期大家都在使用 ActiveMQ，适合小型项目，如果你尝试使用MQ，你可以选择。
RabbitMQ 社区活跃度比较高，开源，有问题可以在社区寻求帮助。但是底层使用了 erlang 语言，不是小公司又能力掌控的。
RocketMQ 阿里出品，是用的中国公司比较多，经历过使用场景的考验，且自家产品也在用，不用担心。但是社区活跃度不高。推荐使用。
如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。