Redis シングルスレッドをロックする必要があるのはなぜですか?

私の個人的な理解では、redis はシングルスレッドですが、複数のクライアントから同時にアクセスでき、各クライアントは 1 つのスレッドを持つことになります。クライアント アクセス間で競合が発生します。

複数のクライアントが同時に存在するため、操作のアトミック性を保証する必要があります。たとえば、銀行カードの引き落としの場合、残高の取得、判定、引き落とし、書き戻しがトランザクションである必要があり、そうでないとエラーが発生する可能性があります。

#従来の単一アプリケーションのスタンドアロン展開の場合、Java 同時実行関連のロック (ReentrantLcok や synchronized など) を相互排他制御に使用できます。 。しかし、ビジネス開発のニーズに伴い、元の単一マシンのデプロイメント システムは、サービスを同時に提供するために徐々に複数のマシンと複数の JVM にデプロイされるようになり、元の単一マシンのデプロイメントにおける同時実行制御ロック戦略が無効になってしまいました。この問題は、共有リソースへのアクセスを制御するには、JVM 間の相互排他メカニズムが必要であり、分散ロックが解決したい問題です。 (推奨学習: Redis ビデオ チュートリアル )

分散ロックの実装条件

1. 相互排他性は、単一アプリケーションと同じです。常に 1 つのクライアントだけがロックを保持できるようにするために必要です

2. 信頼性、システムの安定性を確保する必要があり、デッドロックが発生してはならない

3. 一貫性、ロックが必要です。ロックを解除できるのはロックした人だけであり、A のロックがユーザー B

によってロック解除されることはあり得ません。Redis は分散ロックを実装しています。人によって実装ロジックが異なる場合があります。

分散環境では、データの一貫性の問題は常に重要なトピックですが、それは単一プロセスの状況とは異なります。分散環境とスタンドアロン環境の最大の違いは、それがマルチスレッドではなくマルチプロセスであることです。マルチスレッドはヒープ メモリを共有できるため、メモリをマークの保存場所として使用するだけで済みます。プロセスは同じ物理マシン上にない場合もあるため、タグはすべてのプロセスが認識できる場所に保存する必要があります。

一般的なフラッシュ セール シナリオでは、注文サービスの複数のインスタンスがデプロイされます。たとえば、フラッシュ セール製品が 4 つある場合、最初のユーザーは 3 つを購入し、2 番目のユーザーは 2 つ購入します。理想的には、最初のユーザーが正常に購入でき、2 番目のユーザーには購入が失敗したことを示すメッセージが表示され、その逆も同様です。実際に起こる可能性があるのは、両方のユーザーが 4 個の在庫を取得し、最初のユーザーが 3 個を購入することです。在庫を更新する前に、2 番目のユーザーが 2 個の品目を注文し、在庫を 2 に更新すると、エラーが発生します。

一般的なロック スキームは次のとおりです。

データベースに基づいて分散ロックを実装します

キャッシュに基づいて、redis などの分散ロックを実装します

Zookeeper に基づく分散ロックの実装

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

以上がRedis シングルスレッドをロックする必要があるのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。