Orion Context Broker交付保證？

Question

考慮到Orion Context Broker的“生產”使用，我想知道Orion Context Broker在消息傳遞方面提供了什么樣的保證 - 從生產者和消費者的角度來看？ 特別是，要記住各種可能的故障情況（CB故障/重啟，網絡瞬態故障，消費者故障/重啟等），以及CB中資源擁塞的可能性。 幾個例子：

1）如果上下文更新操作成功，是否保證后續查詢將返回最新數據（例如，即使CB在確認更新請求后立即失敗，然后重新啟動）？

2）如果消費者訂閱了某些上下文信息，是否可以保證它將收到所有相關的更新 - 只需一次，至少一次，甚至根本沒有？ （例如，在CB與消費者之間發生短暫網絡故障的情況下）

3）如果消費者更新了其訂閱，是否可以保證隨后的更新能夠准確反映它？ （例如，如果CB在確認訂閱請求后立即失敗，然后重新啟動）

4）如果消費者訂閱了上下文更改（'onchange'，沒有限制），並且生產者有多個后續更新影響同一屬性，是否保證每個更改都將被發送（或者某些更改可能會被跳過） - 例如，由於CB需要在特定時間段內發送的通知太多，是否按任何特定順序？

等等...

謝謝！

Answer 1

通過子彈回答子彈：

1. 通常，如果客戶端收到2xx響應（ 在 NGSIv1的情況下在響應有效負載內部，在 NGSIv2的情況下是HTTP響應代碼），它可以假設更新已經保存在上下文數據庫中，因此后續查詢將返回數據（除非在使用-writeConcern 0運行CB的情況下，如果數據庫失敗，則更新可以從數據庫內存持久保存到磁盤）。

2. 為了簡化操作，CB使用“即發即棄”通知政策。 但是，CB可以與HTTP中繼軟件（例如Rush ，事件總線等）結合使用以實現重試等。

3. 與情況1類似，如果客戶端收到2xx響應（ 在 NGSIv1的情況下在響應有效負載內部，在 NGSIv2的情況下是HTTP響應代碼），它可以假定更新已經在上下文數據庫中持久化（除了在這種情況下）使用-writeConcern 0運行CB如果數據庫失敗，則更新可以從數據庫內存持久保存到磁盤），因此這些數據的通知（由於現有訂閱或新訂閱）將使用新值。

4. 只要線程飽和 （在-notificationMode transient的情況下）或隊列飽和（ -notification threadpool:q:n ）沒有發生，就會發送所有通知。 您可以在Orion文檔中找到有關通知模式的更多信息。