【问题标题】:Aerospike ACID - How to know the final result of the transaction on timeouts?Aerospike ACID - 如何知道超时事务的最终结果?
【发布时间】:2018-06-11 15:49:10
【问题描述】:

我是 Aerospike 的新手。

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

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

  1. 客户端无法在指定的超时 (timeout=) 内连接。超时为零 表示没有设置超时。

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

  3. 服务器在它自己的处理过程中超时事务(默认 如果客户端未指定超时,则为 1 秒)。为了调查这件事, 确认服务器事务延迟不是瓶颈。

  4. M 次重试后客户端超时,但没有错误 由于节点故障或连接失败。

  5. 客户端在 N 次重试后无法获得有效节点(其中重试次数为 从您的客户那里设置)。

  6. 客户端在 X 次重试后无法获得有效连接。重试 count 通常是限制因素,而不是超时值。这 推理是,如果您在 R 重试后无法获得连接,您 永远不会,所以早点超时。

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

Aerospike 是否提供任何服务,例如在客户端不响应时回滚事务?

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

提前非常感谢。

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

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

你们认为有必要这样做吗?还是有其他办法?

【问题讨论】:

标签: database nosql timeout aerospike acid


【解决方案1】:

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

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

我用过的方法如下:

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

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

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

【讨论】:

    【解决方案2】:

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

    您还可以考虑查看 Aerospike 的 Strong Consistency 功能,它可以帮助您的使用案例。

    【讨论】:

    • 感谢您的提醒。我找到了“有疑问”的领域。这将大大缩小问题的范围。关于强一致性,我在社区版本上,所以没有提供。我稍后会调查它。谢谢。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-01-02
    • 2014-09-07
    • 1970-01-01
    • 2011-04-14
    相关资源
    最近更新 更多