业务背景

#

消息队列是开发过程中的一个中间件，目前在实际的开发中起到了非常关键的作用，下面通过一个场景来说明。 小明在直播平台上发现了一款自己喜欢的游戏机，想要将其买入，查看商品的详情后下了单。这一场景下，可能会出现的问题有：

• 小明的搜索直播和点击点击商品详情的动作信息都需要存储到数据库中，如果说此时机房的数据库发生了故障，那么有可能点击商品详情之后可能就卡在详情页了，回不了之前的界面。
• 由于游戏机的受众面还是比较广的，大量用户会下单购买，此时很多用户同时发出请求，而服务器只能同时处理 10 个订单，那么处理订单的服务可能不知道需要先处理哪一个订单。
• 由于这么多订单的处理总是需要时间的，等到自己的订单被处理完后可能已经过了很久了，下单成功的消息反馈比较慢，用户体验很差。
• 另外在服务端，如果日志出现了问题，那么有些操作可能无法回溯甚至可能影响业务实现。 以上的场景在普通的后端服务来说，都是比较困难且无法避免的问题，此时就需要引入消息队列机制，下面为上面问题的解决方案与其所起到的作用
• 解耦：关于数据库存储的故障问题，使用处于服务与存储之间的消息队列可以起到解耦的作用。

  

• 削峰：中间加一层消息队列，可以让订单有序的进入服务，服务可以依次消费 10 个订单消息并处理

  

• 异步：业务发起到完成处理较多的存储服务，可以在发起订单后加一层消息队列，当订单消息成功进入消息队列时，即可返回下单成功的通知，随后由消息队列发送订单消息让服务处理，异步地执行可以减少用户的等待时间

  

• 日志处理：为防止日志的丢失，可以通过消息队列存储在 ES 搜索引擎中，并使用 Kibana 进行可视化和分析

  

简介

#

消息队列 (MQ)，指保存消息的一个容器，本质是个队列。但这个队列呢，需要支持高吞吐，高并发，并且高可用。

发展历史

#

消息中间件其实诞生的很早，早在 1983 年互联网应用还是一片荒芜的年代，有个在美国的印度小哥 Vivek 就设想了一种通用软件总线，世界上第一个现代消息队列软件 The Information Bus (TIB)， TIB 受到了企业的欢迎，这家公司的业务发展引起了当时最牛 气的 IT 公司 IBM 的注意，于是他们一开始研发了自己消息队列软件，于是才有了后来的 wesphere mq，再后来微软也加入了战团。接近 2000 年的时候，互联网时代已经初见曙光，全球的应用程序得到了极大地丰富，对于程序之间互联互通的需求越来越强烈，但是各大 IT 公司之间还是牢牢建立着各种技术壁垒，以此来保证自己的商业利益，所以消息中间件在那个时候是大型企业才能够用的起的高级玩意。

但是时代的洪流不可逆转，有壁垒就有打破壁垒的后来者，2001 年 sun 发布了 jms 技术，试图在各大厂商的层面上再包装一层统一的 java 规范。java 程序只需要针对 jms api 编程就可以了，不需要再关注使用了什么样的消息中间件，但是 jms 仅仅适用于 java。2004 年 AMQP（高级消息队列协议）诞生了，才是真正促进了消息队列的繁荣发展，任何人都可以针对 AMQP 的标准进行编码。有好的协议指导，再加上互联网分布式应用的迅猛发展成为了消息中间件一飞冲天的最大动力，程序应用的互联互通，发布订阅，最大契合了消息中间件的最初的设计初衷。除了刚才介绍过的收费中间件，后来开源消息中间件开始层出不穷，常见比较流行的有 ActiveMQ、RabbitMQ 、Kafak、阿里的 RocketMQ，以及目前存算分离的 Pulsar，在目前互联网应用中消息队列中间件基本上成为标配。

业界消息队列对比

#