我刚刚使用 Nginx 创建了一个 OCB 的 dockerized 负载平衡版本，并且 supervisord 运行由 Nginx 平衡的 Orion 的单独实例。仅用于测试目的。
我的问题是，如果我使用这种方法，TIMEINTERVAL 订阅会不会有一些问题？ (我不希望每个 OCB 进程都有“n”个通知)。
我们将不胜感激任何帮助。
最佳答案
当前 Orion 版本 (0.23.0) 以下列方式工作:在创建时，ONTIMEINTERVAL subscribeContext 由 LB 分派(dispatch)到其中一个 CB 节点，它创建一个永久线程，负责在通知时发送通知消息频率。
但是，有两种问题:
如果客户端想要取消订阅发送 unsubscribeContext，该请求可以由 管理订阅的 CB 接收。因此，该操作可能会导致从数据库中删除订阅，但会继续发送通知。
让我们考虑一下，在给定时刻，CB1 管理订阅 S1 和 S2，而 CB2 管理 S3 和 S4。让我们考虑 CB2 失败并重新启动。 CB2在启动时会“看到”4个订阅(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 的特性，例如分页或过滤)
关于nginx - 负载均衡 Fiware Orion，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32274951/