RabbitMQ

usernamehui

已于 2022-03-17 20:30:12 修改

阅读量246

点赞数 1

文章标签： rabbitmq 网络 java

于 2020-06-12 23:09:51 首次发布

本文链接：https://blog.csdn.net/usernamehui/article/details/106239673

版权

简介
RabbitMQ是一个AMQP的开源实现，由以高性能、可伸缩性出名的Erlang写成。RabbitMQ Server适用的OS有：Windows、Linux/Unix和Mac OS X，RabbitMQ官方的Client有Java、.Net/C#和Erlang。

1.基本概念
   Message
       消息，消息是不具名的，它由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等。
   Publisher
       消息的生产者，也是一个向交换器发布消息的客户端应用程序。
   Exchange
       交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。
   Binding
       绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。
   Queue
       消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。
   Connection
       网络连接，比如一个TCP连接。
   Channel
       信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内地虚拟连接，AMQP 命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销，所以引入了信道的概念，以复用一条 TCP 连接。
   Consumer
       消息的消费者，表示一个从消息队列中取得消息的客户端应用程序。
   Virtual Host
       虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器，拥有自己的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础，必须在连接时指定，RabbitMQ 默认的 vhost 是 / 。
   Broker
       表示消息队列服务器实体。

2. Exchange 类型
   direct：
       处理路由键，需要将一个队列绑定到交换机上，要求该消息与一个特定的路由键完全匹配。这是一个完整的匹配。
   topic:
       将路由键和某模式进行匹配。此时队列需要绑定一个模式上。符号“#”匹配一个或多个词，符号“*”只能匹配一个词。
   fanout
       不处理路由键。发送到该交换机上的消息会被广播到与该交换机绑定的所有队列上。
   headers
       不处理路由键，而是根据发送的消息内容中的headers属性进行匹配。在绑定Queue与Exchange时指定一组键值对；
       当消息发送到RabbitMQ时会取到该消息的headers与Exchange绑定时指定的键值对进行匹配；
       如果完全匹配则消息会路由到该队列，否则不会路由到该队列。headers属性是一个键值对，可以是Hashtable，键值对的值可以是任何类型。
       而fanout，direct，topic 的路由键都需要要字符串形式的

3.常见问题
   1).RabbitMQ消息重复消费问题
       可以消费端消费时，利用redis加一个消费标志，如果消费过了就不继续
   2).RabbitMQ消息丢失问题
       a.生产者发送消息时，使用confirm机制
       b.broker端设置消息时持久化，设置持久化有两个步骤，第一个是创建queue的时候将其设置为持久化的，这样就可以保证rabbitmq持久化queue的元数据，但是不会持久化queue里的数据；第二个是发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化的，此时rabbitmq就会将消息持久化到磁盘上去。必须要同时设置这两个持久化才行，rabbitmq哪怕是挂了，再次重启，也会从磁盘上重启恢复queue，恢复这个queue里的数据。
       c.消费端用rabbitmq提供的ack机制，关闭rabbitmq自动ack
   3.RabbitMQ消息顺序问题
       将需要顺序的消息，写到同一个queue里，然后单独指定一个消费者消费这个queue
   4.RabbitMQ消息积压问题
       如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概1小时的时间才能恢复过来一般这个时候，只能操作临时紧急扩容了，具体操作步骤和思路如下：
       1）先修复consumer的问题，确保其恢复消费速度，然后将现有cnosumer都停掉
       2）新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量
       3）然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue
       4）接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据
       5）这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据
       6）等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息

4.与其他消息队列的区别

   (1)RabbitMQ是一个AMQP的开源实现，由以高性能、可伸缩性出名的Erlang写成。RabbitMQ Server适用的OS有：Windows、Linux/Unix和Mac OS X，RabbitMQ官方的Client有Java、.Net/C#和Erlang。
       AMQP协议主要有3个组件：
       交换器（Exchange）：它是发送消息的实体
       队列（Queue）：它是接收消息的实体
       绑定器（Bind）：将交换器和队列连接起来，并且封装消息的路由信息

   (2)ActiveMQ是一个完全支持JMS 1.1和J2EE 1.4规范的JMS Provider实现。JMS（Java Messaging Service）是Java平台上有关面向消息中间件的技术规范，它便于消息系统中的Java应用程序进行消息交换，并且通过提供标准的产生、发送、接收消息的接口简化企业应用的开发。
       JMS消息通常有两种类型：
       点对点（Point-to-Point）：在点对点的消息系统中，消息分发给一个单独的使用者，点对点消息往往与队列相关联。
       发布/订阅（Publish/Subscribe）：发布/订阅消息系统支持一个事件驱动模型，消息生产者和消费者都参与消息的传递。该类消息一般与特定的主题关联。

   (3)Kafka是一种分布式的，基于发布/订阅的消息系统。Kafka开发语言为Scala，支持跨平台。其设计主要目标如下：
       以时间复杂度为O(1)的方式提供消息持久化能力
       高吞吐率
       支持Kafka Server间的消息分区，及分布式消费，同时保证消息顺序传输
       支持离线数据处理和实时数据处理
       支持在线水平扩展

       更快！单机上万TPS
       传统的MQ，消息被消化掉后会被mq删除，而kafka中消息被消化后不会被删除，而是到配置的expire时间后，才删除
       传统的MQ，消息的Offset是由MQ维护，而kafka中消息的Offset是由客户端自己维护
       分布式，把写入压力均摊到各个节点。可以通过增加节点降低压力
       Kafka的优点：
           分布式高可扩展。Kafka 集群可以透明的扩展，增加新的服务器进集群；
           高性能。Kafka 的性能大大超过传统的ActiveMQ、RabbitMQ等MQ 实现，尤其是Kafka 还支持batch 操作；
           容错。Kafka每个Partition的数据都会复制到几台服务器上。当某个Broker故障失效时，ZooKeeper服务将通知生产者和消费者，生产者和消费者转而使用其它Broker。
       Kafka的缺点：
           重复消息。Kafka 只保证每个消息至少会送达一次，虽然几率很小，但一条消息有可能会被送达多次；
           消息乱序。虽然一个Partition 内部的消息是保证有序的，但是如果一个Topic 有多个Partition，Partition 之间的消息送达不保证有序；
           复杂性。Kafka需要zookeeper 集群的支持，Topic通常需要人工来创建，部署和维护较一般消息队列成本更高。
   (4)Redis做Mq
       Redis是一个高性能的key-value数据库，它的出现很大程度补偿了memcached这类key-value存储的不足。虽然它是一个数据库系统，但本身支持MQ功能，完全可以当做一个轻量级的队列服务器使用。Redis开发语言为C，支持OS为Linux。
       Redis从2.0版本开始支持发布/订阅指令，发布者调用redis的publish方法往特定的channel发送消息，订阅者在初始化的时候要订阅到该channel，一旦有消息就会立即接收。
       redis 消息推送（基于分布式 pub/sub）多用于实时性较高的消息推送，并不保证可靠。其他的mq和kafka保证可靠但有一些延迟（非实时系统没有保证延迟）。redis-pub/sub断电就清空，而使用redis-list作为消息推送虽然有持久化，但是也并非完全可靠不会丢。

   (5)RocketMQ
           阿里出品，topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic

   (5)RabbitMQ与Redis性能对比
       性能上，实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；
       出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

   总结：
       一般的业务场景使用RabbitMQ，不论是实时性和准确性等方面都比较优秀,日志采集、大数据领域使用kafaka，吞吐量很大