当我们在学生时代需要在食堂排队的时候，我们和食堂大妈就是一个同步的模型。
很好 ，你又提出了一个概念，同步通信。就比如现在业界使用比较多的Dubbo就是一个适用于各个系统之间同步通信的RPC框架。
我们看着大妈那颤抖的手和掉落的土豆丝不禁咽了咽口水。这其中我们也就传达了一个消息，我们省略中间的网络通信时间消耗，我们告诉服务员来一碗牛肉面加个荷包蛋(传达一个消息)，比如我们有一个购票系统，然后大妈帮我们打饭配菜，等到我们的牛肉面上了我们就可以吃了。我们工作赚钱了有钱去饭店吃饭了，那后来，而是消息队列为什么会出现？消息队列能用来干什么？用它来干这些事会带来什么好处？消息队列会带来副作用吗？
回想一下，我们在给大妈发送需要的信息之后我们是同步等待大妈给我配好饭菜的，上面我们只是加了鸡腿和土豆丝，万一我再加一个番茄牛腩，韭菜鸡蛋，这样是不是大妈打饭配菜的流程就会变长，我们等待的时间也会相应的变长。
消息队列算是作为后端程序员的一个必备技能吧，因为分布式应用必定涉及到各个系统之间的通信问题，这个时候消息队列也应运而生了。可以说分布式的产生是消息队列的基础，而分布式怕是一个很古老的概念了吧，所以消息队列也是一个很古老的中间件了。
当然，乍看没什么问题。可是仔细一想你就感觉有点问题，我用户购票在购票系统的时候其实就已经完成了购买，而我现在通过同步调用非要让整个请求拉长时间，而短息系统这玩意又不是很有必要，它仅仅是一个辅助功能增强用户体验感而已。我现在整个调用流程就有点头重脚轻的感觉了，购票是一个不太耗时的流程，而我现在因为同步调用，非要等待发送短信这个比较耗时的操作才返回结果。那我如果再加一个发送邮件呢？
我们需要告诉食堂大妈：“姐姐，给我加个鸡腿，再加个酸辣土豆丝，帮我浇点汁上去，多打点饭哦” 咦~~~~~ 为了多吃点，真恶心。
你可能会反驳我，应用之间的通信又不是只能由消息队列解决，好好的通信为什么中间非要插一个消息队列呢？我不能直接进行通信吗？
这样，我们在将消息存入消息队列之后我们就可以直接返回了(我们告诉服务员我们要吃什么然后玩手机)，所以整个耗时只是 150ms + 10ms = 160ms。
但是我们只需要传达一个消息就可以看其他事情了，那么整个处理流程的时间消耗就是 150ms + 200ms = 350ms。短信系统处理需要 200ms ，然后我们又转过头干其他事情了。这其中虽然做面的时间没有变短，需求是用户在购买完之后能接收到购买完成的短信。然后我们就可以在饭桌上安心的玩手机了(干自己其他事情)，所以问题并不是消息队列是什么，假如购票系统处理需要 150ms ，我来举个 吧！这是一个异步的概念。
消息队列顾名思义就是存放消息的队列，队列我就不解释了，别告诉我你连队列都不知道似啥吧？
如果你觉得还行，那么我这个时候不要发邮件这个服务了呢，我是不是又得改代码，又得重启应用？
所以，为了解决这一个问题，聪明的程序员在中间也加了个类似于服务员的中间件——消息队列。这个时候我们就可以把模型给改造了。
那么第二步，我们又添加了一个发送邮件，我们就得重新去修改代码，如果我们又加一个需求：用户购买完还需要给他加积分，这个时候我们是不是又得改代码？
这样改来改去是不是很麻烦