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

Question

我是 Aerospike 的新手。

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

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

1. 客户端无法通过指定的超时时间 (timeout=) 连接。超时为零意味着没有设置超时。

2. 客户端在指定的超时 (timeout=) 前未收到响应。

3. 服务器在自己的处理过程中使事务超时（如果客户端未指定超时，则默认为 1 秒）。要对此进行调查，请确认服务器事务延迟不是瓶颈。

4. 由于节点失败或连接失败而没有错误时，客户端在 M 次重试迭代后超时。

5. N 次重试后，客户端无法获得有效节点（从您的客户端设置重试）。

6. 重试 X 次后，客户端无法获得有效连接。重试计数通常是限制因素，而不是超时值。原因是，如果您在 R 重试后无法获得连接，那么您将永远不会，所以请提前超时。

在提到的所有超时情况中，在哪些情况下我可以绝对确定事务的最终结果是失败的？

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

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

提前谢谢了。

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

为该记录保留 [generation -> value read] 的映射（可能是后台线程不断读取记录等），然后在超时时，我们将定期检查映射（键 = 预期生成）以查看是否真实写入value 实际上是放在地图上的那个。如果相同，则表示写入成功，否则表示写入失败。

大家觉得有必要这样做吗？还是有其他方法？

标签： databasenosqltimeoutaerospikeacid

Answer 1

首先，超时不是您应该关注的唯一错误。较新的客户端有一个与错误关联的“ inDoubt ”标志，表明写入可能已应用或未应用。

没有一种内置的方法可以将可疑交易解决为明确的答案，如果网络是分区的，AP 中就没有办法严格解决可疑交易。'强一致性'模式确实存在严格的方法，相同的方法可用于处理常见的AP场景，但它们在分区下会失败。

我使用的方法如下：

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

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

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