跟随Redis Pub / Sub
这工作正常,我可以使用以下任何语言发布消息
$redis.publish 'channel', { object: @object.id }
使用redis-cli > MONITOR
,我可以验证此请求是否已正确发布
[0 127.0.0.1:64192] "publish" "channel" "{:object=>\"5331d541f4eec77185000003\" }"
当我将订阅者 块 添加到 其他类(侦听器类)中的 该频道时,问题就开始了,如下所示
class OtherClass
$redis.subscribe('channel') do |payload|
p payload
end
end
中的redis-cli > MONITOR
,还表明侦听器已正确订阅
[0 127.0.0.1:52930] "subscribe" "channel"
问题是,当我将订户侦听器类添加到相同的Rails应用程序时…它停止工作,导致OtherClass
侦听Redis服务器并停止执行任何其他代码…它只是坐在那里侦听。
因此,有一种方法可以在同一个Rails应用程序上使用redis制作消息总线…以便
从某些类或服务对象发布事件,并且有特定通道的侦听器在后台接收事件时起作用。
我知道我可能会使用sidekiq或任何其他背景工作人员来完成这项工作…但是过了一会儿,背景工作人员变得凌乱且难以维护。
的实现Redis#subscribe
是一个循环,它将采取对当前线程的控制以侦听事件。这意味着,当按照您显示的方式将订阅拖放到Rails类的上下文中时,引导过程将停止。
您可以尝试将调用包装在线程中,但是这种方法将在每次将该类加载到新进程(如Rails控制台或多个独角兽)中时,实际上都会创建一个新的订阅。另外,您必须注意共享状态和其他线程问题。这可能不是您想要的。
最好启动一个不同的进程来加载Rails环境并与服务Web请求的进程分开预订Redis。可能是类似以下的rake任务:
namespace :subscribe do
task :redis => :environment do
$redis.subscribe("bravo") do |on|
on.message do |channel, message|
Rails.logger.info("Broadcast on channel #{channel}: #{message}")
OtherClass.some_method # yada yada
end
end
end
end
主要内容:发布/订阅流程,常用命令汇总,基本命令应用Redis PubSub 模块又称发布订阅者模式,是一种消息传递系统,实现了消息多播功能。发布者(即发送方)发送消息,订阅者(即接收方)接收消息,而用来传递消息的链路则被称为 channel。在 Redis 中,一个客户端可以订阅任意数量的 channel(可译为频道)。 消息多播:生产者生产一次消息,中间件负责将消息复制到多个消息队列中,每个消息队列由相应的消费组进行消费,这是分布式系统常用的
Redis 发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。 Redis 客户端可以订阅任意数量的频道。 下图展示了频道 channel1 , 以及订阅这个频道的三个客户端 —— client2、client5 和 client1 之间的关系: 当有新消息通过 PUBLISH 命令发送给频道 channel1 时, 这个消息就会被发送给订阅它的三个
我有一个问题非常困扰我。Redis发布/订阅功能的实际用途是什么?我只能想到通过TCP(本地或分布式)进行进程间通信,但其他的就不多了。 有人能证明我错了吗。
问题内容: 当前,我正在使用node.js和redis来构建应用程序,使用redis的原因是由于发布/订阅功能。该应用程序只是在用户进入用户或不在房间时通知管理员。 由于我想听join和disjoin事件,我的问题是我是否应该使用两个redisclient来听这两个事件,例如 或者只是使用一个redisclient来监听和分离回调中的逻辑 我知道这两种方式都是可行的,但是我不知道人们在哪种情况下会
简介 Redis 的列表类型键可以用来实现队列,并且支持阻塞式读取,所以 Redis 能够非常容易的实现一个高性能的优先队列。同时在更高层面上,Redis 还支持“发布/订阅”的消息模式,可以基于此构建一个聊天系统。 发布示例 发布(Publish)即将消息发布到频道中。示例代码: // 发送消息 Redis::publish('chan-1', 'Hello, World!'); // 发送消息
问题内容: 我正在尝试使用nodejs和node_redis构建一个通用的发布/订阅服务器,该服务器接收带有通道名称的浏览器的请求,并以该通道也已发布的任何数据作为响应。为此,我使用了来自浏览器的长轮询请求,并通过在通道上收到消息时发送响应来处理这些请求。 对于每个新请求,都会创建一个对象来订阅该频道(如果且仅当该频道不存在时)。 这是处理订阅渠道的最佳方法,还是还有其他更直观的方法? 问题答案: