乐趣区

关于rabbitmq:RabbitMQ学习入门

jiezi

1. 音讯队列

1.1 什么是 MQ

MQ(message queue)，从字面意思上看实质是个队列，FIFO 先入先出，只不过队列中寄存的内容是 message 而已，还是一种跨过程的通信机制，用于上下游传递音讯。在互联网架构中，MQ 是一种十分常见的上下游“逻辑解耦 + 物了解耦”的音讯通信服务。应用了 MQ 之后，音讯发送上游只须要依赖 MQ，不必依赖其余服务。

1.2 为什么要用 MQ

1.2.1 流量消峰

举个例子，如果订单零碎最多能解决一万次订单，这个解决能力应酬失常时段的下单时入不敷出，失常时段咱们下繁多秒后就能返回后果。然而在高峰期，如果有两万次下单操作系统是解决不了的，只能限度订单超过一万后不容许用户下单。应用音讯队列做缓冲，咱们能够勾销这个限度，把一秒内下的订单扩散成一段时间来解决，这时有些用户可能在下单十几秒后能力收到下单胜利的操作，然而比不能下单的体验要好。

1.2.2 利用解耦

以电商利用为例，利用中有订单零碎、库存零碎、物流零碎、领取零碎。用户创立订单后，如果耦合调用库存零碎、物流零碎、领取零碎，任何一个子系统出了故障，都会造成下单操作异样。当转变成基于音讯队列的形式后，零碎间调用的问题会缩小很多，比方物流零碎因为产生故障，须要几分钟来修复。在这几分钟的工夫里，物流零碎要解决的内存被缓存在音讯队列中，用户的下单操作能够失常实现。当物流零碎复原后，持续解决订单信息即可，中单用户感触不到物流零碎的故障，晋升零碎的可用性。

1.2.3 异步解决

有些服务间调用是异步的，例如 A 调用 B，B 须要破费很长时间执行，然而 A 须要晓得 B 什么时候能够执行完，以前个别有两种形式，A 过一段时间去调用 B 的查问 api 查问。或者 A 提供一个 callback api，B 执行完之后调用 api 告诉 A 服务。这两种形式都不是很优雅，应用音讯总线，能够很不便解决这个问题，A 调用 B 服务后，只须要监听 B 解决实现的音讯，当 B 解决实现后，会发送一条音讯给 MQ，MQ 会将此 音讯转发给 A 服务。这样 A 服务既不必循环调用 B 的查问 api，也不必提供 callback api。同样 B 服务也不 用做这些操作。A 服务还能及时的失去异步解决胜利的音讯。

1.3 MQ 分类

1.3.1 ActiveMQ

  • 长处：单机吞吐量万级，时效性 ms 级，可用性高，基于主从架构实现高可用性，音讯可靠性较
  • 毛病：官网社区当初对 ActiveMQ 5.x 保护越来越少，高吞吐量场景较少应用。

1.3.2 Kafka

大数据的杀手锏，谈到大数据畛域内的音讯传输，则绕不开 Kafka，这款为大数据而生的消息中间件，以其百万级 TPS 的吞吐量名声大噪，迅速成为大数据畛域的宠儿，在数据采集、传输、存储的过程中施展着无足轻重的作用。目前曾经被 LinkedIn，Uber, Twitter, Netflix 等大公司所驳回。

  • 长处：性能卓越，单机写入 TPS 约在百万条 / 秒，最大的长处，就是吞吐量高。时效性 ms 级可用性非 常高，kafka 是分布式的，一个数据多个正本，多数机器宕机，不会失落数据，不会导致不可用, 消费者采 用 Pull 形式获取音讯, 音讯有序, 通过管制可能保障所有音讯被生产且仅被生产一次; 有优良的第三方 Kafka Web 治理界面 Kafka-Manager; 在日志畛域比拟成熟，被多家公司和多个开源我的项目应用; 性能反对: 性能较为简单，次要反对简略的 MQ 性能，在大数据畛域的实时计算以及日志采集被大规模应用
  • 毛病：Kafka 单机超过 64 个队列 / 分区，Load 会产生显著的飙高景象，队列越多，load 越高，发送音讯响应工夫变长，应用短轮询形式，实时性取决于轮询间隔时间，生产失败不反对重试; 反对音讯程序，然而一台代理宕机后，就会产生音讯乱序，社区更新较慢;

1.3.3 RocketMQ

RocketMQ 出自阿里巴巴的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了本人的一 些改良。被阿里巴巴广泛应用在订单，交易，充值，流计算，音讯推送，日志流式解决，binglog 散发等场景。

  • 长处：单机吞吐量十万级, 可用性十分高，分布式架构, 音讯能够做到 0 失落,MQ 性能较为欠缺，还是分布式的，扩展性好, 反对 10 亿级别的音讯沉积，不会因为沉积导致性能降落, 源码是 java 咱们能够本人浏览源码，定制本人公司的 MQ
  • 毛病: 反对的客户端语言不多，目前是 java 及 c++，其中 c++ 不成熟; 社区活跃度个别, 没有在 MQ 外围中去实现 JMS 等接口, 有些零碎要迁徙须要批改大量代码

1.3.4 RabbitMQ

