【问题标题】:Jedis Many Subscribers绝地武士许多订阅者
【发布时间】:2014-01-24 08:38:22
【问题描述】:

我正在用 java 构建一个推送服务器,并计划使用 Redis PubSub 将消息排队以发送到客户端。

现在我的实现每个设备都有一个 redis 订阅者。因此,当设备上线时,它会为其设备订阅 redis 队列。

这个比例可以吗/有更好的方法吗?我将拥有成千上万的订阅者。

【问题讨论】:

    标签: java redis jedis


    【解决方案1】:

    每个设备的订阅者应该可以正常工作。我认为扩展问题主要围绕您向每个订阅者发布的确切内容以及消息实际存在的位置。您可能还需要考虑在某个时候运行多个 redis 实例,可能由 Redis Sentinel 管理,以确保高可用性。如果主实例不可用,Redis Sentinel 将处理将您的一个从 Redis 实例提升为主实例,然后在原始主实例返回并赶上时将其提升回主实例。

    如果消息对于每个订阅者都是唯一的,那么将消息发送给每个订阅者似乎是一个好方法。请注意,redis 中的 pub/sub 不提供持久性,因此如果我的订阅者断开连接或崩溃或其他任何事情并返回,自他上次订阅以来发送的所有消息都对他不可用。如果您需要持久性,那么消息可能应该为每个订阅者发送到一个 LIST,并且在频道上发布的内容应该只是通知客户端有新消息可用。然后,订阅者可以在空闲时从 LIST 中弹出任何消息,直到 LIST 为空。每当在频道上收到通知时,此过程都会重复。

    如果一条消息正在广播给您的所有或多个客户端,那么您可能应该考虑将消息本身存储在 redis 键或列表或其他东西中,并在每个受影响的客户端的频道上发布一条新消息可用以及在哪里(什么键)阅读它。您可以使用多种策略来跟踪哪个订阅者阅读了哪些消息并删除每个人都阅读的旧消息。

    【讨论】:

      猜你喜欢
      • 2015-03-07
      • 1970-01-01
      • 1970-01-01
      • 2014-02-09
      • 1970-01-01
      • 1970-01-01
      • 2017-10-07
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多