队列，是一种先进先出的数据结构，由于其有一定的容量，可以暂存一定的数据，作为临时缓冲，是在消息传递过程中，暂存消息的容器。
由于内存的读写速度大大高于硬盘，硬盘的读写速度成为现代大数据量高并发模式下的瓶颈。而数据的访问往往遵循二八定律：80%的业务访问集中在20%的数据上，于是将这20%常用的数据写入内存（缓存）可以大大改善程序的运行速度。
消息队列（MQ，Message Queue）类似思想，把对数据库的读写转移到消息队列服务器，大大增加读写速度。消息队列的主要应用场景为：异步处理 和 应用解耦。
例如某电商某时间点促销秒杀，那么此时间段，会突然产生大量订单，在大数据量高并发的环境中，由于订单需要扣减库存，就会访问数据库，那么在系统访问数据库的速度远远赶不上用户下单的速度，数据无限堆积，来不及处理，造成服务器崩溃。在这种情况下，引入MQ可以解决此问题。
- 异步处理
同步情况下【如下图】：用户发出一个请求（下一个订单），要等待订单程序访问数据库扣减库存成功后，用户才能得到响应，在大量订单的情况下，数据库来不及处理，假设你前面已经有一万个订单在排队，每个订单处理需要0.02秒，那么一万个订单就是200秒，这个等待时间显然是不能承受的。
引入MQ的异步情况下【如下图】：用户下订单后（下单之前一般会查询库存量是否>=购买量），直接返回下单成功，不做扣减库存的处理，而是将订单消息放入MQ储存起来，用户作为生产者，队列的另一端有异步程序在消费（即扣减库存），所以我们一般情况下会在购买东西之后几秒或者几分钟收到购买成功的短信，这个短信发送就是异步处理的。这样处理后，用户无需等待与自己无关的处理即可直接得到响应，让真正的操作在队列后台中默默的进行。
- 应用解耦
还以订单为例，将创建订单与扣减库存两块业务解耦。在未解耦情况下，用户创建订单后，必须要扣减库存成功，才能下单成功，但如果扣减库存代码因为某些原因导致扣减失败，就会直接导致下单操作失败，这是平台的问题，与用户无关，不应将错误抛给用户。引入MQ后，将订单业务与扣减库存业务分离，在扣减库存之前，就把下单成功的消息返回给用户，即使后续扣减库存失败了，也会在用户不知情的情况下偷偷的解决。
注意：在实际情况中，使用异步处理后，下单返回的消息可以是正在处理中等，一般不会直接将成功返回给用户，因为后续修改数据库等操作可能出现失败。所以会在所有的真正操作处理完成后，给用户发送一个下单成功的短信或邮件，避免纠纷。