2007 年公布，是一个在 AMQP(高级音讯队列协定)根底上实现的，可复用的企业音讯零碎，是以后最支流的消息中间件之一。

  • 长处：因为 erlang 语言的高并发个性，性能较好; 吞吐量到万级，MQ 性能比拟齐备, 强壮、稳固、易 用、跨平台、反对多种语言 如:Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，反对 AJAX 文档齐全; 开源提供的治理界面十分棒，用起来很好用, 社区活跃度高; 更新频率相当高
  • 毛病：商业版须要免费, 学习老本较高

联合 erlang 语言自身的并发劣势，性能好时效性微秒级，社区活跃度也比拟高，治理界面用起来非常不便，如果你的数据量没有那么大，中小型公司优先选择性能比拟齐备的 RabbitMQ。

2. RabbitMQ

2.1 概念

RabbitMQ 是一个消息中间件: 它承受并转发音讯。你能够把它当做一个快递站点，当你要发送一个包裹时，你把你的包裹放到快递站，快递员最终会把你的快递送到收件人那里，依照这种逻辑 RabbitMQ 是 一个快递站，一个快递员帮你传递快件。RabbitMQ 与快递站的次要区别在于，它不解决快件而是接管，存储和转发音讯数据。

生产者——交换机——队列——消费者

2.1.1 生产者

产生数据发送音讯的程序是生产者

2.1.2 交换机

交换机是 RabbitMQ 十分重要的一个部件，一方面它接管来自生产者的音讯，另一方面它将音讯推送到队列中。交换机必须确切晓得如何解决它接管到的音讯，是将这些音讯推送到特定队列还是推送到多个队列，亦或者是把音讯抛弃，这个得有交换机类型决定

2.1.3 队列

队列是 RabbitMQ 外部应用的一种数据结构，只管音讯流经 RabbitMQ 和应用程序，但它们只能存储在队列中。队列仅受主机的内存和磁盘限度的束缚，实质上是一个大的音讯缓冲区。许多生产者能够将音讯发送到一个队列，许多消费者能够尝试从一个队列接收数据。这就是咱们应用队列的形式

2.1.4 消费者

生产与接管具备类似的含意。消费者大多时候是一个期待接管音讯的程序。请留神生产者，生产 者和消息中间件很多时候并不在同一机器上。同一个应用程序既能够是生产者又是能够是消费者。

2.2 原理

  • Broker:

    接管和散发音讯的利用，RabbitMQ Server 就是 Message Broker

  • Virtual host:

    出于多租户和平安因素设计的，把 AMQP 的根本组件划分到一个虚构的分组中，相似于网络中的 namespace 概念。当多个不同的用户应用同一个 RabbitMQ server 提供的服务时，能够划分出 多个 vhost，每个用户在本人的 vhost 创立 exchange/queue 等

  • Connection:

    publisher/consumer 和 broker 之间的 TCP 连贯

  • Channel:

    如果每一次拜访 RabbitMQ 都建设一个 Connection，在音讯量大的时候建设 TCP Connection 的开销将是微小的，效率也较低。Channel 是在 connection 外部建设的逻辑连贯，如果利用程 序反对多线程，通常每个 thread 创立独自的 channel 进行通信，AMQP method 蕴含了 channel id 帮忙客 户端和 message broker 辨认 channel，所以 channel 之间是齐全隔离的。Channel 作为轻量级的Connection 极大缩小了操作系统建设 TCP connection 的开销

  • Exchange:

    message 达到 broker 的第一站，依据散发规定，匹配查问表中的 routing key，散发音讯到 queue 中去。罕用的类型有:direct (point-to-point), topic (publish-subscribe) and fanout(multicast)

  • Queue:

    音讯最终被送到这里期待 consumer 取走

  • Binding:

    exchange 和 queue 之间的虚构连贯，binding 中能够蕴含 routing key，Binding 信息被保 存到 exchange 中的查问表中，用于 message 的散发根据

2.3 模式分类

2.4 装置应用 RabbitMQ

下载安装 erlang

因为 RabbitMQ 应用 erlang 语言编写的，所以咱们须要下载 erlang

  1. 下载 erlang 的压缩包文件https://erlang.org/download/otp_src_22.1.tar.gz

  2. 解压到对应目录

    tar -xvf otp_src_20.3.tar.gz

  3. 配置零碎环境

    yum -y install make gcc gcc-c++ kernel-devel m4 ncurses-devel openssl-devel
  4. 进入解压后的 otp_src_20.3 根目录

  5. 配置装置变量

    ./configure --prefix=/usr/local/erlang --with-ssl --enable-threads --enable-smp-support --enable-kernel-poll --enable-hipe --without-javac

  6. 装置

    make && make install

  7. 编写 /etc/profile 文件，配置环境变量

    #set erlang environment
ERL_PATH=/usr/local/erlang/bin
PATH=$ERL_PATH:$PATH

  8. 使配置文件失效

    source /etc/profile

  9. 测验是否装置胜利

    [[email protected] otp_src_22.1]# erl
Erlang/OTP 22 [erts-10.5]  [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:1] [hipe]

Eshell V10.5  (abort with ^G)
退出移动版