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

时间:2018-06-11 15:49:10

标签: database nosql timeout aerospike acid

我是Aerospike的新手。

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

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

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

  2.   
  3. 客户端未按指定的超时(timeout =)接收响应。

  4.   
  5. 服务器在自己的处理过程中超时(默认值)   如果客户端没有指定超时,则为1秒。要研究这个,   确认服务器事务延迟不是瓶颈。

  6.   
  7. 在没有错误的M次迭代重试后,客户端超时   由于节点故障或连接失败。

  8.   
  9. N次重试后,客户端无法获取有效节点(重试次数为   从您的客户端设置。)

  10.   
  11. X重试后,客户端无法获取有效连接。重试   count通常是限制因素,而不是超时值。该   推理是,如果你在R重试后无法获得连接,那么你   永远不会,所以只是提前超时。

  12.   

在提到的所有超时情况中,在哪种情况下我可以绝对确定交易的最终结果是否失败?

如果客户没有回复,Aerospike是否提供任何内容,即回滚交易?

在最坏的情况下,如果我无法确定最终结果,我怎么能够确切知道交易的最终状态?

非常感谢提前。

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

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

你们认为有必要这样做吗?或者还有其他方式吗?

2 个答案:

答案 0 :(得分:4)

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

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

我使用的方法如下:

  1. 每个记录都需要一个列表bin,列表bin将包含最后N个事务ID。
    • 对于我的用例,我给每个客户端一个唯一的2字节标识符 - 每个客户端线程一个唯一的2字节标识符 - 每个客户端线程都有一个4字节的计数器。因此,特定的transaction-id看起来会掩盖来自2个ID和计数器的8字节标识符。
  2. *使用getHeader api读取记录元数据 - 这可以避免从存储中读取记录箱。
    • 注意 - 我的用例不是增量所以我实际上必须阅读记录并使用生成检查进行写入。对于反用例,此模式应该更有效。
  3. 使用操作和gen-equal将记录写入读取生成,并执行以下操作:增加整数bin,txns的prepend to the list trim txns列表。您将事务id添加到txns列表中,然后将列表修剪为所选列表的最大大小。
    • N需要足够大,以便记录可以确保有足够的时间来验证其在密钥争用时的事务。 N会影响记录的存储大小,因此选择太大会占用磁盘资源,选择太小会导致算法失效。
  4. 如果交易成功,那么您就完成了。
  5. 如果交易是“怀疑”的话。然后读取密钥并检查txns列表中的transaction-id。如果有,那么您的交易肯定会成功。
  6. 如果您的交易ID不在txns中,请使用步骤5中的读取返回的代数重复步骤3。
  7. 返回步骤3 - 除了步骤5 a'生成错误'还需要考虑“怀疑”的问题。因为它可能是最后的尝试最终应用。
  8. 还要考虑在步骤5中读取记录而不在txns中找到transaction-id并不能确保交易确实失败了#39;如果你想保持记录保持不变,但肯定会失败的'你需要观察一代语义超越了之前写的gen-check政策。如果它没有你可以用触摸替换步骤6中的操作 - 如果成功则初始写入肯定失败了#39;如果你得到一代错误,你将需要检查你是否参加了初始交易的申请,初步写作现在可能已经成功了。

    再次,强大的一致性'提到的绝对是成功的'并且'绝对失败了'是准确的语句,但在AP中这些语句有失败模式(特别是在网络分区周围)。

答案 1 :(得分:3)

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

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