Redis发布/订阅和高可用性
目前，我正在开发一个分布式测试执行和报告系统。我计划将Redis PUB/SUB用作消息队列和消息分发系统。
我是Redis的新手，所以我试着阅读尽可能多的文档，并尝试着使用它。最重要的主题之一是高可用性。正如我所说，我不是专家，但我知道可能的选择——使用Sentinel、复制、集群等。
我不清楚的是Pub/Sub功能和HA选项是如何相互关联的。使用Redis构建可靠消息传递系统的最佳实践是什么？可靠的意思是，如果我的Redis消息代理出现故障，应该有某种备份节点（从节点？）应该能够接管这个角色。
是否有纯粹的服务器端解决方案？或者我需要围绕Redis客户端创建一个智能包装器来处理此问题？Sentinel驱动的设置会帮助我吗？
共有2个答案
在国际海事组织，PUB/SUB不是一个好的选择，也许disque（来自Redis的作者antirez）更适合：
Disque，内存中的分布式作业队列
在Redis中使用故障切换进行pub-sub意味着要考虑客户端的其他因素。需要了解的一个关键问题是，订阅是按连接进行的。如果您订阅了节点上的某个频道，但该频道出现故障，则需要处理重新连接和重新订阅。由于订阅是在连接级别完成的，因此无法复制。
关于它如何工作的细节以及您可以期望看到什么，以及围绕它的方法，请参阅我今年早些时候在https://objectrocket.com/blog/how-to/reliable-pubsub-and-blocking-commands-during-redis-failovers
您可以通过订阅从属服务器并将其发布到主服务器来降低风险面，但是您需要订阅不可升级的从属服务器，并且仍然需要处理丢失从属服务器的问题—丢失给定从属服务器的机会与丢失主服务器的机会一样多。
-
主要内容：发布/订阅流程,常用命令汇总,基本命令应用Redis PubSub 模块又称发布订阅者模式，是一种消息传递系统，实现了消息多播功能。发布者（即发送方）发送消息，订阅者（即接收方）接收消息，而用来传递消息的链路则被称为 channel。在 Redis 中，一个客户端可以订阅任意数量的 channel（可译为频道）。 消息多播：生产者生产一次消息，中间件负责将消息复制到多个消息队列中，每个消息队列由相应的消费组进行消费，这是分布式系统常用的
-
我有一个问题非常困扰我。Redis发布/订阅功能的实际用途是什么？我只能想到通过TCP（本地或分布式）进行进程间通信，但其他的就不多了。 有人能证明我错了吗。
-
问题内容： 我一直在寻找使用Redis Pub / Sub替代RabbitMQ。 据我了解，Redis的pub / sub拥有与每个订阅者的持久连接，如果该连接终止，则所有将来的消息都将丢失并掉在地板上。 一种可能的解决方案是使用列表（和阻止等待）将所有消息和pub / sub存储为通知机制。我认为这可以帮助我解决大部分问题，但是我仍然对失败案例感到担忧。 当订户死亡并重新联机时会发生什么情况，应
-
问题内容： 我正在尝试使用nodejs和node_redis构建一个通用的发布/订阅服务器，该服务器接收带有通道名称的浏览器的请求，并以该通道也已发布的任何数据作为响应。为此，我使用了来自浏览器的长轮询请求，并通过在通道上收到消息时发送响应来处理这些请求。 对于每个新请求，都会创建一个对象来订阅该频道（如果且仅当该频道不存在时）。 这是处理订阅渠道的最佳方法，还是还有其他更直观的方法？ 问题答案：
-
Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。 Redis 客户端可以订阅任意数量的频道。 下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2、client5 和 client1 之间的关系： 当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个
-
问题内容： 当前，我正在使用node.js和redis来构建应用程序，使用redis的原因是由于发布/订阅功能。该应用程序只是在用户进入用户或不在房间时通知管理员。 由于我想听join和disjoin事件，我的问题是我是否应该使用两个redisclient来听这两个事件，例如 或者只是使用一个redisclient来监听和分离回调中的逻辑 我知道这两种方式都是可行的，但是我不知道人们在哪种情况下会