消息队列其实是个中间件。
消息队列的作用：
1.解耦。
中间件嘛，a和b本来直接关联，现在多了个中间件c,通过c来关联，那不就是不直接联系了吗？那不就是解耦了吗？
2.异步，削峰/限流
就是不同一时间做某个事情嘛，把做事情拆分步骤。
这样是不是，就不会阻碍在某个人要筷子，还筷子环节。
那使用消息队列不就是一个队列吗，直接写一个队列不就完了？
当然不是。消息队列要考虑很多问题，比如说高可用性，数据丢失问题。
如果是单机的消息队列，万一这台机器挂了，那我们整个系统几乎就是不可用了。
所以，当我们项目中使用消息队列，都是得集群/分布式的。要做集群/分布式就必然希望该消息队列能够提供现成的支持，而不是自己写代码手动去实现。
我们将数据写到消息队列上，系统B和C还没来得及取消息队列的数据，就挂掉了。如果没有做任何的措施，我们的数据就丢了。
学过Redis的都知道，Redis可以将数据持久化磁盘上，万一Redis挂了，还能从磁盘从将数据恢复过来。同样地，消息队列中的数据也需要存在别的地方，这样才尽可能减少数据的丢失。
那存在哪呢？
- 磁盘？
- 数据库？
- Redis？
- 分布式文件系统？
同步存储还是异步存储？
3.3消费者怎么得到消息队列的数据？
消费者怎么从消息队列里边得到数据？有两种办法：
- 生产者将数据放到消息队列中，消息队列有数据了，主动叫消费者去拿(俗称push)
- 消费者不断去轮训消息队列，看看有没有新的数据，如果有就消费(俗称pull)
除了这些，我们在使用的时候还得考虑各种的问题：
- 消息重复消费了怎么办啊？
- 我想保证消息是绝对有顺序的怎么做？
- ……..
虽然消息队列给我们带来了那么多的好处，但同时我们发现引入消息队列也会提高系统的复杂性。市面上现在已经有不少消息队列轮子了，每种消息队列都有自己的特点，选取哪种MQ还得好好斟酌。
所以说各种消息队列的框架就出来的，但不同框架的侧重点不一样。
所以说，我也不知道，我也没用过。拜，再会。
