【问题标题】:Number of subscribers to a pub/sub channel and timeout发布/订阅频道的订阅者数量和超时
【发布时间】:2014-05-30 22:38:34
【问题描述】:

目前正在开发一个多进程/多主机 nodeJS 应用程序我遇到了一个问题,我需要你的帮助。

我的应用程序包含流程,每个流程都可以托管多个独特的作业。我必须实时知道我的系统上是否正在运行作业。

这是我目前的解决方案:

  • 每个作业都订阅一个频道“job.JOB_UUID”
  • 如果一个进程想知道一个作业当前是否正在运行,我推送到“job.JOB_UUID”并检查订阅者数量。如果是 1 = ok,这个作业正在运行,如果 0 不是。

此解决方案运行良好,除非出现网络问题。可能是因为 Redis pub/sub 没有超时:

Note that the timeout only applies to number clients and it **does not apply** to Pub/Sub clients, since a Pub/Sub connection is a push style connection so a client that is idle is the norm.

Redis 似乎保留了幽灵订阅者,当我发布到频道时,它返回给我 1 个订阅者,但它实际上并不存在。

你有处理这个案子的想法吗?

ps:我之前的解决方案是:

  • 每个作业在 redis 中设置一个键“job_UUID”,TTL 设置为 5s。
  • 每个作业每秒都会更新 TTL
  • 要检查作业是否存在,我只检查“job_UUID”键是否存在 问题是它不是实时的。

【问题讨论】:

    标签: node.js redis node-redis


    【解决方案1】:

    如果您能保证您的工作不会崩溃,您可以随时使用原始解决方案的变体。

    每个作业在redis中设置一个键“job_UUID”,TTL设置为N(一个足够大的数字让进程完成,它只会作为超时) 作业完成,在执行期间捕获任何异常。 作业完成后,它会从 redis 中删除密钥

    在这种情况下,您始终拥有实时时间。在进程运行时,该值将在那里。只有当您的工作在没有删除值的情况下死亡时,您才会看到不一致。保护超时时间过后,TTL 将自动删除该值。

    如果您需要更强大的实时功能,那么您可能使用了错误的工具来完成这项工作。对于进程协调 ZooKeeper 是相当了不起的。不像 Redis 那样通用,而且由于问题的分布式特性,设置起来肯定有点复杂,但对于流程编排和实时故障转移非常非常好。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-12-14
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-10-29
      相关资源
      最近更新 更多