Orion Context Broker 交付保证？

Question

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

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

2）如果消费者订阅了某些上下文信息，是否保证它将收到所有相关更新——恰好一次，至少一次，甚至根本没有？（例如，CB 和消费者之间出现暂时性网络故障的情况）

3）如果消费者更新了其订阅，是否能保证后续更新能够准确反映它？（例如，如果CB在确认订阅请求后立即失败，然后重新启动）

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

ETC...

谢谢！

Answer 1

逐条回答：

1. 一般来说，如果客户端收到 2xx 响应（在 NGSIv1 的情况下在响应负载内部，在 NGSIv2 的情况下在 HTTP 响应代码内），它可以假设更新已保存在上下文数据库中，因此后续查询将返回该信息数据（除了在运行 CB 的情况下，-writeConcern 0如果数据库在更新可以从数据库内存持久保存到磁盘之前发生故障）。

2. 为了让事情变得更简单，CB 使用“即发即忘”通知策略。然而，CB可以与HTTP中继软件（例如Rush、事件总线等）结合以实现重试等。

3. 与情况 1 类似，如果客户端收到 2xx 响应（在 NGSIv1 的情况下在响应负载内部，在 NGSIv2 的情况下在 HTTP 响应代码内部），则可以假设更新已保存在上下文数据库中（除了以下情况）如果数据库在更新可以从数据库内存持久保存到磁盘之前发生故障，则运行 CB-writeConcern 0的情况），因此此类数据的通知（由于现有订阅或新订阅）将使用新值。

4. 只要不发生线程饱和（在 的情况下-notificationMode transient）或队列饱和（在 的情况下），所有通知都会被发送。您可以在Orion 文档-notification threadpool:q:n中找到有关通知模式的更多信息。