Redisの分散ロックは楽観的ロックですか?

簡単に言うと、Redis は楽観的ロックを使用します。これは悲観的ロックよりも実装が簡単で、一部のシナリオではパフォーマンスが向上します。軽量で高速なキャッシュ エンジンである Redis は、フル機能を備えたリレーショナル データベースではないため、悲観的ロックを使用する必要も手頃な価格もありません。

Optimistic Lock は、その名前が示すように、非常に楽観的です。データを取得しに行くたびに、他の人はそのデータを変更しないと考えます。ロックはしませんが、更新時に他の人がこのデータを更新したかどうかを確認したり、バージョン番号などのメカニズムを使用したりできます。オプティミスティック ロックはマルチ読み取りアプリケーション タイプに適しており、スループットを向上させることができます。

楽観的ロック戦略: 更新を実行するには、送信されたバージョンがレコードの現在のバージョンよりも大きい必要があります (推奨学習: Redis ビデオ チュートリアル )

Redis のみトランザクションに対するサポートは非​​常に限定的ですが、実際には問題を回避する試みにすぎません。

まず、Redis は同じトランザクション内の一連の操作をすぐに実行するのではなく、キューに入れて、EXEC が実行されるときにまとめて実行されます。トランザクションの実行はグローバルに排他的です。つまり、同時に実行されるトランザクションは 1 つだけであり、途中で他のトランザクションによって中断されることはできません。 Redis は、競合状態を回避するために、この最も単純でパフォーマンスの悪い方法を使用します。

第 2 に、Redis トランザクションでは、1 つ以上の操作が失敗しても、他の操作は引き続き成功します。これは、ロールバック メカニズムがまったくないことを意味します。

このメソッドは多くの深刻な問題を引き起こします。その 1 つは、最初に特定の値を読み取ってから、その値に依存する操作を実行することが不可能であることです。同じトランザクションに配置しないで実行すると、競合状態が発生します。解決策は、1 つ以上の変数を監視する WATCH を使用することです。WATCH を呼び出した後、トランザクションがコミットされる前に別のトランザクションによって変数の値が変更されると、トランザクション全体が失敗します。これは、オペレーティング システムの CAS (Compare and Set) に似ています。 WATCH が具体的にどのように実装されているかはわかりませんが、指定された変数のバージョン番号を監視しているのではないかと推測しています。

WATCH を使用しても、Redis トランザクションは厳しく制限されます。まず、WATCH は読み取り操作では機能しないため、データの読み取り時に一貫性が得られません。次に、ロールバックはサポートされていません。 3 番目に、同じ変数に対して多数の同時書き込み操作がある場合、トランザクションが送信されるたびに、WATCH によって監視されている変数が変更され、トランザクションの送信が複数回失敗するため、パフォーマンスが非常に低下します。 。しかし、Redis は元々 KV 型のキャッシュ エンジンであり、大量の読み取りと少量の書き込みのシナリオに対応する必要があり、一貫性は要求されません。

Redis 関連の技術記事の詳細については、「Redis データベース チュートリアルの使用方法の概要」 列にアクセスして学習してください。

以上がRedisの分散ロックは楽観的ロックですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。