redis消息队列（redis消息队列和mq）

本篇文章给大家谈谈redis消息队列，以及redis消息队列和mq对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、通过Redis消息队列实现大文件处理
• 2、redis消息队列先进先出需要注意什么？
• 3、Kafka，Mq和Redis作为消息队列使用
• 4、Redis实现简单消息队列
• 5、Redis的基本使用（二） 消息队列

通过Redis消息队列实现大文件处理

一、故事背景

1、读取离线文件数据，再通过【离线数据】作为条件，查询第三方接口，返回最终的结果，再入库。

2、 业务逻辑是很简单， 读取文件、查询接口、返回数据集、入库 四步。

3、业务特性：第三方接口调用400毫秒(ms) 。

如果用普通单线程去跑算500毫秒一个请求，一天也就跑8W多数据量，20多亿的数据不知道跑到猴年马月了。

二、处理方案

A) 初步方案采用ganymed-ssh2(文件都存储在Linux服务器雹租消上) 来读文件，Redis来存储型盯消息、多线程来提升处理能力。

B) 流程图：

三、呈现问题

四、优化问题

最终流程图：

1、 通过Redis做一个计数器 每读取一行记录数值，即使服务终止后，先从Redis读取这个源知数值

再通过cat指定行数开始读数据即可。

2、 通过取模拆Key 分片到不同小Key存储 ，降低单个节点存储压力，也充分利用了存储资源。

3、Redis Push 提供了批量方式(leftPushAll) ，可以指定读取行数再批量入库，而pop并没有提供批量 只能一个一个pop。

4、消费者通过多线程pop、再分发到线程去处理。

五、总结问题

[img]

redis消息队列先进先出需要注意什么？

通常使用一个list来实现队列操作，这样有一个小限制，所以的任务统一都是先进先出，如果想优先处理某个任务就不太好处理了，这就需要让洞手队列有优先级的概念，我们就可以优先处理高级别的任务，实现方式有以下纳帆嫌几种方式：

1）单一列表实现：队列正常的操作是 左进右出（lpush,rpop）为了先处理高优先级任务，在遇到高级别任务时，可以直接插队，直接放入队列头部（rpush），这样，从队列头部（右侧）获取任务时，取到的就是高优先级的任务（rpop）

2）使用两个队列，一个普通队列，一个高级队列，针对任务轿御的级别放入不同的队列，获取任务时也很简单，redis的BRPOP命令可以按顺序从多个队列中取值，BRPOP会按照给出的 key 顺序查看，并在找到的第一个非空 list 的尾部弹出一个元素，redis BRPOP list1 list2 0

list1 做为高优先级任务队列 list2 做为普通任务队列

这样就实现了先处理高优先级任务，当没有高优先级任务时，就去获取普通任务

方式1最简单，但实际应用比较局限，方式3可以实现复杂优先级，但实现比较复杂，不利于维护，方式2是推荐用法，实际应用最为合适

Kafka，Mq和Redis作为消息队列使用

kafka是个日志处理缓冲组件，在大数据信息处理中使用。和传统的消息队列相比较简化了队列结构和功能，以流形式处理存储（持久化）消息（主要是日志）。日志数据量巨大，处理组件一般会处理不过来，所以作为孝衫神缓冲层的kafka，支持巨大吞吐量。为了防止信息丢失，其消息被调用后不直接丢弃，要多存储一段时间，等过期时间过了才丢弃。这是mq和redis不能具备的。主要特点如下:巨型存储量: 支持TB甚至PB级别数据。高吞吐，高IO：一般配置的服务器能实现单机每秒100K以上消息的传输。消息分区，分布式消费：能保消息顺序传输。 支持离线数据处理和实时数据处理。Scale out：支持在线水平扩展，以支持更大数塌洞据处理量

redis只是提供一个高性能的、原子操作内存键值对，具有高速访问能力，可用做消息队列的存储，但是不具备消息队列的任何功能和逻辑，要作为消息队列来实现的话，功能和逻辑要通过上层应用自己实现。

我们以RabbitMQ为例介绍。它是用Erlang语言开发的开源的消息队列，支持多种协议，包括AMQP，XMPP, SMTP, STOMP。适合于企业级的开发。

