1.背景
最近の研究を飼育係、接触飼育係の初めに、飼育係が使用だか分かりません。飼育係は、情報がたくさんあると私は一緒に困難と分散型クラスのUnix / Linuxのファイルシステムアプリケーションを飼育係になる原因、「クラスのUnix / Linuxファイルシステム」ミドルウェアとして説明します。
その後ラフ読む「ZooKeeperの分散、協調プロセス技術が説明」と二冊の本「の原則と実践に配布パクシ島の飼育係からの一貫性」であり、一定の理解のためのハンズCURDデモ、予備飼育係の数を書きました。
ベースの分散ロック飼育係の実装 - しかし、より多くの表面的には、さらに飼育係の理解を深めるために、私は、対応するデモこの記事を書くために自由な時間を使います。分散ロック・デモを書いて、私は飼育係のメカニズムをウォッチャすることにより、飼育係は、その上での使用をよりよく理解していると。
しかし、私は、分散ロックは、非常に簡単であるだけ参考のために、美しく、ちょうど練習を達成するのに十分ではありません書きました。さて、余談はここで停止し、その後、私たちは、飼育係分散ロックベースの実装について話しています。
2.排他ロックとロックの実装を書きます
私はあなたが、実装のプロセスを理解するために、対応するフローチャートと一緒に排他ロックを説明し、詳細な導入プロセスをロックし、書き込み、およびます。ここでは排他ロックの実現について話をします。
2.1排他ロックの実装
また、排他ロック排他ロックとして知られ、文字通りの意味から自分の目的を理解するのは簡単です。アクションは、リソースへのアクセスをロックするプロセスのO1前R1は、リソースR1に動作O1アクセスの終了時に、他の操作がリソースR1にアクセスすることを許可されていない場合には、です。排他ロックのより簡単な定義である、これは飼育係の「クラスのUnix / Linuxファイルシステム」構造にそれをどのように達成するかの定義は？答えをロックする前に、私たちは写真を見て：
上記のようにロックリソースはR1、ノードロックを作成するために、O1のアクセスリソースを操作すると見られ、R1は、ノードと見られてロック解除リソースR1を削除するノードとして、排他ロックのために、私たちは見ることができます。このようにして、我々は排他ロック飼育係の定義になりますロックノードを作成することで、ロックを取得し、特定のノード構造に対応し、ノードのリリースにロックを削除します。次のように詳細なプロセスは以下のとおりです。
-
複数のクライアントが競争を作成するために、一時的なノードをロック
-
ここで、クライアント・ノードが正常にロックを作成し、他のクライアント・ノードは、ウォッチャーロックするように設定されている3
-
ロッククライアントノードロックを保持しているか、クライアントがクラッシュを削除し、ノードロック飼育係を削除
-
他のクライアントはロック削除したノードを通知しました
-
ロックの獲得を待つことなく、クライアントまで、上記の4つのステップを繰り返します
すなわち、排他ロックに上記の特定の実装手順、それは非常に複雑ではありません、ここでは繰り返しません。
2.2読み書きロックの実装
排他ロックを達成した、とこの祭りは、ロックを読み書きすると言われています。ロックおよびリソースR1プラス操作O1上に書込ロックを含む読み書きロックがロックを読み取り、ロックが取得され、他の操作が同時に資源R1のロックを読み取ることができる読み取り動作を共有、提供されます。
操作O1 R1プラスリソースの書き込みロックとは、ロックを取得した場合、他のオペレーティング・リソースR1は、ロックのさまざまな種類がブロックされている設定しました。結論として、共有読み取りロックと、排他的な書き込みロックのに対し。だから、飼育係に、我々は、上記の動作は、ノード構造の種類を行い達成することができますか？
飼育係、原因の読み書きや排他ロックするために異なるノードへの構造では、読み書きロッククライアントは競争を作成するために、ノードをロックする必要はありませんでした。だから、最初に、すべてのクライアントは、独自のロックノードを作成します。何も、すべてのノードが正常にロックを作成することはできません場合は、ロックケースは、図3ノード構造に示されています。その後、クライアントは最後からすべての子ノード/ share_lock飼育係を取得し、取得した独自のロックかどうかを決定します。クライアントは、次のように（会うことができるそのうちの一つ）のロック状態を取得する読み取りロックノードを作成する場合：
-
あなたが他のすべての子ノードの前に列を作成するノード番号
-
あなたが書き込みロックフリーノードを作成したノードの前で
クライアントは、排他的な書き込みロックによる書き込みロックのノードを、作成した場合。だから、シンプルにするためのロック状態を取得し、ちょうどすることができ、他の子ノードの前で自分の行を作成するかどうかを判断するためにノードをロックします。
不同于独占锁，读写锁的实现稍微复杂一下。读写锁有两种实现方式，各有异同，接下来就来说说这两种实现方式。
读写锁的第一种实现
第一种实现是对 /sharelock 节点设置 watcher，当 /sharelock 下的子节点被删除时，未获取锁的客户端收到 /share_lock 子节点变动的通知。在收到通知后，客户端重新判断自己创建的子节点是否可以获取锁，如果失败，再次等待通知。详细流程如下：
-
所有客户端创建自己的锁节点
-
从 Zookeeper 端获取 /sharelock 下所有的子节点，并对 /sharelock 节点设置 watcher
-
判断自己创建的锁节点是否可以获取锁，如果可以，持有锁。否则继续等待
-
持有锁的客户端删除自己的锁节点，其他客户端收到 /share_lock 子节点变动的通知
-
重复步骤2、3、4，直至无客户端在等待获取锁了
上述步骤对于的流程图如下：
上面获取读写锁流程并不复杂，但却存在性能问题。以图3所示锁节点结构为例，第一个锁节点 host1-W-0000000001 被移除后，Zookeeper 会将 /share_lock 子节点变动的通知分发给所有的客户端。
但实际上，该子节点变动通知除了能影响 host2-R-0000000002 节点对应的客户端外，分发给其他客户端则是在做无用功，因为其他客户端即使获取了通知也无法获取锁。所以这里需要做一些优化，优化措施是让客户端只在自己关心的节点被删除时，再去获取锁。
读写锁的第二种实现
在了解读写锁第一种实现的弊端后，我们针对这一实现进行优化。这里客户端不再对 /share_lock 节点进行监视，而只对自己关心的节点进行监视。还是以图3的锁节点结构进行举例说明，host2-R-0000000002 对应的客户端 C2 只需监视 host1-W-0000000001 节点是否被删除即可。
HOST3-W-0000000003 C3対応クライアントのみHOST2-R-0000000002ノードのみHOST2-R-0000000002ノードを除去することができるかどうかを監視し、ロックを取得するためのクライアントC3を削除します。そして、通知がホスト1-W-0000000001のノードを削除され、クライアントによって生成されたC3は、この通知に応じて、クライアントC3は、ロックを取得することができない場合でも、無用です。
ここで要約、関係するロックノード異なるクライアントが異なっています。クライアントは、読み取りロック・ノードを作成する場合、クライアントは単にノード番号が書き込みロックノードの最後の読み取りロックよりも小さい見つける必要がある、とあなたはウォッチャーを設定することができます。そして、それが唯一のセットウォッチャー缶の一方のノードの書き込みロックノード、さらに簡単に、クライアントですか。次のようにプロセスの詳細は以下のとおりです。
-
すべてのクライアントは、独自のロックノードを作成します
-
エンド飼育係からすべての子ノード/ share_lockを取得
-
あなたは、ロックを保持することができれば、独自のロックを作成するかどうかを判断するためにロックノードは、取得することができます。それ以外の場合は、あなたが気に監視ノードをロックするように設定されています
-
自分のロックを削除するには、ロッククライアントノードを保持し、クライアントは、ノードが削除された通知を受信して、ロックを取得します
-
ロックの獲得を待つことなく、クライアントまで、ステップ4を繰り返します
次のようにフローチャートの上記手順のためのものです。
3.最後に書かれました
この記事では詳細に飼育係分散ロックに基づいて実装プロセスを説明し、2つの原則に基づいて、より単純な分散ロックデモを達成するためのコードが必要にgithubの、友人の上に置かれ、求めて、上記ロック。
これは単純なデモですので、コードの実装は、参照のみを目的として、綺麗ではありません。最後に、あなたはかなり良い記事を感じる場合は、親指を歓迎します。そこにそれと間違って何もありませんが、またお気軽にお尋ねした場合、私は謙虚に訂正されます。