RabbitMQ是什么，不用多介绍了，毕竟名声在那，江湖地位摆着，搜索引擎收录着。为什么突然去学习这个框架了，毕竟工作中没有用得上（说来也惭愧，工作中开发的项目没有使用这个框架）。但是作为互联网分布式应用必不可少的一部分——消息服务，总要补上这块只是空白，不然每次被别人问道消息服务是干嘛的，总是很尴尬的转移到发邮件、短信的服务那块去。更重要的是要有这块知识准备，哪天用户量上来的或者被委以重任，也能够独当一面。
消息服务功能
消息服务能干嘛呢，当然不是仅仅发送个消息那么简单。据我个人知道的一般分布式系统中消息服务的有如下作用
1.服务解耦
我们设计软件时总是提倡单一职责原则，提倡组件之间的低耦合。最低级别的耦合就是仅仅通过数据或者参数关联，那么这里的数据我们可以通过消息服务来传递。也就是说，服务组件之间不知道对方的存在，调用方和被调用方之间是没有依赖关系的。调用方发布一个消息，然后被调用方发现有消息过来然后触发一些列动作。那么这里的灵活性就很大，以及可作的文章就多了。
举个例子，比如常见的用户注册功能，通常注册之后有发送确认邮件，分配权限，上传图片，触发统计等操作。如果不适用消息服务，那么在代码中需要依次实现这一系列动作，如果系统简单这些代码糅合在一起还不算复杂。但是如果这些功能分布在不同系统、服务器，那么得针对不同的功能提供API或者接口。调用方和被调用方都得有一套约定才能进行通讯，而且这套约定还不能重用，只能用于特定的调用。通常不止这几个调用，实际调用关系会更加复杂
（直接调用API）
那么使用消息服务之后，如何去解耦呢？通常消息服务都提供了消息的发布和订阅功能。比如这里的用户注册功能，在用户注册之后发布一个消息，然后其他相关的服务订阅了这个用户注册的消息之后，就会执行各自的动作。用户注册模块只管发布一个消息，其他的不管，更不用关系哪个API和存在哪些下游服务。那么理论上就可以支持很多下游服务。下游服务（邮件服务、权限服务、文件服务等）也不关心消息是谁发送的，只负责处理，也不用提供一个API给上游调用。这样就实现了调用方和被调用方的解耦。
（使用消息服务）
2 负载均衡
互联网应用讲究高性能，高可用，负载均衡技术是被用得最广泛的技术之一。通常做法是提供多个服务器，实现一个集群或者主从备份等。通常实现这种技术要求能通过增加服务的方式，通过简单的线性扩展就能达到增加处理容量的目的。传统的技术需要在客户端或者服务端实现负载均衡的调度算法，而消息服务，比如RabbitMQ则可以借助消息分发的机制实现将消息发送到多个服务群，增加服务只需要服务订阅相关的消息即可，是一种简单灵活的扩展方式。
（消息服务实现的负载均衡）
3 服务异构
现在一个大的应用程序通常有多个不同服务组成，这些服务可能用不同的编程语言和技术实现，可充分利用各种技术的优势，有点类似于微服务。消息服务的解耦功能使得实现技术异构变得容易。由于消息服务实现了AMQP协议，不同语言的实现只要遵循这个协议，就能在不同应用，不同服务器之间实现通讯。这样使得引入新技术变得更加简单，引入新技术实现不担心造成依赖，更不担心对原有应用造成影响。
（通过AMQP实现服务异构）
大概知道这几个主要的功能点，应该说大部分MQ都有的。
RabbitMQ基本概念
接下来了解一下RabbitMQ里面的一些基本概念，便于在正式入坑之前有个大概的印象。
队列(queue)
队列是RabbitMQ种消息的载体，可以理解为存储消息的地方，生产者会把消息发送到队列，然后订阅的该队列的消费者会收到消息。
如果一个队列没有被任何服务订阅，那么消息会一直在队列中直到队列被订阅。
如果一个队列被多个消费者订阅了，那么消息会通过轮询的方式投递给消费者，每个消息只会投递给一个消费者。这个功能就是实现负载均衡的理论基础。
消息投递到消费者之后，都需要消费者确认才能认为投递成功。这个确认包含自动确认和手动确认。自动确认就是说，一旦消费者收到消息就认为投递成功。手动确认，就是需要手动调用确认消息的API。
（队列）
交换(exchanges)与绑定(bindings)
提到队列的时候，上面的描述都好像是生产者直接把消息放到队列，然后消费者从队列拿消息。实际上不是的，他们不直接跟队列打交道，只是知道队列的存在。负责发布和投递消息的是一个中间组件，叫做交换。类似于路由器功能，负责将接收消息和转发消息。
那么具体按照什么规则转发消息？这里的规则叫做路由key。
这个路由key实际上是一种绑定信息，在使用队列的时候，并不是创建个队列就可以了，同时还会创建一个交换器，然后将队列绑定到交换器中。那么在绑定队列的时候，是需要提供一个路由key（可以是一个空白内容）。交换器在发布或者投递信息的时候，就会查找对应的绑定信息，然后根据匹配的路由key，找到对应的队列以及队列的订阅者，从而实现消息发布或者投递。
RabbitMQ提供了四种类型的交换器
direct
按照路由key去匹配消息队列
（引自RabbitMQ in Action)
fanout
发送到交换器的消息，都会发送到绑定的所有队列，类似于广播消息
（引自RabbitMQ in Action)
topic
类似于路由key，但是会提供模糊匹配功能，支持使用一些通配符
（引自RabbitMQ in Action)
headers
使用消息的header去匹配队列
虚拟主机(vhost virtual hosts)
可以理解为RabbitMQ种一个用于隔离不同应用程序的工具，每个vhost有独立的queue,exchange和binding以及权限配置信息。通过vhost可以让不同的应用程序在一个相对安全的环境运行，至少不会导致数据的误删，在逻辑上将数据隔离开，同时也避免了命名冲突。
vhost是默认存在的，默认的vhost是/，不创建的话用的就是这个。vhost作为运行环境的一个很重要的基础部分，我们在使用API时都必须知道要用哪个vhost，并且指明需要连接的vhost，有了vhost才能有queue,exchange和binding。
先整理到这，后续整理一些实际操作的内容。
（待续）
