考虑到Orion Context Broker的“生产”使用，我想知道Orion Context Broker在消息传递方面提供了什么样的保证 - 从生产者和消费者的角度来看？特别是，要记住各种可能的故障情况（CB故障/重启，网络瞬态故障，消费者故障/重启等），以及CB中资源拥塞的可能性。几个例子：
1）如果上下文更新操作成功，是否保证后续查询将返回最新数据（例如，即使CB在确认更新请求后立即失败，然后重新启动）？
2）如果消费者订阅了某些上下文信息，是否可以保证它会收到所有相关更新 - 只需一次，至少一次，甚至根本不会？ （例如，在CB与消费者之间发生短暂网络故障的情况下）
3）如果消费者更新了订阅，是否可以保证后续更新能够准确反映它？ （例如，如果CB在确认订阅请求后立即失败，然后重新启动）
4）如果消费者订阅了上下文更改（'onchange'，没有限制），并且生产者有多个后续更新影响同一属性，是否保证每个更改都将被发送（或者一些可能会被跳过 - 例如，由于CB需要在特定时间段内发送的通知太多，以任何特定顺序？
等...
谢谢！
答案 0 :(得分：3)
通过子弹回答子弹：
通常，如果客户端收到2xx响应（在NGSIv1的情况下为inside of the response payload，在NGSIv2的情况下为HTTP响应代码），则可以假定更新已在上下文数据库中保留，因此，后续查询将返回该数据（如果数据库发生故障，则在运行带有-writeConcern 0的CB的情况下，除非可以将更新从DB内存持久保存到磁盘）。
为了让事情变得简单，CB使用“火”并忘记＆＃34;通知政策。但是，CB可以与HTTP中继软件（例如Rush，事件总线等）结合使用，以实现重试等。
与案例1类似，如果客户端收到2xx响应（在NGSIv1的情况下为inside of the response payload，在NGSIv2的情况下为HTTP响应代码），则可以假定更新已在上下文中保留数据库（如果在更新之前DB可以从DB内存持久存储到磁盘，则运行带有-writeConcern 0的CB的情况除外），因此这些数据的通知（由于现有订阅或新订阅）将使用新价值。
只要thread saturation（在-notificationMode transient}的情况下）或队列饱和度（-notification threadpool:q:n）不发生，就会发送所有通知。您可以在Orion documentation中找到有关通知模式的更多信息。