zoukankan      html  css  js  c++  java
  • RabbitMQ 上手记录part 1基础概念

    RabbitMQ是什么,不用多介绍了,毕竟名声在那,江湖地位摆着,搜索引擎收录着。为什么突然去学习这个框架了,毕竟工作中没有用得上(说来也惭愧,工作中开发的项目没有使用这个框架)。但是作为互联网分布式应用必不可少的一部分——消息服务,总要补上这块只是空白,不然每次被别人问道消息服务是干嘛的,总是很尴尬的转移到发邮件、短信的服务那块去。更重要的是要有这块知识准备,哪天用户量上来的或者被委以重任,也能够独当一面。

    消息服务功能

    消息服务能干嘛呢,当然不是仅仅发送个消息那么简单。据我个人知道的一般分布式系统中消息服务的有如下作用

    1.服务解耦

    我们设计软件时总是提倡单一职责原则,提倡组件之间的低耦合。最低级别的耦合就是仅仅通过数据或者参数关联,那么这里的数据我们可以通过消息服务来传递。也就是说,服务组件之间不知道对方的存在,调用方和被调用方之间是没有依赖关系的。调用方发布一个消息,然后被调用方发现有消息过来然后触发一些列动作。那么这里的灵活性就很大,以及可作的文章就多了。

    举个例子,比如常见的用户注册功能,通常注册之后有发送确认邮件,分配权限,上传图片,触发统计等操作。如果不适用消息服务,那么在代码中需要依次实现这一系列动作,如果系统简单这些代码糅合在一起还不算复杂。但是如果这些功能分布在不同系统、服务器,那么得针对不同的功能提供API或者接口。调用方和被调用方都得有一套约定才能进行通讯,而且这套约定还不能重用,只能用于特定的调用。通常不止这几个调用,实际调用关系会更加复杂

    image(直接调用API)

    那么使用消息服务之后,如何去解耦呢?通常消息服务都提供了消息的发布和订阅功能。比如这里的用户注册功能,在用户注册之后发布一个消息,然后其他相关的服务订阅了这个用户注册的消息之后,就会执行各自的动作。用户注册模块只管发布一个消息,其他的不管,更不用关系哪个API和存在哪些下游服务。那么理论上就可以支持很多下游服务。下游服务(邮件服务、权限服务、文件服务等)也不关心消息是谁发送的,只负责处理,也不用提供一个API给上游调用。这样就实现了调用方和被调用方的解耦。

    image(使用消息服务)

    2 负载均衡

    互联网应用讲究高性能,高可用,负载均衡技术是被用得最广泛的技术之一。通常做法是提供多个服务器,实现一个集群或者主从备份等。通常实现这种技术要求能通过增加服务的方式,通过简单的线性扩展就能达到增加处理容量的目的。传统的技术需要在客户端或者服务端实现负载均衡的调度算法,而消息服务,比如RabbitMQ则可以借助消息分发的机制实现将消息发送到多个服务群,增加服务只需要服务订阅相关的消息即可,是一种简单灵活的扩展方式。

    image(消息服务实现的负载均衡)

    3 服务异构

    现在一个大的应用程序通常有多个不同服务组成,这些服务可能用不同的编程语言和技术实现,可充分利用各种技术的优势,有点类似于微服务。消息服务的解耦功能使得实现技术异构变得容易。由于消息服务实现了AMQP协议,不同语言的实现只要遵循这个协议,就能在不同应用,不同服务器之间实现通讯。这样使得引入新技术变得更加简单,引入新技术实现不担心造成依赖,更不担心对原有应用造成影响。

    image(通过AMQP实现服务异构)

    大概知道这几个主要的功能点,应该说大部分MQ都有的。

    RabbitMQ基本概念

    接下来了解一下RabbitMQ里面的一些基本概念,便于在正式入坑之前有个大概的印象。

    队列(queue)

    队列是RabbitMQ种消息的载体,可以理解为存储消息的地方,生产者会把消息发送到队列,然后订阅的该队列的消费者会收到消息。

    如果一个队列没有被任何服务订阅,那么消息会一直在队列中直到队列被订阅。

    如果一个队列被多个消费者订阅了,那么消息会通过轮询的方式投递给消费者,每个消息只会投递给一个消费者。这个功能就是实现负载均衡的理论基础。

    消息投递到消费者之后,都需要消费者确认才能认为投递成功。这个确认包含自动确认和手动确认。自动确认就是说,一旦消费者收到消息就认为投递成功。手动确认,就是需要手动调用确认消息的API。

    image(队列)

    交换(exchanges)与绑定(bindings)

    提到队列的时候,上面的描述都好像是生产者直接把消息放到队列,然后消费者从队列拿消息。实际上不是的,他们不直接跟队列打交道,只是知道队列的存在。负责发布和投递消息的是一个中间组件,叫做交换。类似于路由器功能,负责将接收消息和转发消息。

    那么具体按照什么规则转发消息?这里的规则叫做路由key

    这个路由key实际上是一种绑定信息,在使用队列的时候,并不是创建个队列就可以了,同时还会创建一个交换器,然后将队列绑定到交换器中。那么在绑定队列的时候,是需要提供一个路由key(可以是一个空白内容)。交换器在发布或者投递信息的时候,就会查找对应的绑定信息,然后根据匹配的路由key,找到对应的队列以及队列的订阅者,从而实现消息发布或者投递。

    RabbitMQ提供了四种类型的交换器

    direct

    按照路由key去匹配消息队列

    image(引自RabbitMQ in Action)

    fanout

    发送到交换器的消息,都会发送到绑定的所有队列,类似于广播消息

    image(引自RabbitMQ in Action)

    topic

    类似于路由key,但是会提供模糊匹配功能,支持使用一些通配符

    image(引自RabbitMQ in Action)

    headers

    使用消息的header去匹配队列

    虚拟主机(vhost virtual hosts)

    可以理解为RabbitMQ种一个用于隔离不同应用程序的工具,每个vhost有独立的queue,exchange和binding以及权限配置信息。通过vhost可以让不同的应用程序在一个相对安全的环境运行,至少不会导致数据的误删,在逻辑上将数据隔离开,同时也避免了命名冲突。

    vhost是默认存在的,默认的vhost是/,不创建的话用的就是这个。vhost作为运行环境的一个很重要的基础部分,我们在使用API时都必须知道要用哪个vhost,并且指明需要连接的vhost,有了vhost才能有queue,exchange和binding。

    image

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

    (待续)

  • 相关阅读:
    HDU 5744
    HDU 5815
    POJ 1269
    HDU 5742
    HDU 4609
    fzu 1150 Farmer Bill's Problem
    fzu 1002 HangOver
    fzu 1001 Duplicate Pair
    fzu 1150 Farmer Bill's Problem
    fzu 1182 Argus 优先队列
  • 原文地址:https://www.cnblogs.com/lzjsky/p/15769653.html
Copyright © 2011-2022 走看看