問題タブ [distributed-lock]

私のアプリケーションでは、カスタムのキー値ストアをデータ永続化レイヤーとして使用しています。このキー値ストアは社内で開発され、使用する API がいくつかありますが、トランザクション管理やロック (特に分散ロック) に関するものは何も提供していません。

現在、このキー値ストアのユーザーとして、このようなロック/トランザクション管理システムを開発する必要があります。そのような分散ロックをどのように実装できるかを示すのを手伝ってくれる人はいますか? Apache Zookeeper は一見の価値がありますか?

Java 7 を使用しています。

ありがとう、NN

現在、分散ロックのユースケースについて apache-curator を評価しています。以下は私たちのテストケースです：

テストは、2G Xmx を搭載した 2 コア/7.5G RAM マシンで実行されます。Zookeeper インスタンス ( zook.company.com) が Xmx を 12G として 4 コア/15G RAM サーバーで実行されている間、maxClientCnxns=5000、tickTime=2000、initLimit=10、および syncLimit=5。

両方のサーバーが同じ AWS VPC に存在します。

テストを 10 分間実行すると80 ms、95% 以上のロック試行でロック取得時間が得られます。ロックの取得にかかった最大時間は でした340 ms。スレッド数とロック数のさまざまな組み合わせを試してみましたが、時間は常に高い側にあります。

どこかで何か問題があるかどうかを見つけることができませんか? 時代が高すぎるように見えるからです。手がかりはありますか??

マルチインスタンス ワーカー ロール用に、Azure 上の Redis 内に分散ロックを作成しようとしています。ワーカー ロールの複数のインスタンス間で、一度に 1 つのスレッドだけがアクセスできる「クリティカル セクション」を作成する方法が必要です。

私はこれを行うために StackExchange.Redis クライアントを使用していますが、便利なことに、TakeLock\ReleaseLock すでにtransactional の実装があり、 SO に関するこの回答は、使用するパターンとロックの作成方法の詳細についての良いアイデアを与えてくれます。

この件についてさらに読むと、distlock に関するこの Redis の記事も読みました。この記事では、分散ロック メカニズムを実装しようとするときのフェイルオーバー ベースの Redis ノードの弱点について説明しています。

Azure Redis キャッシュは (基本層とは別に) マスター/スレーブ フェールオーバーを実装していますが、これは、 1 つのものだけがロックされることを保証するために、レッドロックパターンを実装する必要があることを意味しますか?

さらに、私は疑問に思っています：

• Azure Redis の例の接続文字列にマスターとスレーブがリストされていないように見えるのはなぜですか? Azure はマスター/スレーブ フェールオーバーを別の方法で実装しましたか?
• redlock の.NET 実装の 1 つが、マスター/スレーブの使用をサポートしないことを選択したのはなぜですか? (使用法セクションの最初の段落を参照) これは単に選択によるものですか、それともマスター/スレーブが redlock の有効な使用法ではないためですか ( redis の記事ではそうではないようです)

http://redis.io/topics/distlockで、Redis を使用した分散ロックに関する投稿を読みました。「ロック解除」を行う方法を説明する lua スクリプトがあります。

このモデルには競合状態があると思います：

1. クライアント A は 3 秒の有効期限でロックを取得します。SET key randomstring1 NX PX 3000
2. スリープ 2.99 秒。
3. クライアント A はロックを解除し、上記のコードを呼び出します。
4. 条件は真です。if redis.call("get",KEYS[1]) == ARGV[1] then
5. 元のキーの有効期限が切れています
6. クライアント B は、anthor ロックを取得します。SET key randomstring2 NX PX 3000
7. クライアント A がキーを削除します。
8. クライアント B のロックがクライアント A によって削除されました。

複数のサーバーで実行される .NET アプリケーション用のDistributedLockの NuGet パッケージを入手しました。ご存じない方のために説明すると、SQL Server のアプリケーション ロック機能を利用して、異なるマシン間で簡単にロックする手段を提供します。私がそれを使ってきたものは、大丈夫でした。ただし、ロックがチェックされた順序により、ロックが解放されたときに順序が維持されるかどうか疑問に思っていました。

たとえば、アプリケーションがキューから読み取り、各メッセージを順番に処理しているとします。各メッセージが世帯に関するもので、世帯の各メッセージを順番に処理したい場合はどうでしょうか。遭遇した最初のメッセージは、DistributedLock の Acquire を使用して、アカウントが空いているかどうかを確認し、空いている場合はロックし、メッセージの処理を開始できます。次に、キュー リスナー アプリが別のサーバーで実行されていて、同じ世帯のキューから別のメッセージを読み取るとします。この場合、Acquire は世帯のロックが解放されるまで待ってから、再度ロックしてメッセージを処理します。

しかし、同じアプリを実行している 3 台目のマシンがあり、同じ世帯 ID を持つメッセージに遭遇した場合はどうなるでしょうか?

そのため、マシン #1 は世帯 ID A01 の最初のメッセージを取得し、ロックして処理を開始します。マシン #2 は、A01 のキューで 2 番目のメッセージを取得し、待機します。マシン #3 は、A01 のキューから 3 番目のメッセージを取得して待機します。

上記の場合、マシン #1 が A01 へのメッセージの処理を完了し、ロックを解放すると、A01 への 2 番目のメッセージを取得したマシン #2 が次にマシン #3 の前に実行されますか? それとも、実質的にランダムで、マシン #2 または #3 のいずれかが次のロックを取得する可能性がありますか? 秩序は保たれますか？

GAE/J でアプリケーションを開発しており、分散ロックを実装する方法を検討しています。

私の要件は、この質問とまったく同じです。 しかし、この質問は約 7 年前のものであるため、回答がまだ有効かどうかはわかりません。また、これらの回答が GAE/J で機能することがわかりません。

GAE/J で分散ロックを実装するにはどうすればよいですか?

次の状況を考えてみましょう: エンティティ A に更新要求があり、サブエンティティ AB を作成するために、A に多くの B が存在する可能性があり、各 B には一意の電子メール アドレスがあります。エンティティ A は共有エンティティであり、同じ要求が複数のサーバーで並行して発生する可能性があります (スケーラブルなマイクロサービス)。

AB を作成するには、B が A のサブ エンティティとして存在していないことを確認する必要があります (B の電子メール アドレスによる)。

この更新要求を処理するサービスは、更新を安全にするために、(一意の ID によって) A をロックする必要があります。

私の質問は、技術的なものよりも概念的なものです。

1. この場合、リソース A をロックすることは、この更新タスクのビジネス ロジックの一部ですか?

2. 検証と更新の手順を処理するミドルウェアとは別のミドルウェアにリソース ロックを配置することを検討しますか? (もう 1 つのオプションは、ロックをビジネス ロジックの一部として扱い、ビジネス ロジックを担当するミドルウェアに直接配置することです。)