在Orion負載平衡方案中，訂閱和通知的行為是什么？

Question

基於此答案，有關如何通過負載平衡擴展Orion Context Broker https://stackoverflow.com/a/33068119/3706998訂閱和通知的行為應該是什么？

女巫服務器應該來自哪里？ 什么是工作流程？

會引起一些混亂或訂閱混亂嗎？

Answer 1

讓我們考慮不同的情況，具體取決於訂閱緩存的使用情況。 讓我們考慮不失一般性的兩個Orion節點（A和B），它們共享同一個MongoDB實例。

使用訂閱緩存（即未設置-noCache ）

訂閱創建請求被分派到某些節點（假設它是節點A）。 節點A將把訂閱保留在共享數據庫和本地（即節點A）訂閱緩存中。 請注意，直到下一次訂閱緩存刷新，節點B才知道新的訂閱。 這相當於-subCacheIval參數的秒間隔。

現在考慮更新（在符合訂閱條件以觸發通知的實體/屬性上）。 降低負載均衡器將更新分發到哪個節點及其到達的時間（關於訂閱創建請求時間），可能會發生以下情況之一：

• 更新在下一次訂閱刷新（即-subCacheIval秒） 之前到達節點B。 假設節點B對訂閱一無所知，則不會發送通知。

• 在下一次訂閱刷新（即-subCacheIval秒） 之后 ，更新到達節點B。 節點B知道新訂閱是刷新的便利，因此發送了通知。

• 無論下一次訂閱刷新之前還是之后，更新都會到達節點A。 節點A是創建訂閱的節點，因此它的緩存從一開始就是最新的。 因此，發送通知。

顏色：預訂創建后等待-subCacheIval將確保預訂已傳播到所有CB節點，因此將始終發送通知。 但是，請注意，將-subCacheIval值設置得太小可能會產生負面影響。 權衡在Orion性能文檔部分中進行了分析。

最后，關於節流，請注意Orion實施說明中的以下說明 ：

另外，Orion以本地方式實施節流。 在多CB配置中，應考慮到最后通知措施是每個Orion節點本地的。 盡管每個節點定期與DB同步以獲取潛在的新值（ 此處有更多信息 ），但是可能會發生特定節點具有舊值的情況，因此限制並不是100％准確的。

因此，如果您需要精確的節流，則最好在通知者接收終結點處實施它，而不是使用Orion提供的終結點。

不使用訂閱緩存（即，設置了-noCache ）

在這種情況下，訂閱評估總是在查詢數據庫時完成。 因此，無論哪個節點（A或B）創建了預訂，因為它都存儲在DB中。 因此，無論A或B是否處理更新，因為它將在數據庫中檢查匹配的訂閱，並且在這種情況下始終發送通知。

但是，請注意，此模式（不使用訂閱高速緩存）可能會帶來嚴重的性能缺陷（尤其是在使用基於模式的訂閱的情況下），因此不建議使用。

我不太確定，但是在這種情況下可能不會發生針對其他情況描述的限制問題。