Redis和RabbitMQ实现消息队列

夜唯美不离

墨衍会员 · AI 创作全网分发码龄14年

关注

转载最新推荐文章于 2026-01-25 11:33:26 发布 4.5k 阅读 AI 写同款· GEO 优化 ›

AI权益加码！Claude Code、Cursor等20+工具免费用！购周边限时加赠Coding Plan Lite，畅享主流AI工具！学习进阶更高效！阅读详情

RabbitMQ简介

1什么是RabbitMQ？

RabbitMQ是实现AMQP（高级消息队列协议）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然：

单向解耦

双向解耦（如：RPC）

例如一个日志系统，很容易使用RabbitMQ简化工作量，一个Consumer可以进行消息的正常处理，另一个Consumer负责对消息进行日志记录，只要在程序中指定两个Consumer所监听的queue以相同的方式绑定到同一个exchange即可，剩下的消息分发工作由RabbitMQ完成。

使用RabbitMQ server需要：

1. ErLang语言包；

2. RabbitMQ安装包；

RabbitMQ同时提供了java的客户端（一个jar包）。

2 概念和特性

2.1 交换机（exchange）：

1. 接收消息，转发消息到绑定的队列。四种类型：direct, topic, headers and fanout

direct：转发消息到routigKey指定的队列

topic：按规则转发消息（最灵活）

headers：（这个还没有接触到）

fanout：转发消息到所有绑定队列

2. 如果没有队列绑定在交换机上，则发送到该交换机上的消息会丢失。

3. 一个交换机可以绑定多个队列，一个队列可以被多个交换机绑定。

4. topic类型交换器通过模式匹配分析消息的routing-key属性。它将routing-key和binding-key的字符串切分成单词。这些单词之间用点隔开。它同样也会识别两个通配符：#匹配0个或者多个单词，*匹配一个单词。例如，binding key：*.stock.#匹配routing key：usd.stcok和eur.stock.db，但是不匹配stock.nana。

还有一些其他的交换器类型，如header、failover、system等，现在在当前的RabbitMQ版本中均未实现。

5. 因为交换器是命名实体，声明一个已经存在的交换器，但是试图赋予不同类型是会导致错误。客户端需要删除这个已经存在的交换器，然后重新声明并且赋予新的类型。

6. 交换器的属性：

- 持久性：如果启用，交换器将会在server重启前都有效。

- 自动删除：如果启用，那么交换器将会在其绑定的队列都被删除掉之后自动删除掉自身。

- 惰性：如果没有声明交换器，那么在执行到使用的时候会导致异常，并不会主动声明。

2.2 队列（queue）：

1. 队列是RabbitMQ内部对象，存储消息。相同属性的queue可以重复定义。

2. 临时队列。channel.queueDeclare()，有时不需要指定队列的名字，并希望断开连接时删除队列。

3. 队列的属性：

- 持久性：如果启用，队列将会在server重启前都有效。

- 自动删除：如果启用，那么队列将会在所有的消费者停止使用之后自动删除掉自身。

- 惰性：如果没有声明队列，那么在执行到使用的时候会导致异常，并不会主动声明。

- 排他性：如果启用，队列只能被声明它的消费者使用。

这些性质可以用来创建例如排他和自删除的transient或者私有队列。这种队列将会在所有链接到它的客户端断开连接之后被自动删除掉。它们只是短暂地连接到server，但是可以用于实现例如RPC或者在AMQ上的对等通信。4. RPC的使用是这样的：RPC客户端声明一个回复队列，唯一命名（例如用UUID），并且是自删除和排他的。然后它发送请求给一些交换器，在消息的reply-to字段中包含了之前声明的回复队列的名字。RPC服务器将会回答这些请求，使用消息的reply-to作为routing key（默认绑定器会绑定所有的队列到默认交换器，名称为“amp.交换器类型名”）发送到默认交换器。注意这仅仅是惯例而已，可以根据和RPC服务器的约定，它可以解释消息的任何属性（甚至数据体）来决定回复给谁。

2.3 消息传递：

1. 消息在队列中保存，以轮询的方式将消息发送给监听消息队列的消费者，可以动态的增加消费者以提高消息的处理能力。

2. 为了实现负载均衡，可以在消费者端通知RabbitMQ，一个消息处理完之后才会接受下一个消息。

channel.basic_qos(prefetch_count=1)

注意：要防止如果所有的消费者都在处理中，则队列中的消息会累积的情况。

3. 消息有14个属性，最常用的几种：

deliveryMode：持久化属性

contentType：编码

replyTo：指定一个回调队列

correlationId：消息id

实例代码：

4. 消息生产者可以选择是否在消息被发送到交换器并且还未投递到队列（没有绑定器存在）和/或没有消费者能够立即处理的时候得到通知。通过设置消息的mandatory和/或immediate属性为真，这些投递保障机制的能力得到了强化。

5. 此外，一个生产者可以设置消息的persistent属性为真。这样一来，server将会尝试将这些消息存储在一个稳定的位置，直到server崩溃。当然，这些消息肯定不会被投递到非持久的队列中。

2.4 高可用性（HA）：

1. 消息ACK，通知RabbitMQ消息已被处理，可以从内存删除。如果消费者因宕机或链接失败等原因没有发送ACK（不同于ActiveMQ，在RabbitMQ里，消息没有过期的概念），则RabbitMQ会将消息重新发送给其他监听在队列的下一个消费者。

channel.basicConsume(queuename, noAck=false, consumer);

2. 消息和队列的持久化。定义队列时可以指定队列的持久化属性（问：持久化队列如何删除？）

channel.queueDeclare(queuename, durable=true, false, false, null);

发送消息时可以指定消息持久化属性：

