负载均衡的Fiware Orion [英] Load balanced Fiware Orion

问题描述

我刚刚使用Nginx创建了docker化的OCB负载平衡版本，并通过Nginx平衡运行了Orion的独立实例.仅用于测试目的.

I just created a dockerized load balanced version of OCB using Nginx and supervisord running separate instances of Orion balanced by Nginx. Only for testing purposes.

我的问题是，如果我使用这种方法，TIMEINTERVAL订阅会遇到麻烦吗? (我不希望每个OCB流程都发出"n"个通知).

My question is if I use this approach, would I have some troubles with TIMEINTERVAL subscriptions? (I don't want 'n' notifications for each OCB process).

任何帮助将不胜感激.

推荐答案

当前Orion版本(0.23.0)的工作方式如下:在创建时，LB将ONTIMEINTERVAL subscriptionContext分配给CB节点之一，这样会创建一个永久线程，负责按通知频率发送通知消息.

Current Orion version (0.23.0) works in the following way: at creation time, the ONTIMEINTERVAL subscribeContext is dispatched by the LB to one of the CB nodes, which creates a permantent thread in charge of sending notification messages at the notification frequency.

但是，有两种问题:

• 如果客户端要取消发送unsubscribeContext的订阅，则可以由管理订阅的CB not 接收该请求.因此，该操作可能会导致从DB中删除订阅，但是通知将继续发送.

• If the client wants to cancel the subscription sending unsubscribeContext, that request could be recived by a CB not managing the subscription. Thus, the operation may result in the subscription being deleted from DB, but the notification continues being sent.

让我们考虑一下，在给定的时刻，CB1管理订阅S1和S2，CB2管理订阅S3和S4.让我们考虑一下CB2发生故障并重新启动. CB2将在开始时间看到"四个订阅(S1，S2，S3和S4)，因此创建了4个线程，最终结果是重复了S3和S4通知(由CB1和CB2同时发送)

Let's consider that in a given moment CB1 managed subscriptions S1 and S2 and CB2 managed S3 and S4. Let's consider that CB2 fails and that it is restarted. The CB2 will "see" four subscription (S1, S2, S3 and S4) at starting time, thus 4 threads are created and the final result is that S3 and S4 notifications are duplicated (being sent at the same time by CB1 and CB2).

因此，在高可用性和/或水平扩展方案中，建议不要进行ONTIMEINTERVAL订阅.但是，请注意，所有基于ONTIMEINTERVAL的用例都可以在通知接收者处以相同的频率反转"运行基于queryContext的轮询，因此这并不是一个大问题.

Thus, in sum ONTIMEINTERVAL subscription are discouraged in HA and/or horizontal scaling scenarios. However, note that all use cases based on ONTIMEINTERVAL can be "reversed" running a queryContext-based polling at the same frequency at the notification receptor, so it doesn't use to be a big problem.

编辑:删除了ONTIMEINTERVAL订阅在Orion 1.0.0 中. ONTIMEINTERVAL订阅有几个问题(如以上答案中所述).实际上，它们并不是真正需要的，因为任何基于ONTIMEINTERVAL通知的用例都可以转换为等效的用例，在该用例中，接收器以相同的频率运行queryContext(并利用queryContext的功能，例如分页或过滤) )

EDIT: ONTIMEINTERVAL subscription were removed in Orion 1.0.0. ONTIMEINTERVAL subscriptions had several problems (as the ones described in the above answer). Actually, they aren't really needed, as any use case based on ONTIMEINTERVAL notification can be converted to an equivalent use case in which the receptor runs queryContext at the same frequency (and taking advantage of the features of queryContext, such as pagination or filtering)

这篇关于负载均衡的Fiware Orion的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！