RabbitMQ 上手记录-part 1-基础概念

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。

 

 

先整理到这，后续整理一些实际操做的内容。

 

（待续）