MQ支持Broker构架，消息发送给客户端时需要在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。

还有ActiveMq，ZeroMq等。功能基本上大同小异。并发吞吐TPS比较，ZeroMq 最好，RabbitMq 次之， ActiveMq 最差巧亏。

原文：

Redis实现简单消息队列

打开浏览器，输入地址，按下回车，打开凯芹了页面。于是一个 HTTP 请求（ request ）就由客户端发送到服务器，服务器处理请求，返回响应（ response ）内容。

我们每天都在浏览网页，发送大大小小的请求给服务器。有时候，服务器接到了请求，会发现他也需要给另外的服务器发送请求，或者服务器也需要做另外一些事情，于是最初们发送的请求就被阻塞了，也就是要等待服务器完成其他的事情。

更多的时候，服务器做的额外事情，并不需要客户端等待，这时候就可以把这些额外的事情异步去做。从事异步任务的工具有很多。主要原理还是处理通知消息，针对通知消息通常采取是队列结构。生产和消费消息进行通信和业务实现。

上述异步任务的实现，知纤可以抽象为生产者消费模型。如同一个餐馆，厨师在做饭，吃货在吃饭。如果厨师做了很多，暂时卖不完，厨师就会休息；如果客户很多，厨师马不停蹄的忙碌，客户则需要慢慢等待。实现生产者和消费者的方式用很多，下面使用 Python 标准库 Queue 写个小例子：

大概输出如下：

Python内置了一个好用的队列结构。我们也可以是用redis实现类似的操作。并做一个简单的异步任务。

Redis提供了两种方式来作消息队列。一个是使用 生产者消费模式 模式，另外一个方法就是 发布订阅者模式 。前者会让一个或者多个客户端监听消息队列，一旦消息到达，消费者马上消费，谁先抢到算谁的，如果队列里没有消息，则消费者继续监听。后者也是一个或多个客户端订阅消息频道，只要发布者发布消息，所有订阅者都能收到消息，订阅者都是平等的。

主要使用了redis提供的blpop获取队列数据，如果队列没有数据则阻塞盯猛毕等待，也就是监听。

使用redis的pubsub功能，订阅者订阅频道，发布者发布消息到频道了，频道就是一个消息队列。

我们分别实现了两种异步任务的后端服务，直接启动他们，就能监听redis队列或频道的消息了。简单的测试如下：

启动脚本，使用

可以分别在监听的脚本输入中看到异步消息。在异步的任务中，可以执行一些耗时间的操作，当然目前这些做法并不知道异步的执行结果，如果需要知道异步的执行结果，可以考虑设计协程任务或者使用一些工具如 RQ 或者 celery 等。

Redis的基本使用（二） 消息队列

使用消息中间件的时候，并非每次都需要非常专业的消息中间件，假如只有一个消息队列，只有一个消费者，那就没有必要去使用专业的消息中间件，这种情况可以直接使用 Redis 来做消息大敬则队列。

Redis 的消息队列不是特别专业，他没有很多高级特性，适用简单的场景，如果对稿扰于消息可靠性有着极高的追求，那么不适合使用 Redis 做消息队列。

Redis 做消息队列，使用它里边的 List 数据结构就可以实现，使用 lpush/rpush 操作来实现入队，然后使用 lpop/rpop 来实现出队。

在客户端（例如 Java 端），我们会维护一个死循环来不停的从队列中读取消息，并处理，如果队列中有消息，则直

接获取到，如果没有消息，就会陷入死循环，直到下一次有消息进入，这种死循环会造成大量的资源浪费，这个滚棚时候，

可以使用之前讲的 blpop/brpop 。

blpop 阻塞式的弹出，相当于 lpop 的阻塞版。

延迟队列可以通过 zset 来实现，因为 zset 中有一个 score，我们可以把时间作为 score，将 value 存到redis 中，然后通过轮询的方式，去不断的读取消息出来。

首先，如果消息是一个字符串，直接发送即可，如果是一个对象，则需要对对象进行序列化，这里我们

使用 JSON 来实现序列化和反序列化。

首先在项目中，添加 JSON 依赖：

接下来，构造一个消息对象：

接下来封装一个消息队列：

测试：

关于redis消息队列和redis消息队列和mq的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。