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

我是Aerospike的新手

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

客户端无法通过指定的超时（超时=）进行连接。零超时 表示没有设置超时

客户端在指定的超时（timeout=）之前未收到响应

服务器在自己的处理过程中超时事务（默认值 如果客户端未指定超时，则为1秒）。为了调查这个,， 确认服务器事务延迟不是瓶颈

在没有错误的情况下，客户端在M次重试后超时 由于节点故障或连接故障

客户端在N次重试后无法获得有效节点（其中重试次数为 从您的客户处设置）

客户端在重试X次后无法获得有效连接。重试 计数通常是限制因素，而不是超时值。这个 理由是，如果在重试后无法获得连接，则 永远不会，所以只要早点休息就好了

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

Aerospike是否提供任何服务，例如，如果客户不响应，则回滚交易

在最坏的情况下，如果我不能确定最终结果，我如何能够确定事务的最终状态

非常感谢

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

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

---

你们认为有必要这么做吗？或者有其他方法吗？

最近的客户端将在超时时提供一个额外的标志，称为“有疑问”。如果为false，则确定事务未成功（客户端甚至无法连接到节点，因此无法发送事务）。如果为true，则仍然存在不确定性，因为客户端本来会发送事务，但不知道它是否已到达集群

---

你也可以考虑Survipkes的特性，这对你的用例有帮助。

首先，超时不是你应该关注的唯一错误。较新的客户端具有与错误关联的“”标志，该标志将指示可能已应用或未应用写操作

没有一种内置的方法来解决有疑问的交易，从而得到一个明确的答案，如果网络被划分，AP中也没有一种方法来严格解决有疑问的交易。“”模式确实存在严格的方法，相同的方法可用于处理常见AP场景，但在分区下它们将失败

我采用的方法如下：

每个记录都需要一个列表箱，列表箱将包含最后N个事务ID。

• 对于我的用例，我给每个客户机一个唯一的2字节标识符-每个客户机线程一个唯一的2字节标识符-每个客户机线程有一个4字节计数器。因此，一个特定的事务id看起来像是从2个id和计数器中屏蔽一个8字节的标识符

*使用api读取记录元数据-这避免了从存储中读取记录箱。

• 注意-我的用例不是一个增量，所以我实际上必须读取记录并使用生成检查进行写入。对于计数器用例，这种模式应该更有效

使用operate写入记录，并使用以下操作将其写入读取生成：递增整数bin、TXN的值和TXN的列表。您将在txns列表前添加事务id，然后将列表修剪为所选列表的最大大小。

• N需要足够大，以便在密钥争用的情况下，记录可以确保有足够的时间验证其事务。N将影响记录的存储大小，因此选择太大将消耗磁盘资源，选择太小将使算法无效

如果交易成功，那么您就完成了

如果事务为“inDoubt”，则读取密钥并检查txns列表中的事务id。如果存在，则您的事务“肯定成功”

如果您的事务id不在txns中，请使用步骤5中读取返回的生成重复步骤3

返回步骤3-除了步骤5中的“生成错误”也需要被视为“可疑”，因为它可能是最后应用的前一次尝试

还考虑在步骤5中读取记录，而不是在TXNS中找到事务ID，并不能确保事务“肯定失败”。如果您想保持记录不变，但有一个“肯定失败”的语义，那么您需要观察到生成经过上一次写入的gen-check策略。如果没有，您可以用触摸替换步骤6中的操作-如果成功，则初始写入“肯定失败”，如果出现生成错误，则需要检查您是否已完成初始事务的应用程序初始写入现在可能“肯定成功”

---

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

感谢您的提醒。我找到了“怀疑”字段。这将大大缩小问题的范围。关于强一致性，我在社区版上，因此