说到消息队列，想必大家都不陌生。无论是学校、面试还是工作，我们都参与了很多。哪里有需求，哪里就有供应。当然，市面上的消息队列很多，主流的也就5、6个，你可能对某个队列比较熟悉，所以一直在用，大概是ArthurJungler，ArthurToplane，Arthurmiddle弄，亚瑟支持。但是你有没有想过引入的队列是不是最合适的呢？它比其他队列有什么优势吗？可以说选型是开发工作中最重要的一环，也是最能干的一环。今天牛牛就给大家介绍一下如何选择消息队列。什么是消息队列？消息队列，顾名思义，就是传输消息的队列，具有先进先出的特点。既然是队列，自然是遵循先进先出的原则。同时，消息队列具有可靠性和高性能的特点。消息队列是大型分布式系统不可或缺的中间件。它们通常用于异步进程、消息分发和流量削减。消息队列可用于实现高性能、高可用性和高可扩展性的体系结构。业界知名的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等。那么大家就会问了，消息队列那么多，我该选谁呢？别着急，下面我们就来深入了解一下消息队列的应用场景以及各个队列的特点。只有了解这些信息，我们才能做出决定。消息队列的应用场景是异步的。如果一个接口处理时间比较长，不能通过水平扩展来解决，就需要异步。那么，在什么情况下不能通过横向扩展来解决呢？还有很多，比如视频处理，涉及到视频下载，受网络带宽等因素限制，扩展没用；例如，在区块链等共识场景中，只有单机才能出块，扩容无用；还有比较常见的，比如一个业务流程，10多个微服务之后，每个个体可能都不长，加起来很难接受。以上情况，用户很难通过同步接口长时间等待结果，所以应该做成异步的，先丢到消息队列，后面再消费，响应时间可以从10秒到10毫秒。2.消息分发假设一个核心服务A用于发布某个信号。发布后需要通知下游服务B和C，这种模式在只有B和C两个兄弟的情况下是没有问题的，但是随着业务的需要，可能会有更多的Worker，比如D，E，和F、此时服务A需要更改代码，将消息传递给这些新加入的兄弟。每增加一个worker，就需要修改一次代码。消息队列的引入可以解决这个问题，实现能力复用和业务解耦。3.调峰业务中有一个概念叫做高峰流量，意思是在一段时间内流量比平时大很多，看起来像一座山峰。比如天猫双11闪购日，尤其是0点，人流量至少是平时的千倍。如果处理不好，服务可以一波完全杀掉。如果1000倍流量的设备一直在手边，那是一种巨大的成本浪费。如果临时部署以扩大服务能力，往往没有想象中那么简单。之前和Shopee的同学聊过，一到活动日他们就得努力扩容。扩容后，他们不得不通宵熬夜做压力测试，不仅付出了生命和金钱，还引发了事故。消息队列可以优雅的解决这个问题，将双十一的请求丢到消息队列中，等待后续服务慢慢处理，如下图。其实从架构上来说，调峰和上面的异步场景是一样的架构，都是把请求丢进队列慢慢消费。但是需要注意的是，异步场景是单个请求，处理时间比较长。削峰针对的是单个请求还可以，但是流量暴增的场景。消息队列能力比较上面提到了几个比较有名的消息队列。其中ZeroMQ过于轻量级，主要用于学习。事实上，它不会应用到生产中。我们将从不同的维度来比较Kafka、ActiveMQ、RabbitMQ、RocketMQ。在选择消息队列模型时，我们需要根据业务场景和以上特点来选择模型。比如要支持天猫双十一等超大秒杀活动，这种一锤子买卖，管理界面和消息回溯都不重要。我们需要看什么？看吞吐量！因此，Kafka和RocketMQ是吞吐量更高的首选。比如说你是一个公司的中台，对外提供能力，可能有很多topic是连在一起的。这时候话题的多少也是一个很重要的考虑因素。像Kafka这样的百级不符合要求。大家可以根据情况考虑。千级的RocketMQ，甚至百万级的RabbitMQ。再比如金融业务，那么重点考虑稳定性和安全性，Kafka和Rocket的分布式部署更有优势。让我们特别谈谈及时性。RabbitMQ以微秒级的时效性作为招牌，但实际上，在大多数情况下，毫秒和微秒之间并没有感知上的区别。除了网络造成的波动外，这是在制作过程中，但不会被视为重要的考虑因素。其他的特性，比如消息确认、消息回溯等，也经常作为场景来考虑。这取决于公司来管理接口。反正妞妞呆过的地方，他们也不太关注这个。毕竟他们有自己的运维体系。最后，牛牛这次给大家分享一下什么是消息队列，解决什么问题，各个队列的特点，以及如何结合场景和特点进行分析。面试的时候可以根据每个场景的不同当地情况选择队列，这样既可以展示知识的全面性，也可以展示分析问题的能力。在实际工作中，我们需要考虑的更多，比如综合分析团队的技术栈，经济成本等。只有熟悉各个消息队列的优缺点，才能择优选择最合适的方案.
