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文档中找到有关通知模式的更多信息。