测验：订单的生命周期与时钟

为什么cancel_req在播放订单事件时不应该改变状态？

• 取消请求可能无法到达交易所，因此不可靠。
• 发送请求和确认取消是两个不同的事实，并且请求可能会附有结论。
• 由于cancel_req事件没有数量信息，因此无法计算其状态。
• 因为exchange在日志中留下了cancel_req，并没有对其进行处理

有 40 个订单在交易时下注时取消，在接收时下注时执行。应以什么作为事后重建和冲突应对的基础？

• 接待时间。因为我们的系统实际上就是这样处理的。
• 平均两次。因为它不偏向某一方或另一方。
• 交换时间。因为这是市场实际发生的秩序，监管也是以此为基础的。
• 申请处理时间。因为这是最终确认状态的时候。

具有相同 exec_id 的结论事件被接收两次。正确的解释是什么？

• 这是交换错误的信号，因此您必须立即断开会话并重新连接。
• 由于执行实际上发生了两次，因此数量必须添加两次。
• 这是重传或会话恢复期间经常发生的正常行为，过滤是接收方的责任。
• 这是我们的日志存储过程中的一个bug，所以我们需要重新获取日志。

在查找重复执行时，如果只统计“累计执行超过订单数量的订单”，你会错过什么？

• 部分完成的订单有所增加，但并未超过订单数量。没有警报声
• 由于更正，订单数量增加。超额判定标准将发生变化
• 执行附加到被拒绝的订单。由于状态被拒绝，因此被排除在计数之外。
• 两份合同价格不同。即使数量相同，金额也不同。

播放结束后，添加“累计成交量超过订单数量，状态为已成交”的规则，最合适的依据是什么？

• 因为执行比取消更频繁地发生，所以它在统计上是有利的。
• 由于合同是不可逆转的事实，取消仅适用于剩余金额，因此如果剩余金额为0，则取消不能消除合同。
• 这是因为交易所规定结束事件要在取消事件之前发送。
• 如果您将状态字段保留为已填写，则结算批次不会产生错误。

比较OMS状态字段和重建结果时，不同状态的情况有27例，查看交易数量时有67例。这40个差异意味着什么？

• 由于时间差是由比较参考日期不同引起的，因此当设置为同一时间点时，时间差就会消失。
• 重建代码中必须对舍入误差有一定的容忍度。
• 具有相同状态字符串但缺少执行数量的订单。只看状态的对比永远无法揭示它。
• 这些是仍在由 OMS 处理的订单，因此如果您稍后再次计数，它们将是正确的。

当实时处理器产生的状态与重建后产生的状态不同时，最现实的操作策略是什么？

• 更改实时处理器以按交换时间排序，以便两个结果始终匹配。
• 将重建后的结果设置为原始结果，并创建一个程序来使用它们校正实时结果。
• 如果两次结果不同，则订单被搁置，由负责人每次做出决定。
• 实时结果被认为是真实的，重建后仅作为参考指标。