于周末时分，与朋友一道前往深圳杨梅坑的海边游玩，到了下午四点多，开始排队等候乘坐快艇前往鹿嘴山庄。岸边的阶梯之处挤满了人群，然而载客的快艇到来的数量却并不多，现场看上去一片乱哄哄的景象。工作人员不间断地进行点数、分组操作，每一次仅仅放行十个人上船，其余的人则需要继续等待。这样的一幕忽然让我产生联想，这难道不正是软件系统里面在处理高并发数据时的经典场景吗。

岸边排队就是消息队列

在系统设计当中，当有着大量数据瞬间汹涌而来，而处理能力难以跟上之时，便需要有一个用于临时存放的地方。杨梅坑岸边的阶梯恰似一个消息队列，先来的乘客排列在前方，后来的乘客跟在后面，待快艇到来之际就依照顺序装载人员。这样一种先进先出的方式，确保了大家均能够有序上船，不会出现争抢混乱的状况。

系统里消息中间而起的作用便是如此，它会将生产者发送过来的数据先行存储起来，使得消费者能够依据自身的速度去进行处理，这种采用异步处理的方式，能够使其将瞬间出现的高峰流量予以平滑消除，进而避免整个系统遭受冲击而垮掉，这就如同要是所有的乘客都一窝蜂地挤到码头边上争着往船上挤，那么反而是谁都别想能够顺利地出发。

流量削峰的关键作用

下午四五点的时候，是杨梅坑返程的高峰期，这个时候游客会集中返回，然而快艇的数量却是有限的。要是让所有乘客都直接涌到码头处，那么工作人员根本就管不过来，如此很容易出现安全问题。现在采用的这种分批排队的方式，实际上就是把高峰期分散开来，从而让快艇能够持续运转，不会因为突然到来一大波人而陷入瘫痪状态。

削峰填谷在系统设计当中即为如此，电商大促之际零点立刻涌到的下单恳求 ，支付系统铁定运转不了 ，消息中间件率先将那些央求储存起来，支付系统依照自身的速率缓缓处置 ，这般既确保了用户感受，又不会令后端系统崩溃 ，削峰并非使数据消逝，而是把集中的压力匀摊至更漫长的时间段以内。

ActiveMQ的传统选择

有一个在早期较为流行的消息中间件名为ActiveMQ，它是基于Java语言进行开发的，并且完全达成了JMS规范。它具备一些优点，比如说功能较为全面，文档十分丰富，社区是比较成熟的，许多传统企业的内部系统都在运用它。然而，它存在一个明显的不足之处，也就是吞吐量不够高，单机处理能力是有限的，对于像互联网那种动不动每秒就有几万条消息的场景不太适宜。

假设你所着手欲做的乃是企业内部管理系统，此系统消息量并非庞大之物，对于事务以及可靠性有着超高要求，那么ActiveMQ确是一个较为稳妥的可供选择之物。然而现今在国内众多互联网公司之中其应用已然较少，缘由在于其性能于应对高并发情况之时确实存在一定程度的吃力状况。诸如银行、政府项目这般对于稳定状况倍加器重的场景之中，依旧能够见到它的存在身影。

RocketMQ的阿里实践

RocketMQ是由阿里巴巴开源的消息中间件，它经受住了如双十一那般极端场景的考验，其具备吞吐量极高的特性，单机能够支撑每秒十万级别的消息发送，并且支持分布式部署，能够横向扩展，在像金融支付、电商交易这类需求低延迟和高可靠性的场景当中，RocketMQ展现得颇为出色。

这一款中间件存在的缺点在于，与之对应相关的生态相对来说较为年轻，在海外所拥有的影响力比不上Kafka。然而，它针对事务消息的支持是极为完善的，能够确保在分布式系统当中，多个操作要么均成功，要么均失败。要是你正处于构建大规模的互联网应用的进程当中，特别是涉及到交易链路方面，那么RocketMQ是值得予以重点考虑的一种方案。

RabbitMQ的灵活轻量

RabbitMQ是依据Erlang语言来进行开发的，它是以稳定可靠以及功能丰富而被众人所知的。它对多种消息协议是予以支持的，其路由机制是相当灵活的，能够借助交换机将消息精准无误地投递到不同的队列之中。它部署起来相对而言是比较简便的，仅仅单机便能够运行起来，适宜中小企业去快速搭建消息通信系统。

不能如Kafka以及RocketMQ那般具备高吞吐量量，这是RabbitMQ的局限所在，当海量消息堆积之际其性能会出现下滑状况。倘若每秒的消息量处于几千至一两万的区间范围之内时，它是完全可以胜任工作的。诸如订单处理、异步通知、日志收集这些应用场景，RabbitMQ在其中有着高度广泛的应用。其社区呈现出极为活跃不已的态势，碰上问题之时极易寻觅到解决办法。

Kafka的日志之王

Kafka最初是由LinkedIn进行开发的，随后捐赠给了Apache基金会，它的设计理念跟其他消息中间件并非一样，主打高吞吐量以及持久化存储，Kafka将消息直接写入磁盘进行顺序读写，依靠单机便能支撑每秒几十万的消息吞吐，它生来就是为大数据场景所设计的，在日志收集、流式处理、实时数仓这些领域属于事实标准。

Kafka存在的不足为功能比较单一，对消息确认、事务等高级特性并不支持。它所追求的乃是极致的性能，为此舍弃了一部分易用性。要是你有处理海量日志、打造实时数据管道的需求，Kafka堪称最佳选择。然而要是仅仅是简单的异步通知，选用它就有些过于浪费资源了。

技术选型的实际考量

来讲回到杨梅坑排队这个事，工作人员会依据现场状况来定一次放多少人以及调用多少艘快艇。选消息中间件也是遵循一样的道理，不存在绝对的好与坏，只有适不适合之分。所要考虑的因素涵盖消息量究竟有多大、对延迟敏不敏感、需不需要事务支持以及团队熟悉哪一种技术栈。

假设消息量不大、所处场景简易，那么RabbitMQ便能够满足需求。要是打算构建电商交易系统，RocketMQ会更为契合。倘若要处理日志以及流数据，Kafka当属首选。另外一些场景会将多种中间件搭配运用，各自发挥优势。恰似杨梅坑不但有快艇，并且有观光车，不同工具用以解决各异问题。

实际项目里头，你用的是哪类消息中间件，碰到过啥样的坑，欢迎到评论区那儿，把你的经验给分享出来。