我是Aerospike的新手。
我想知道在所有可能的超时情况中,如此链接中所述:
https://discuss.aerospike.com/t/understanding-timeout-and-retry-policies/2852
客户端无法通过指定的超时(timeout =)进行连接。超时为零 表示没有设置超时。
客户端未按指定的超时(timeout =)接收响应。
服务器在自己的处理过程中超时(默认值) 如果客户端没有指定超时,则为1秒。要研究这个, 确认服务器事务延迟不是瓶颈。
在没有错误的M次迭代重试后,客户端超时 由于节点故障或连接失败。
N次重试后,客户端无法获取有效节点(重试次数为 从您的客户端设置。)
- 醇>
X重试后,客户端无法获取有效连接。重试 count通常是限制因素,而不是超时值。该 推理是,如果你在R重试后无法获得连接,那么你 永远不会,所以只是提前超时。
在提到的所有超时情况中,在哪种情况下我可以绝对确定交易的最终结果是否失败?
如果客户没有回复,Aerospike是否提供任何内容,即回滚交易?
在最坏的情况下,如果我无法确定最终结果,我怎么能够确切知道交易的最终状态?
非常感谢提前。
编辑: 我们想出了一个临时解决方案:
保留[代 - >的地图对于该记录(可能是后台线程不断读取记录等)然后在超时时,我们会定期检查地图(键=预期的生成)以查看真实的写入值是否实际上是放在地图。如果它们相同,则表示写入成功,否则表示写入失败。
你们认为有必要这样做吗?或者还有其他方式吗?
答案 0 :(得分:4)
首先,超时不是您应该关注的唯一错误。较新的客户有一个' inDoubt'与错误相关联的标志,表示写入可能已应用或未应用。
没有一种内置的方法可以将一个不确定的交易解决为一个明确的答案,如果网络是分区的,那么在AP中没有一种方法可以严格解决不确定的交易。确实存在严格的方法,用于Strong Consistency'模式,相同的方法可用于处理常见的AP方案,但它们将在分区下失败。
我使用的方法如下:
还要考虑在步骤5中读取记录而不在txns中找到transaction-id并不能确保交易确实失败了#39;如果你想保持记录保持不变,但肯定会失败的'你需要观察一代语义超越了之前写的gen-check政策。如果它没有你可以用触摸替换步骤6中的操作 - 如果成功则初始写入肯定失败了#39;如果你得到一代错误,你将需要检查你是否参加了初始交易的申请,初步写作现在可能已经成功了。
再次,强大的一致性'提到的绝对是成功的'并且'绝对失败了'是准确的语句,但在AP中这些语句有失败模式(特别是在网络分区周围)。
答案 1 :(得分:3)
最近的客户将在超时时提供额外的标记,称为“有疑问”。如果为false,则表示您确定事务未成功(客户端甚至无法连接到节点,因此无法发送事务)。如果是,那么仍然存在不确定性,因为客户端会发送交易,但不知道它是否已到达集群。
您也可以考虑查看Aerospike的Strong Consistency功能,它可以帮助您使用案例。