0

アイテムを処理するときにチェックするアカウント キーがあります。このキーにより、有効でなくなったアイテムに時間を費やすことができなくなります。処理中の内側のループで、作業中のキーがまだ見つかることを検証します。

エンティティ定義:

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

チェックに使用しているコード:

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

first_key は、検証済みでデータストアにある AuthorizedKey エンティティに一致する文字列です。キーによっては、数週間または数か月間変更されていません。

このクエリは定期的に結果の取得に失敗します。だいたい1万回に1回。エラーはキー間で分散しているように見えます (つまり、問題は 1 つのレコードだけにあるわけではありません)。

これらのエラーを取り除く方法について何か提案はありますか? リクエストを正確に処理するには、AuthorizedKey 内に保存されている情報が必要です。キーを持たないデータが入ってくる場合は、できるだけ早く処理を停止したいと考えています。

更新 --- 通常、クエリに一致するレコードは、使用される数日前に作成されます。これらの記録は、平均して数か月間維持されています。それらは何百万回も機能し、以前から存在し、存在し続けています。場合によっては、get() 呼び出しに対する応答が None になることがあります。

複数のレコードでこの問題が発生していますが、特定の 1 つのレコードは、作成後約 2 日から一貫してアクセスされています。数日前に内側のループに監視コードを追加しました。エラー メッセージは返されません。

"if not authorized_key:"

上記のコードが約 10,000 回に 1 回 False を返した直後。作品前後のアクセス。私の主張と一致する secret_key を持つエンティティは、わずか 8 か月間しか存在せず、何百万回も正常にアクセスされています。これが私の質問の理由であり、助けを求めることです。この場合、静かに失敗し、後で自動的に再試行します。再試行は正常に機能します。まったく同じデータです。

この問題の奇妙な性質は別として、私がこれについて心配している主な理由は次のとおりです。

  • 基幹システムの信頼性
  • システムの他の領域は、これほど適切に劣化していない可能性があります。
4

2 に答える 2

2

非祖先クエリを使用しているため、結果整合性のある結果が得られる可能性があります。エンティティがかなり新しい場合、そのエンティティに対するクエリはそれを表示できない可能性があります。

于 2012-12-12T22:27:30.970 に答える
1

この内部処理コードは2つのモードで呼び出されたことがわかります。最初のモードはバッチをプルして処理します。バッチ内のアイテムが多すぎる場合は、後でフォローアップタスクをスケジュールします。フォローアップタスクがスケジュールされている場合、それはデフォルト以外のネームスペースにあります。

2番目のモードは、キューに入れられた名前空間を引き継ぐフォローアップタスクとしてです。これは、間違った名前空間でAuthorizedKeyを探しているのに、見つからないことを意味します。私のバッチサイズはかなり大きかったが、天文学的なものではなかった。1つのデバイスが非常にアクティブな場合、またはシステムの負荷が高い場合、イベントがそのマークに到達し、エラーが散発的に発生する可能性があります。

提案とデバッグのヘルプをありがとうございました！

于 2012-12-13T23:48:23.033 に答える