Orion上下文經紀商交付保證？

Question

關於Orion上下文代理的'生產'使用的思考，我想知道Orion上下文代理在消息傳遞方面提供了什麼樣的保證 - 從生產者和消費者的角度來看？特別是要記住各種可能的故障情況（CB故障/重啓，網絡瞬時故障，用戶故障/重啓等）以及CB中資源擁塞的可能性。幾個例子：

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

2）如果消費者訂閱了某些上下文信息，是否保證它會收到所有相關的更新 - 至少一次，至少一次，甚至根本不會？ （例如，如果CB和消費者之間暫時出現網絡故障）

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

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

etc ...

謝謝！

Answer 1

接聽子彈由子彈：

1. 一般來說，如果客戶端接收（在NGSIv1，在NGSIv2的情況下的HTTP響應碼的情況下inside of the response payload）一個2xx響應它可以假設該更新具有被保留在上下文數據庫中，所以後續查詢將返回該數據（除非在更新可以從DB內存持久保存到磁盤之前DB運行失敗的情況下運行CB時使用-writeConcern 0）。

2. 爲了使事情更簡單，CB使用「隨時待命」通知政策。然而，CB可以與HTTP中繼軟件，以便執行重試組合（例如Rush，事件總線，等）等。

3. 到外殼1中，如果客戶端接收的情況下的2xx應答（inside of the response payload類似NGSIv1的HTTP響應代碼，NGSIv2的情況下的HTTP響應代碼），它可以假定更新已經保存在上下文數據庫中（除非在更新可以從DB內存持續到磁盤之前DB運行失敗的情況下運行CB，-writeConcern 0） ，所以此類數據的通知（由於現有訂閱或新訂閱）將使用新值。

4. 所有通知只要將發送爲thread saturation（在-notificationMode transient的情況下）或隊列飽和度（-notification threadpool:q:n）不會發生。您可以在Orion documentation中找到有關通知模式的更多信息。