我刚刚使用 Nginx 创建了一个 dockerized 负载平衡版本的 OCB，并且 supervisord 运行由 Nginx 平衡的 Orion 的单独实例。仅用于测试目的。
我的问题是，如果我使用这种方法，我会在 TIMEINTERVAL 订阅方面遇到一些麻烦吗？ （我不希望每个 OCB 进程都有 'n' 个通知）。
我们将不胜感激。
【问题讨论】：
标签： nginx supervisord fiware-orion
当前 Orion 版本 (0.23.0) 的工作方式如下：在创建时，LB 将 ONTIMEINTERVAL subscribeContext 分派到其中一个 CB 节点，从而创建一个永久线程，负责在通知处发送通知消息频率。
但是，有两种问题：
如果客户端想要取消发送 unsubscribeContext 的订阅，该请求可能会被管理订阅的 CB 接收。因此，该操作可能会导致订阅从 DB 中删除，但通知会继续发送。
让我们考虑在给定的时刻 CB1 管理订阅 S1 和 S2，而 CB2 管理 S3 和 S4。让我们考虑 CB2 失败并重新启动。 CB2 在启动时会“看到”四个订阅（S1、S2、S3 和 S4），因此创建了 4 个线程，最终结果是 S3 和 S4 通知重复（由 CB1 和 CB2 同时发送） .
因此，总而言之，在 HA 和/或水平扩展方案中不鼓励订阅 ONTIMEINTERVAL。但是，请注意，所有基于 ONTIMEINTERVAL 的用例都可以“反转”，在通知接收器上以相同频率运行基于 queryContext 的轮询，因此这不是一个大问题。
编辑：ONTIMEINTERVAL 订阅were removed in Orion 1.0.0。 ONTIMEINTERVAL 订阅有几个问题（如上述答案中所述）。实际上，它们并不是真正需要的，因为任何基于 ONTIMEINTERVAL 通知的用例都可以转换为受体以相同频率运行 queryContext 的等效用例（并利用 queryContext 的功能，例如分页或过滤)
【讨论】：