1

Djangos ORM を使用して、メッセージ キューからジョブを取得するいくつかのワーカーでシステムを実行しています。あるケースでは、あるワーカーから別のキュー内の別のワーカーにメッセージを実際に渡しています。それはこのように動作します：

  • queue1 の Worker1 がオブジェクト (MySQL INSERT) を作成し、メッセージを queue2 にプッシュします。
  • Worker2 は queue2 で新しいメッセージを受け取り、Djangos の objects.get(pk=object_id) を使用してオブジェクト (MySQL SELECT) を取得します。

これは最初のメッセージで機能します。しかし、2 番目のメッセージ ワーカー 2 では、id object_id を持つオブジェクトが見つからないという理由で常に失敗します (Django の例外 DoesNotExist を使用)。

これは、Django 1.2.3 と MySQL 5.1.66 を使用したローカル セットアップでシームレスに動作します。問題は、Django 1.3.1 と MySQL 5.5.29 を実行するテスト環境でのみ発生します。

worker1 がメッセージをプッシュする前に毎回 worker2 を再起動すると、正常に動作します。これは、ある種のキャッシングが行われていると私に信じさせます。

これらのバージョン間で異なる Django の objects.get() に関連するキャッシュはありますか? その場合、何らかの方法でクリアできますか？

4

1 に答える 1

1

この問題は、MySQL トランザクションの使用に関連している可能性があります。送信者のサイトでは、受信者に読み取るアイテムを通知する前に、トランザクションをデータベースにコミットする必要があります。受信者側では、送信者のコミット後にセッションで新しいデータが表示されるように、セッションに使用されるトランザクション レベルを設定する必要があります。

デフォルトでは、MySQL はREPEATABLE READ分離レベルを使用します。これにより、複数のプロセスがデータベースに対して読み取り/書き込みを行う場合に問題が発生します。考えられる解決策の 1 つは、次のようなオプションを使用して、Djangosettings.pyファイルで分離レベルを設定することです。DATABASES

'OPTIONS': {'init_command': 'SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED'},

ただし、トランザクション分離レベルを変更すると、特にステートメント ベースのレプリケーションを使用している場合に、別の副作用が生じる可能性があることに注意してください。

次のリンクは、より有用な情報を提供します。

于 2013-04-23T12:48:30.010 に答える