channel.basicPublish(exchangeName, routingKey,

MessageProperties.PERSISTENT_TEXT_PLAIN,

message.getBytes());

这样，即使RabbitMQ服务器重启，也不会丢失队列和消息。

3. publisher confirms

4. master/slave机制，配合Mirrored Queue，这种情况下，publisher会正常发送消息和接收消息的confirm，但对于subscriber来说，需要接收Consumer Cancellation Notifications来得到主节点失败的通知，然后re-consume from the queue，此时要求client有处理重复消息的能力。注意：如果queue在一个新加入的节点上增加了一个slave，此时slave上没有此前queue的信息（目前还没有同步机制）。

（通过命令行或管理插件可以查看哪个slave是同步的：

rabbitmqctl list_queues name slave_pids synchronised_slave_pids）

当一个slave重新加入mirrored-queue时，如果queue是durable的，则会被清空。

2.5 集群（cluster）：

1. 不支持跨网段（如需支持，需要shovel或federation插件）

2. 可以随意的动态增加或减少、启动或停止节点，允许节点故障

3. 集群分为RAM节点和DISK节点，一个集群最好至少有一个DISK节点保存集群的状态。

4. 集群的配置可以通过命令行，也可以通过配置文件，命令行优先。

3 使用

3.1 简易使用流程

3.2 RabbitMQ在OpenStack中的使用

在Openstack中，组件之间对RabbitMQ使用基本都是“Remote Procedure Calls”的方式。每一个Nova服务（比如计算服务、存储服务等）初始化时会创建两个队列，一个名为“NODE-TYPE.NODE-ID”，另一个名为“NODE-TYPE”，NODE-TYPE是指服务的类型，NODE-ID指节点名称。

从抽象层面上讲，RabbitMQ的组件的使用类似于下图所示：

每个服务会绑定两个队列到同一个topic类型的exchange，从不同的队列中接收不同类型的消息。消息的发送者如果关心消息的返回值，则会监听另一个队列，该队列绑定在一个direct类型的exchange。接受者收到消息并处理后，会将消息的返回发送到此exchange。

在Openstack中，如果不关心消息返回，消息的流程图如下：

如果关心消息返回值，流程图如下：

3.3 为什么要使用RabbitMQ？

曾经有过一个人做过一个测试（http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html），发送1百万个并发消息，对性能有很高的需求，于是作者对比了RabbitMQ、MSMQ、ActiveMQ、ZeroMQueue，整个过程共产生1百万条1K的消息。测试的执行是在一个Windows Vista上进行的，测试结果如下：

虽然ZeroMQ性能较高，但这个产品不提供消息持久化，需要自己实现审计和数据恢复，因此在易用性和HA上不是令人满意，通过测试结果可以看到，RabbitMQ的性能确实不错。

我在本机也做了一些测试，但我的测试是基于组件的原生配置，没有做任何的配置优化，因此总觉的不靠谱。我只测试了RabbitMQ和ActiveMQ两款产品，虽然网上都说ActiveMQ性能不如前者，但平心而论，ActiveMQ提供了很多配置，存在很大的调优空间，也许修改一个配置参数就会使组件的性能有一个质的飞跃。

Redis简介

1 什么是Redis？

REmote DIctionary Server(Redis) 是一种面向“键/值”对类型数据的分布式NoSQL数据库系统。Redis提供了一些丰富的数据结构，包括 lists, sets, ordered sets 以及 hashes ，当然还有和Memcached一样的 strings结构.Redis当然还包括了对这些数据结构的丰富操作。没有做任何的配置优化，包括 lists, sets, ordered sets 以及 hashes ，当然还有和Memcached一样的 strings结构.Redis当然还包括了对这些数据结构的丰富操作。

redis目前提供四种数据类型：string,list,set及zset(sorted set)。

string是最简单的类型，你可以理解成与Memcached一模一个的类型，一个key对应一个value，其上支持的操作与Memcached的操作类似。但它的功能更丰富。
list是一个链表结构，主要功能是push、pop、获取一个范围的所有值等等。操作中key理解为链表的名字。
set是集合，和我们数学中的集合概念相似，对集合的操作有添加删除元素，有对多个集合求交并差等操作。操作中key理解为集合的名字。
zset是set的一个升级版本，他在set的基础上增加了一个顺序属性，这一属性在添加修改元素的时候可以指定，每次指定后，zset会自动重新按新的值调整顺序。可以理解了有两列的mysql表，一列存value，一列存顺序。操作中key理解为zset的名字。

2 概述

Redis通过定义一个 struct redisServer 类型的全局变量server 来保存服务器的相关信息（比如：配置信息，统计信息，服务器状态等等）。启动时通过读取配置文件里边的信息对server进行初始化（如果没有指定配置文件，将使用默认值对sever进行初始化），初始化的内容有：起监听端口，绑定有新连接时的回调函数，绑定服务器的定时函数，虚拟内存初始化，log初始化等等

3 适用场景

Redis和RabbitMQ性能对比

RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。个人认为，在互联网开发中，使用消息队列，更多的因为在高并发环境下，由于来不及同步处理，请求会发生堵塞，所以我们需要一个队列服务来进行异步的处理，在这种场景下，只要队列服务满足最基本的Push/Pop已经足够了。

    Redis是一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持list数据结构的操作，所以完全可以当做一个轻量级的队列服务来使用。
    对于入队操作，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis慢的无法忍受。
    对于出队操作，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
    Redis比较适合在Web场景下作为队列服务使用，但当数据比较大的时候，入队性能有些问题，也可能是我配置上不正确，所以还需要进一步研究。而RabbitMQ本身支持太多的协议，不适合在Web环境中使用。另外有一个MySQL的插件Q4M，可以使用SQL语法来操作消息队列，只不过性能表现怎么样，还需要进一步测试。