案例 1

有一天，产品跑来说：“我们要做一个用户注册功能，需要在用户注册成功后给用户发一封成功邮件。”

小明（攻城狮）：“好，需求很明确了。” 不就提供一个注册接口，保存用户信息，同时发起邮件调用，待邮件发送成功后，返回用户操作成功。没一会功夫，代码就写完了。验证功能没问题后，就发布上线了。

线上正常运行了一段时间，产品匆匆地跑来说：“你做的功能不行啊，运营反馈注册操作响应太慢，已经有好多用户流失了。”

小明听得一身冷汗，赶紧回去改。他发现，原先的以单线程同步阻塞的方式进行邮件发送，确实存在问题。这次，他利用了 JAVA 多线程的特性，另起线程进行邮件发送，主线程直接返回保存结果。测试通过后，赶紧发布上线。小明心想，这下总没问题了吧。

没过多久，产品又跑来了，他说：“现在，注册操作响应是快多了。但是又有新的问题了，有用户反应，邮件收不到。能否在发送邮件时，保存一下发送的结果，对于发送失败的，进行补发。”

小明一听，哎，又得熬夜加班了。产品看他一脸苦逼的样子，忙说：“邮件服务这块，别的团队都已经做好了，你不用再自己搞了，直接用他们的服务。”

小明赶紧去和邮件团队沟通，谁知他们的服务根本就不对外开放。这下小明可开始犯愁了，明知道有这么一个服务，可是偏偏又调用不了。

邮件团队的人说，“看你愁的，我给你提供了一个类似邮局信箱的东西，你往这信箱里写上你要发送的消息，以及我们约定的地址。之后你就不用再操心了，我们自然能从约定的地址中取得消息，进行邮件的相应操作。”

后来，小明才知道，这就是外界广为流传的消息队列。你不用知道具体的服务在哪，如何调用。你要做的只是将该发送的消息，向你们约定好的地址进行发送，你的任务就完成了。对应的服务自然能监听到你发送的消息，进行后续的操作。这就是消息队列最大的特点，将同步操作转为异步处理，将多服务共同操作转为职责单一的单服务操作，做到了服务间的解耦。

哈哈，这下能高枕无忧了。太年轻，哪有万无一失的技术啊~

不久的一天，你会发现所有业务都替换了邮件发送的方式，统一使用了消息队列来进行发送。这下仅仅一个邮件服务模块，难以承受业务方源源不断的消息，大量的消息堆积在了队列中。这就需要更多的消费者（邮件服务）来共同处理队列中的消息，即所谓的分布式消息处理。

未完待续。。。

总结

定义

有了上面的基础，再看非常官方的解释应该也能理解了。

消息队列（英语：Message queue）是一种进程间通信或同一进程的不同线程间的通信方式，软件的贮列用来处理一系列的输入，通常是来自用户。消息队列提供了异步的通信协议，每一个贮列中的纪录包含详细说明的数据，包含发生的时间，输入设备的种类，以及特定的输入参数，也就是说：消息的发送者和接收者不需要同时与消息队列互交。消息会保存在队列中，直到接收者取回它。 ——维基百科

名词解释

解释还是太官方了，我们来看一个最简单的架构模型：

• Producer：消息生产者，负责产生和发送消息到 Broker；
• Broker：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue；
• Consumer：消息消费者，负责从 Broker 中获取消息，并进行相应处理；

特性

异步性

将耗时的同步操作，通过以发送消息的方式，进行了异步化处理。减少了同步等待的时间。

松耦合

消息队列减少了服务之间的耦合性，不同的服务可以通过消息队列进行通信，而不用关心彼此的实现细节，只要定义好消息的格式就行。

分布式

通过对消费者的横向扩展，降低了消息队列阻塞的风险，以及单个消费者产生单点故障的可能性（当然消息队列本身也可以做成分布式集群）。

可靠性

消息队列一般会把接收到的消息存储到本地硬盘上（当消息被处理完之后，存储信息根据不同的消息队列实现，有可能将其删除），这样即使应用挂掉或者消息队列本身挂掉，消息也能够重新加载

 

案例 2

Java 帝国的张家村正在迎来一次重大的变革。

5年前网上购物兴起的时候， 帝国非常看好， 决定向这个领域进军， 于是兴建了张家村， 在这里安装了Java 虚拟机和数据库， 然后部署了一个基于Web的订单系统和一个库存系统， 由张家村的人负责操作。

张家村的老村长很清楚， 说是两个系统， 其实是逻辑上的一种划分方式，  在物理上两个系统还是部署在一个虚拟机中。  那个时候用户量少， 数据量也不大， 村民们只要使用这一个Java 虚拟机和数据库就足够了。

订单和库存系统运转一直很好， 用户的订单来了， 会在订单系统中存下来， 然后通知库存系统发货。

你要问怎么通知？  老村长会告诉你说：  其实简单的很， 就是普通Java 方法的直接调用， 调用库存系统某个类的某个方法而已。  由于在同一个虚拟机之内， 效率极高 。

