Orion Context Broker 交付保证？
Orion Context Broker delivery guarantees?
考虑到 'production' Orion Context Broker 的使用，我想知道 Orion Context Broker 在消息传递方面提供了什么样的保证——从生产者和消费者的角度来看？特别要记住各种可能的故障场景（CB failure/restart、网络瞬时故障、消费者 failure/restart 等），以及 CB 中资源拥塞的可能性。几个例子：
1) 如果上下文更新操作成功，是否保证后续查询将 return 最新数据（例如，即使 CB 在确认更新请求后立即失败，然后重新启动）？
2) 如果消费者订阅了某些上下文信息，是否可以保证它会收到所有相关更新——恰好一次、至少一次，或者甚至根本没有？ （例如，在 CB 和消费者之间出现暂时性网络故障的情况下）
3) 如果消费者更新了订阅，能否保证后续更新会准确反映出来？ （例如，如果 CB 在确认订阅请求后立即失败，然后重新启动）
4) 如果消费者订阅上下文更改（'onchange'，无节流），并且生产者有多个后续更新影响同一属性，是否保证每个更改都将被以任何特定顺序发送（或者某些可能被跳过——例如，由于 CB 在特定时间段内需要发送的通知太多）？
等...
谢谢！
逐条回答：
通常，如果客户端收到 2xx 响应（inside of the response payload 在 NGSIv1 的情况下，HTTP 响应代码在 NGSIv2 的情况下）它可以假设更新已被持久化在上下文数据库中，因此后续查询将 return 该数据（如果 运行 CB 与 -writeConcern 0 的情况除外，如果数据库在更新可以从数据库内存保存到磁盘之前失败）。
为了让事情更简单，CB 使用了 "fire and forget" 通知政策。但是CB可以结合HTTP中继软件（如Rush、事件总线等）来实现重试等
与情况 1 类似，如果客户端收到 2xx 响应（inside of the response payload 在 NGSIv1 的情况下，HTTP 响应代码在 NGSIv2 的情况下）它可以假设更新有已保存在上下文数据库中（如果数据库在更新可以从数据库内存保存到磁盘之前失败，则 运行 CB 和 -writeConcern 0 除外），因此此类数据的通知（由于现有的订阅或新订阅）将使用新值。
只要thread saturation (in the case of -notificationMode transient) or queue saturation (-notification threadpool:q:n) don't occur. You can find more information about notification modes in Orion documentation.
考虑到 'production' Orion Context Broker 的使用，我想知道 Orion Context Broker 在消息传递方面提供了什么样的保证——从生产者和消费者的角度来看？特别要记住各种可能的故障场景（CB failure/restart、网络瞬时故障、消费者 failure/restart 等），以及 CB 中资源拥塞的可能性。几个例子：
1) 如果上下文更新操作成功，是否保证后续查询将 return 最新数据（例如，即使 CB 在确认更新请求后立即失败，然后重新启动）？
2) 如果消费者订阅了某些上下文信息，是否可以保证它会收到所有相关更新——恰好一次、至少一次，或者甚至根本没有？ （例如，在 CB 和消费者之间出现暂时性网络故障的情况下）
3) 如果消费者更新了订阅，能否保证后续更新会准确反映出来？ （例如，如果 CB 在确认订阅请求后立即失败，然后重新启动）
4) 如果消费者订阅上下文更改（'onchange'，无节流），并且生产者有多个后续更新影响同一属性，是否保证每个更改都将被以任何特定顺序发送（或者某些可能被跳过——例如，由于 CB 在特定时间段内需要发送的通知太多）？
等...
谢谢！
逐条回答：
通常，如果客户端收到 2xx 响应（inside of the response payload 在 NGSIv1 的情况下，HTTP 响应代码在 NGSIv2 的情况下）它可以假设更新已被持久化在上下文数据库中，因此后续查询将 return 该数据（如果 运行 CB 与
-writeConcern 0的情况除外，如果数据库在更新可以从数据库内存保存到磁盘之前失败）。为了让事情更简单，CB 使用了 "fire and forget" 通知政策。但是CB可以结合HTTP中继软件（如Rush、事件总线等）来实现重试等
与情况 1 类似，如果客户端收到 2xx 响应（inside of the response payload 在 NGSIv1 的情况下，HTTP 响应代码在 NGSIv2 的情况下）它可以假设更新有已保存在上下文数据库中（如果数据库在更新可以从数据库内存保存到磁盘之前失败，则 运行 CB 和
-writeConcern 0除外），因此此类数据的通知（由于现有的订阅或新订阅）将使用新值。只要thread saturation (in the case of
-notificationMode transient) or queue saturation (-notification threadpool:q:n) don't occur. You can find more information about notification modes in Orion documentation. 就会发送所有通知