消息是互联网信息的一种表现形式，是人利用计算机进行信息传递的有效载体，比如即时通讯网坛友最熟悉的即时通讯消息就是其具体的表现形式之一。
消息从发送者到接收者的典型传递方式有两种：
1）一种我们可以称为即时消息：即消息从一端发出后（消息发送者）立即就可以达到另一端（消息接收者），这种方式的具体实现就是平时最常见的IM聊天消息；2）另一种称为延迟消息：即消息从某端发出后，首先进入一个容器进行临时存储，当达到某种条件后，再由这个容器发送给另一端。
在上述“消息传递方式2）”中所指的这个容器的一种具体实现就是MQ消息队列服务。
MQ消息队列中间件是中大型分布式系统中重要的组件，它主要用来解决：应用解耦、异步消息、流量削锋等问题，用以实现高性能、高可用、可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等。MQ消息队列中间件已被广泛用于电商、即时通讯、社交等各种中大型分布式应用系统。
在一个典型的IM即时通讯应用中，MQ消息队列可以用于：
1）用户的聊天消息离线存储环节：因为IM消息的发送属于高吞吐场景，直接操纵DB很容易就把DB搞挂了，所以离线消息在落地入库前，可以先扔到MQ消息队列中，再由单独部署的消费者来有节奏地存储到DB中；2）用户的行为数据收集环节：因为用户的聊天消息和指令等，可以用于大数据分析，而且基于国家监管要求也是必须要存储一段时间的，所以此类数据的收集同样可以用于MQ消息队列，再由单独部署的消费者存储到DB中；3）用户的操作日志收集环节：log这种数据价值不高，但关键时刻又非常有用，而且数据量又很大，要想存储起来难度很高，这时就轮到Linkedin公司开源的Kafka出场了；....
因此，对于即时通讯开发者来说，正确地理解MQ消息队列，对于IM或消息推送系统的架构设计、方案选型等都大有裨益。
MQ消息队列目前在中大型分布式系统实际应用中常用的使用场景主要有：异步处理、应用解耦、流量削锋和消息通讯四个场景。
传统的做法有两种：
1）串行的方式：即将注册信息写入数据库成功后、发送注册邮件、再发送注册短信。以上三个任务全部完成后，返回给客户端；2）并行方式：即将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。
假设三个业务节点每个使用50毫秒，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。
因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100）。
小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。
如何解决这个问题呢？答案是：引入消息队列，将不是必须的业务逻辑，异步处理。
按照以上约定，用户的响应时间相当于是注册信息写入数据库的时间，也就是50毫秒。注册邮件，发送短信写入消息队列后，直接返回，因此写入消息队列的速度很快，基本可以忽略，因此用户的响应时间可能是50毫秒。因此架构改变后，系统的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了两倍。
场景说明：一个典型的电商购物系统中，用户下订单后，订单系统需要通知库存系统。即时通讯软件定制开发可以咨询小蓝豆即可
传统模式的缺点：假如库存系统无法访问，则订单减库存将失败，从而导致订单失败，订单系统与库存系统耦合。
如何解决以上问题呢？答案是：引入应用消息队列后的方案。
大致的原理是：
订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功；库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作。
好处就是：假如在下单时库存系统不能正常使用，也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。
