消息队列，我只选RabbitMQ！

高并发架构是架构师的必修课，而消息队列，则是王冠上最闪亮的那颗明珠！能否驾驭消息队列这款高并发神器，亦成为架构师的试金石。作为专注.NET领域十多年的老架构师，下面从队列本质、技术选型、实战应用三个方面，给大家整理下个人心得，希望能对大家有所帮助。

队列本质

当下成熟的消息队列产品非常多，各种丰富的特性让人眼花缭乱，难以抉择。穿透现象先看本质，消息队列其实就是一个第三方应用程序，管理着一块儿内存空间，能快速存取数据，具备先进先出特性。只是跟系统架构设计相结合，产生了神奇的特效，请看下图：

基于消息队列的异步架构图

消息队列的好处：

---流量削峰：高并发的核心问题就是请求集中在同一时间，服务器来不及处理，而有了消息队列，就可以将请求的数据打包放入，然后由后端处理器异步处理，降低高峰期的并发处理压力，用时间换空间

---高可用性：90%系统的不可用都是因为数据库，而在异步化架构里，就算数据库挂掉、甚至处理器挂掉，均不影响系统的可用性，客户端可以继续响应请求，只是将请求堆积在消息队列即可

---高扩展性：异步化架构里，客户端和处理器是通过消息来交互的，只要保证消息格式不变，可以随意独立演化扩展

技术选型

男怕入错行，女怕嫁错郎，技术选型很迷茫！网上充斥着各种不负责任的分析文章，侃侃而谈，似是而非，胡说八道！下面我结合下个人开发实践经历，以及精选测试后的有效数据，给大家做下分析和推荐，仅一家之言！

1 MSMQ

微软自家重量级队列，内置在Windows Server，除了安装省事儿外，几乎没别的优势，在.NET Core跨平台时代里，已经基本淘汰！

2 ActiveMQ

最老牌的开源消息队列，想当年是开源消息队列首选，不过眼下已进入老年期，社区不活跃了。无论是功能还是性能，ActiveMQ 都已经与现代的消息队列存在明显的差距，它存在的意义在于兼容那些还在用老系统，比如2013年我给广东电信做外包项目时接入的还是ActiveMQ，该选项可以基本排除！

3 Redis-List

互联网开发必备的Nosql-Redis，其List数据结构就是一个轻巧型的队列。优势是Redis的普及性，缺陷是现代化消息队列很多必备功能和特性缺失，只能满足中小型项目需求！

4 ZeroMQ

严格来说 ZeroMQ 并不是消息队列，而是一个基于消息队列的多线程网络库，如果你的需求是将消息队列的功能集成到你的系统进程中，可以考虑使用 ZeroMQ，否则是跟异步化独立架构矛盾的，Pass！

5 RocketMQ

源自阿里的开源消息队列，经历过多次“双十一”考验，它的性能、稳定性和可靠性都是值得信赖的。作为优秀的国产消息队列，近年来越来越多的被国内众多大厂使用。唯一的原罪是为Java开发的国产消息队列，与周边生态系统的集成和兼容程度要略逊一筹，对.NET支持就很不友好，果断放弃不折腾！

6 RabbitMQ

特点是Messaging that just works，“开箱即用的消息队列”。也就是说，RabbitMQ 是一个相当轻量级的消息队列，非常容易部署和使用。这里有个RabbitMQ的安装视频，欢迎扫码自取。

RabbitMQ号称是世界上使用最广泛的开源消息队列，其社区资源丰富、对各种开发语言支持友好、还有各种定制化插件，对于.NETer是非常友好的。还有个独特的Exchange设计，非常实用。虽然也有并发不如其他队列高的问题，但是集群下大部分应用场景是毫无问题的，推荐！

7 Kafka

一个非常成熟的消息队列产品，无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求，而且拥有着极致性能。跟周边生态系统的兼容性是最好的没有之一，尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持 Kafka。但是其致命伤在于Kafka是为了性能选择了异步批量发送模式，导致延时太高，无法满足在线业务场景，常用于日志数据分析等场景！