database - Aerospike ACID - 如何知道超时交易的最终结果？

Question

我是 Aerospike 的新手。

我想知道在所有可能的超时情况下，如该链接所述:

https://discuss.aerospike.com/t/understanding-timeout-and-retry-policies/2852

1. Client can’t connect by specified timeout (timeout=). Timeout of zero means that there is no timeout set.

2. Client does not receive response by specified timeout (timeout=).

3. Server times out the transaction during it’s own processing (default of 1 second if client doesn’t specify timeout). To investigate this, confirm that the server transaction latencies are not the bottleneck.

4. Client times out after M iterations of retries when there was no error due to a failed node or a failed connection.

5. Client can’t obtain a valid node after N retries (where retries are set from your client).

6. Client can’t obtain a valid connection after X retries. The retry count is usually the limiting factor, not the timeout value. The reasoning is that if you can’t get a connection after R retries, you never will, so just timeout early.

在所有提到的超时场景中，在什么情况下我可以绝对确定交易的最终结果是失败的？

Aerospike 是否提供任何东西，即如果客户端没有响应则回滚事务？

在最坏的情况下，如果我不能确定最终结果，我怎么能确定交易的最终状态？

非常感谢。

编辑:我们想出了一个临时解决方案:

为该记录保留一个 [generation -> value read] 的映射(可能是后台线程不断读取记录等)，然后在超时时，我们会定期检查映射(key = 预期的生成)以查看是否真正的书面值(value)实际上是放在 map 上的值(value)。如果相同则表示写入成功，否则表示写入失败。

大家觉得有必要这样做吗？还是有别的办法？

Answer 1

首先，超时并不是您应该关注的唯一错误。较新的客户有一个'inDoubt ' 与错误关联的标志将指示写入可能已应用也可能未应用。

没有一种内置的方法可以将不确定的交易解决为确定的答案，如果网络被分区，则 AP 中没有一种方法可以严格解决不确定的交易。 ' Strong Consistency 确实存在严格的方法' 模式，可以使用相同的方法来处理常见的 AP 场景，但它们会在分区下失败。

我用过的方法如下:

1. 每条记录都需要一个列表箱，列表箱将包含最后 N 个交易 ID。
   • 对于我的用例，我为每个客户端提供了一个唯一的 2 字节标识符——每个客户端线程都有一个唯一的 2 字节标识符——并且每个客户端线程都有一个 4 字节的计数器。因此，特定的交易 ID 看起来会屏蔽 2 个 ID 和计数器中的 8 字节标识符。
2. * 使用 getHeader 读取记录元数据api - 这避免了从存储中读取记录箱。
   • 注意 - 我的用例不是增量，所以我实际上必须读取记录并使用生成检查写入。这种模式对于计数器用例应该更有效。
3. 使用操作和gen-equal 写入记录通过以下操作生成读取:增加整数 bin，prepend to the list txns 和 trim txns 列表。您会将您的交易 ID 添加到您的 txns 列表中，然后将列表修剪为您选择的列表的最大大小。
   • N 需要足够大，以便记录可以确保有足够的时间在 key 争用的情况下验证其事务。 N会影响记录的存储大小，选择太大会消耗磁盘资源，选择太小会导致算法无效。
4. 如果交易成功，那么您就完成了。
5. 如果交易“有疑问”，则读取 key 并检查 txns 列表中的交易 ID。如果存在，那么您的交易“绝对成功”。
6. 如果您的交易 ID 不在 txns 中，请使用从步骤 5 中读取返回的生成重复步骤 3。
7. 返回第 3 步 - 除了第 5 步的“生成错误”外，还需要将其视为“不确定”，因为它可能是之前的尝试最终应用的。

还要考虑到在第 5 步中读取记录并且在 txns 中找不到交易 ID 并不能确保交易“肯定失败”。如果你想保持记录不变但有一个“绝对失败”的语义，你需要观察到这一代已经超过了前一个写入的 gen-check 策略。如果没有，您可以用触摸替换步骤 6 中的操作 - 如果它成功，那么初始写入“肯定失败”，如果您遇到生成错误，您将需要检查您是否与初始交易的应用程序竞争初始写入现在可能“绝对成功”。

同样，对于“强一致性”，提及“绝对成功”和“绝对失败”是准确的陈述，但在 AP 中，这些陈述具有失败模式(尤其是在网络分区周围)。