1.介绍

消息队列就是基础数据结构中的 "先进先出" 的一种数据机构。想一下，生活中买东西需要排队，先排队的人先买消费，就是典型的 "先进先出"。

# 扩展
redis: 可以作为简单的消息队列
celery: 本事就是基于消息队列进行的封装。

2.MQ解决了什么问题

MQ是一直存在，不过随着微服务架构的流行，成了解决微服务和微服务之间通信的常用工具。

# 扩展
1.两个服务之间调用的方式:
	1.restful七层协议oss(http协议)
	2.rpc tcp socket层(远程过程调用)
2.不管是使用restful还是rpc，都涉及到使用同步还是异步:
	1.异步: client使用rpc和server交互，client使用异步，不管有没有执行成功，就不停的异步的提交数据，数据在server消息队列排着队，等待着消费。

1.应用的解耦

1.以电商应用为例，应用中有订单系统，库存系统，物流系统，支付系统。用户创建订单后，如果耦合调用库存系统，物流系统，支付系统，任何一个子系统出现了故障，都会造成下单操作异常。
2.当转变成基于队列的方式后，系统间调用的问题会减少很多，比如物流系统因为发生故障，需要几分钟来修复。在这几分钟的时间里，物流系统要处理的内存被缓存在消息队列中，用户的下单操作可以正常完成。当物流系统恢复后，继续处理订单信息即可，订单用户感受不到物流系统的故障。提升系统的可用性。

2.流量削峰

1.举个列子，如果订单系统最多能处理一万次订单，这个处理能力应付正常时段的下单时绰绰有余，正常时段我们下单一秒后就能返回结果。但是在高峰期，如果有两万次下单操作系统是处理不了的，只能限制订单超过一万后不允许用户下单。
2.使用消息队列做缓存，我们可以取消这个限制，把一秒内下的订单分散成一段时间来处理，这时有些用户可能在下单十几秒后才能收到下单成功的操作，但是比不能下单的体验要好。

# 结:
1.通常下比如有两万订单，这时我们server肯定消费不过来，我们将两万丢到消息队列中，进行消费即可。 --- 就叫流量消峰 = 如: 双十一，消息队列 多消费

3.消息分发(发布订阅: 观察者模式)

多个服务对数据感兴趣，只需要监听同一类消息即可处理。

列如A产生数据，B对数据感兴趣。如果没有消息队列A每次处理完需要调用一下B服务。过了一段时间C对数据也感兴趣，A就需要改代码，调用B服务，调用C服务。只要有服务需要，A服务都要改动代码。很不方便。

xxxxxxxxxx 有了消息队列后，A只管发送一次消息，B对消息感兴趣，只需要监听消息。C感兴趣，C也去监听消息。A服务作为基础服务完全不需要有改动。

4.异步消息(celery就是对消息队列的封装)

xxxxxxxxxx 有些服务间调用是异步的:    1.例如A调用B，B需要花费很长时间执行，但是A需要知道B什么时候可以执行完，以前一般有两种方式，A过了一段时间去调用B的查询api是否完成。    2.或者A提供一个callback api，B执行完之后调用api通知A服务。这两种方式都不是很优雅。python

1.使用消息总线，可以很方便解决这个问题，A调用B服务后，只需要监听B处理完成的消息，当B处理完成后，会发送一条消息给MQ，MQ会将此消息转发给A服务。
2.这样A服务既不用循环调用B的查询api，也不用提供callback api。同样B服务也不用做这些操作。A服务还能及时的得到异步处理成功的消息。

3.常见消息队列及比较

xxxxxxxxxx  RabbitMQ: 支持持久化，断电后，重启，数据是不会丢的。    1. 吞吐量小: 几百万都是没问题的，消息确认: 我告诉你，我消费完了，你在删    2.应用场景: 订单，对消息可靠性有要求，就用它     Kafka: 吞吐量高，注重高吞吐量，不注重消息的可靠性    1.你拿走就没了，消费过程崩了，就没了。    2.应用场景，数据量特别大。    # 结论:    1.Kafka在于分布式架构，RabbitMQ基于AMQP协议来实现，RocketMQ/思路来源于Kafka，改成了主从结构，在事务性可靠性方面做了优化。    2.广泛来说，电商，金融等对事物性要求很高的，可以考虑RabbitMQ，对性能要求或吞吐量高的可考虑Kafka。python