转眼间5年过去了， 人类变得越来越懒， 越来越喜欢网上购物，  用户量和数据量暴增， 再加上他们时不时搞个什么秒杀活动， 更是让张家村变得不堪重负。  为了应付汹涌而来的订单， 张家村经常彻夜灯火通明， 全村人三班倒才能勉强应付。

老村长向镇上报告了很多次都没有回音， 要不是帝国的性能监控部门发现了这个异常，还不知道要被瞒到什么时候。

还好，钦差王大人来了， 变革要开始了。

王大人经验丰富， 目光如炬， 一眼就看出了问题， 立刻下达了第一道命令： 拆分 ！ 把订单系统和库存系统分开！

老村长说： “那拆开了以后，我们村还是放不下啊”

王大人道： “订单系统还是留在张家村， 库存系统挪到李家庄去”

老村长暗自思忖，订单系统是直接面向用户的，很重要， 张家村一定要保住， 至于库存系统，主要是后台操作，挪走就挪走吧， 于是就答应了。

拆分不是那么容易的， 订单和库存耦合的比较紧密， 现在要把库存系统搬到李家庄的Java虚拟机和数据库去，免不了一番剧烈的折腾。

在王大人的指导下， 原先那些直接的Java 方法调用，也被改成了Web 服务 -- 张家村和李家庄虽然距离较远 ， 还是有网络相通的。  

 现在用户下了订单以后， 先在张家村保存， 然后由张家村调用李家庄的Web服务来通知库存系统。

数据库自然也做了拆分， 老的库存数据被导出来， 再导入到李家庄的新数据库中 。

不管过程是多么艰难， 两个系统还是分了家，李家庄喜气洋洋、敲锣打鼓的迎接了库存系统的部署， 开始了试运营。

 

由于只需要处理订单， 张家村的负载一下子降了下来， 恢复了正常的作息。

可是好景不长，张家村很快发现李家庄对新系统根本不上心， 派了一个酒鬼小李去负责操作库存Web服务， 小李喝醉了啥都忘了，  Web服务经常用不了。

 

这还不算，李家庄是严格的日出而作， 日落而息， 张家村正在繁忙的处理订单的时候， 李家庄已经把系统关了，睡觉去了。

 

这可苦了张家村的小张，用户提交了订单， 去调用Web服务通知库存发货， 可是Web服务经常不响应， 小张没有办法， 只好反复重试、等待一段时间后再试，导致一个订单很长时间才能完成， 用户体验极差， 大家怨声载道。

 

小张向李家庄投诉了很多次都不管用，没人搭理，跨村庄协作可真是难啊！

 

小张活干的不好，工分减少，  再这么下去，月底分粮的时候又要饿肚子了，小张想起来了自己经历过的《Java帝国之拨云见日识回调 》， 心里再次哀叹： 为什么受伤的总是我？  

 

晚上到家，小张苦思悯想：  原来订单系统和库存系统都在一个虚拟机中，  处理起来很方便， 但是现在是个远程的Web服务， 酒鬼小李不给我返回结果， 我就没法结束， 这是典型的同步操作， 能不能改成异步的呢？  

 

我把一个订单包裹发给小李， 他什么时候处理我就不用管了， 这样我这边的效率就会大大的提高！   可是现在的Web服务并不支持这种方式， 我怎么才能把包裹发过去呢？

小张彻夜未眠， 第二天一大早就去请教老村长。

 

村长说： “你能想到这一层，非常不错！  近来我也一直在考虑这个问题啊， 在大型的分布式系统中，怎么做异步通信是个大问题， 我想到了一个叫消息队列的东西”

 

“消息队列？ 没有听说过”

 

“就拿你遇到的情况来说吧， 我们开发一个消息队列，名称我都想好了，就叫ZhangMQ(Zhang Message Queue),   把它部署在我们张家村和李家庄之间， 我们村产生的订单， 你只要负责把订单消息写到这个队列里就完事大吉了。 ”

 

“奥，李家庄的酒鬼小李醒了，就让他从这个消息队列中读取消息，进行处理，对吧”

 

“没错，这不就变成异步的了？ 酒鬼小李不处理， 那就是他们的责任了”

 

"那订单消息的格式需要和李家庄商量好， 另外次序也不能乱掉， 还有, 要是断电了或者重启了，消息队列中的订单消息也不能丢失 "  小张想的很深入

 

“没错，这些都是我们的ZhangMQ要考虑的，要实现持久化， 把订单消息存到硬盘上”

 

“这真是不错“  小张跃跃欲试    ”村长，我想去开发这个ZhangMQ， 一定要让我参加啊“

 

”没问题， 不过我当前最重要的是说服李家庄， 让他们来采用我们的消息队列“

 

 

经过据理力争和艰难协商，李家庄终于同意了消息队列的方案，毕竟对他们也没啥损失， 也不用听张家村没完没了的投诉了，只需要改一点点代码，从消息队列中读取订单即可。

小张和其他人在家里埋头开发ZhangMQ， 半年后，ZhangMQ正式上线，  彻底解决了异步通信的问题。

前钦差王大人对张家村做了回访，发现了消息队列，赞不绝口，回去后就发来了褒奖令，还下令在帝国推广， ZhangMQ一下子出名了！