0

我有一个帐户密钥，我在处理项目时会检查它。此密钥可防止我花时间处理不再有效的项目。在处理的内部循环中，我验证我仍然可以找到我正在处理的密钥。

实体定义：

class AuthorizedKey(ndb.Model):
    secret_key = ndb.StringProperty()
    ...additional fields...

我用来检查的代码：

authorized_key = AuthorizedKey.query(AuthorizedKey.secret_key == first_key).get()

first_key 是一个字符串，它与已验证且位于数据存储区中的 AuthorizedKey 实体匹配。根据密钥，它在数周或数月内没有被修改过。

此查询定期无法检索结果。大约万分之一。错误似乎分布在键之间（即问题不在于一条记录）。

关于如何摆脱这些错误的任何建议？我需要存储在 AuthorizedKey 中的信息才能准确处理请求。如果传入的数据没有密钥，我想尽快停止处理它。

更新 --- 与查询匹配的记录通常在使用前几天创建。这些记录平均存在几个月。他们已经工作了数百万次，以前存在过，并且继续存在。有时，对 get() 调用的响应是无。

虽然多条记录都出现了这个问题，但一条特定记录在创建后大约 2 天就一直被访问。几天前我刚刚在内部循环上添加了监控代码。没有返回错误信息。

"if not authorized_key:"

在上面的代码大约每 10,000 次返回 False 之后。在工作之前和之后访问。一个具有与我的论点相匹配的 secret_key 的实体已经存在了将近 8 个月，并且已成功访问了数百万次。这就是我提出问题的原因，寻求帮助。在这种情况下，我悄悄地失败了，稍后会自动重试。重试工作正常。完全一样的数据。

除了这个问题的奇怪性质之外，我担心的主要原因是：

  • 核心系统的可靠性
  • 系统的其他区域可能不会像这个区域那样优雅地退化。
4

2 回答 2

2

您正在使用非祖先查询，因此您可能会得到最终一致的结果。如果实体是相当新的，那么对它的查询可能无法显示它。

于 2012-12-12T22:27:30.970 回答
1

事实证明，这个内部处理代码是以两种模式调用的。第一种模式拉出一批并处理它们。如果批次中的项目太多，它会安排后续任务以备后用。安排后续任务时，它位于默认命名空间以外的命名空间中。

第二种模式是作为后续任务，它会继承它所在的命名空间。这意味着我现在在错误的命名空间中寻找 AuthorizedKey 而没有找到它。我的批量相当大，但不是天文数字。当一个设备非常活跃或系统负载过重时，事件可能会达到该标记，从而非常偶尔地导致错误。

谢谢大家的建议和调试帮助！

于 2012-12-13T23:48:23.033 回答