AMQP解析1

一、消息中间件
1.介绍
模拟一个场景，我们客户端发送一个下单请求给订单系统，订单系统发送了一个请求给我们的库存系统，告诉它我已经下单了，需要更改库存了。然后将结果返回客户端，下单是否成功。每个请求可以认为是个消息。

这里有个问题，就是用户下订单，必须要经过库存模块的处理，但是订单模块和库存模块应该是相互独立，而不应该在用户下订单时，非要处理完库存结果，才能把用户是否下单成功结果返回。
我们发现，我们发送的这条消息（下订单），是需要同步的（我需要知道下单返回结果）。订单发送给库存的消息，是可以异步的（我不想知道库存到底改了没有，我只是通知你，我这边成功下了一个订单）。
这里利用订单系统起一个线程模式通知库存系统有下单成功消息。

虽然这里，客户端下订单，不用再多等库存处理的10ms。但是这里也有个问题，就是订单系统需要启动线程，需要维护线程池，代码耦合度太高了。
这里利用消息中间件解决订单系统和库存系统的异步消息通知和耦合度问题。

2.使用原因
业务处理过程中，涉及多个系统。系统之间需要：
1.异步通知
2.松耦合
3.使用场景
如上面的下订单，更改库存过程。
二、AMQP

1.介绍

AMQP，即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。Erlang中的实现有 RabbitMQ等。

发现AMQP是应用层的一种消息队列协议。

2.基本概念
1.broker:接受和分发消息的应用，上面说的消息中间件就是它。
2.virual host: 出于多租户和安全因素设计的，把AMQP的基本组件划分到一个虚拟的分组中。当多个不同的用户使用同一个的RabbitMq server 提供的服务时，可以划分出多个vhost,每个用户在自己的vhost创建exchange/queue等。
3.connection: publisher\broker\consumer之间的的tcp连接。断开连接的操作只会在client端进行，broker不会断开连接，除非出现网络故障或broker服务出现问题。
4.channel:是通过connection建立的逻辑连接。每个线程可以创建单独的轻量级的channel进行通讯。
5.exchange:交换机概念，消息从客户端先发送到这里，根据分发规则，匹配查询表中的routing key,分发消息到queue中。常用的类型有：direct(默认：point-to-point),topic(publish-subsribe),fanout(multicast),header四种。
6.queue:消息最终被送到这里等待consumer取走。一个message可以同时拷贝到多个queue.
7.binding:exchange与queue之间的虚拟连接。binding中可以有routing key.binding信息保存在exchange的分发表中，作为分发规则。
其中exchange分发类型：
direct:
这种类型的交换机的路由规则是根据一个routingkey的标识，交换机通过一个routingkey与一个队列绑定，在生产者生产消息的时候，指定一个routingkey。当绑定的队列的routingkey与生产者发送的一样时，那么交换机把这个消息发送给这个队列。
fanout:
这种类型的交换机路由规则很简单，只要与他绑定了的队列， 他就会把消息发送给对应队列（与routingKey没关系）
topic:这种类型的交换机路由规则也是和routingKey有关 只不过 topic他可以根据:*,#（ 星号代表过滤一单词，#代表过滤后面所有单词， 用.隔开）来识别routingKey。
打个比方 假设 我绑定的routingKey 有队列A和B
A的routingKey是：星.user
B的routingKey是: #.user
那么我生产一条消息routingKey 为： error.user 那么此时 2个队列都能接受到，
如果改为 topic.error.user那么这时候 只有B能接受到了
headers:
这个类型的交换机很少用到，他的路由规则 与routingKey无关 而是通过判断header参数来识别的， 基本上没有应用场景，因为上面的三种类型已经能应付了。