消息队列（MQ(Message Queue)）

消息队列其实是个中间件。

消息队列的作用：

1.解耦。

中间件嘛，a和b本来直接关联，现在多了个中间件c,通过c来关联，那不就是不直接联系了吗？那不就是解耦了吗？

2.异步，削峰/限流

就是不同一时间做某个事情嘛，把做事情拆分步骤。

这样是不是，就不会阻碍在某个人要筷子，还筷子环节。

那使用消息队列不就是一个队列吗，直接写一个队列不就完了？

当然不是。消息队列要考虑很多问题，比如说高可用性，数据丢失问题。

如果是单机的消息队列，万一这台机器挂了，那我们整个系统几乎就是不可用了。

所以，当我们项目中使用消息队列，都是得集群/分布式的。要做集群/分布式就必然希望该消息队列能够提供现成的支持，而不是自己写代码手动去实现。

我们将数据写到消息队列上，系统B和C还没来得及取消息队列的数据，就挂掉了。如果没有做任何的措施，我们的数据就丢了。

学过Redis的都知道，Redis可以将数据持久化磁盘上，万一Redis挂了，还能从磁盘从将数据恢复过来。同样地，消息队列中的数据也需要存在别的地方，这样才尽可能减少数据的丢失。

那存在哪呢？

•  磁盘？
•  数据库？
•  Redis？
•  分布式文件系统？

同步存储还是异步存储？

3.3消费者怎么得到消息队列的数据？

消费者怎么从消息队列里边得到数据？有两种办法：

•  生产者将数据放到消息队列中，消息队列有数据了，主动叫消费者去拿(俗称push)
•  消费者不断去轮训消息队列，看看有没有新的数据，如果有就消费(俗称pull)

除了这些，我们在使用的时候还得考虑各种的问题：

•  消息重复消费了怎么办啊？
•  我想保证消息是绝对有顺序的怎么做？
•  ……..

虽然消息队列给我们带来了那么多的好处，但同时我们发现引入消息队列也会提高系统的复杂性。市面上现在已经有不少消息队列轮子了，每种消息队列都有自己的特点，选取哪种MQ还得好好斟酌。

所以说各种消息队列的框架就出来的，但不同框架的侧重点不一样。

所以说，我也不知道，我也没用过。拜，再会。