fiware - Orion Context Broker 交付保证？

Question

考虑到 Orion Context Broker 的“生产”用法，我想知道 Orion Context Broker 在消息传递方面提供了什么样的保证——从生产者和消费者的角度来看？特别是，牢记各种可能的故障场景(CB 故障/重启、网络瞬时故障、消费者故障/重启等)，以及 CB 中资源拥塞的可能性。几个例子:

1) 如果上下文更新操作成功，是否保证后续查询将返回最新数据(例如，即使 CB 在确认更新请求后立即失败，然后重新启动)？

2)如果消费者订阅了某些上下文信息，是否可以保证它会收到所有相关更新——恰好一次，至少一次，甚至根本没有？ (例如，在 CB 和消费者之间发生瞬时网络故障的情况下)

3) 如果消费者更新了其订阅，是否保证随后的更新将准确反射(reflect)它？ (例如，如果 CB 在确认订阅请求后立即失败，然后重新启动)

4)如果消费者订阅了上下文更改('onchange'，没有限制)，并且生产者有多个影响同一属性的后续更新，是否保证将发送每个更改(或者可能会跳过一些更改) -- 例如，由于 CB 需要在特定时间段内发送太多通知)，以任何特定顺序？

等等...

谢谢!

Answer 1

逐项回答:

通常，如果客户端收到 2xx 响应(NGSIv1 的情况下为 inside of the response payload，NGSIv2 的情况下为 HTTP 响应代码)，则可以假设更新已保存在上下文数据库中，因此后续查询将返回该数据(除了在使用 -writeConcern 0 运行 CB 的情况下，如果 DB 在更新可以从 DB 内存持久化到磁盘之前失败)。

为了让事情更简单，CB 使用了“即发即忘”的通知策略。但是，CB 可以与 HTTP 中继软件(例如 Rush、事件总线等)结合以实现重试等。

与情况 1 类似，如果客户端收到 2xx 响应(在 NGSIv1 的情况下为 inside of the response payload，在 NGSIv2 的情况下为 HTTP 响应代码)，则可以假设更新已在上下文数据库中持久化(运行的情况除外) CB with -writeConcern 0 如果在更新可以从 DB 内存持久化到磁盘之前 DB 失败)，因此此类数据的通知(由于现有订阅或新订阅)将使用新值。

只要 thread saturation 就会发送所有通知(在 -notificationMode transient 的情况下)或队列饱和( -notification threadpool:q:n )不会发生。您可以在 Orion documentation 中找到有关通知模式的更多信息.