ZooKeeper 分散ロック キュレーター ソース コード 3: 再入可能ロック同時ロック

[[410513]]

序文

ロックとロックの再入を理解した後、理解すべき最も重要なことは、分散シナリオまたはマルチスレッドの同時ロックでロックをどのように処理するかということです。

1同時ロック

まずは結果を見てみましょう。複数のスレッドが /locks/lock_01 をロックしたときに、後で新しい一時ノードが作成されました。

これはロックメソッドCreateBuilderImpl#pathInForegroundで導入されました。

ここでは、/locks/lock_01 パスがすでに存在すると判断され、新しい一時シーケンス ノードが直接作成されます。

ロックが正常に取得されたかどうかの実際の判断は、LockInternals#attemptLock メソッド内の internalLockLoop メソッドで行われます。

結果のロックと監視

internalLockLoop メソッドの主な機能は、ロックの結果を決定し、ロックの取得が失敗した場合に他のノードを監視することです。

1. 親ノード /locks/lock_01 の下にあるすべての子ノードを取得し、小さいものから大きいものの順に並べ替えて、ロックを取得できたかどうかを判断します。そうでない場合は、前のノードを監視します。
2. タイムアウトの設定をサポートし、タイムアウトが発生した場合は直接失敗を返します。
3. タイムアウトがサポートされていないか、タイムアウトしていない場合、コマンドは直接待機します。

ロックを取得するためのコードはStandardLockInternalsDriver#getsTheLockにあります。

この部分は、getSortedChildrenですべてのノードがソートされているので、メソッドのリストが最小のノードであるかどうかを判断するためのものです。子供たちは命令されます。

InterProcessMutex が初期化されるときに、maxLeases は 1 に指定されます。

ここでの最終結果は、それが最小であるかどうかを判断し、最小でない場合は、pathToWatch を前のノードに設定することです。

前のノードを監視するだけで群集効果を回避できます。

なぜ待つ必要があるのでしょうか?

これは、前のノードが解放されたかどうかを監視する監視メカニズムがここにあるため、無効なスピンを防ぐためです。

これは ZooKeeper の Watcher 監視メカニズムです。ノードが解放されると、コールバックが行われ、Java の notificationAll メソッドを使用してすべての待機スレッドに通知されます。その後、ここでの while try は実行を継続し、ロックが取得されたかどうかなどを再確認します。

2 まとめ

この記事では、主に、同時実行シナリオにおける ZooKeeper に基づく分散ロック フレームワークである Curator のロック競合問題について紹介します。

理解すべき重要なポイントは次のとおりです。

1. 群集効果を回避するために、一時的なシーケンシャル ノードは、ロックが失敗した後に前のノードをリッスンします。
2. 無効なスピンを回避するために、ここでは Java の wait/notifyAll メカニズムが使用されます。
3. デフォルトのロックは公平なロックであることがわかります。

この記事はWeChatの公開アカウント「Programmer Xiaohang」から転載したもので、以下のQRコードからフォローできます。この記事を転載する場合は、プログラマーXiaohangの公式アカウントまでご連絡ください。