分散 - 分散ロック - コードワールド

ディレクトリ

序文
冪等
ロック属性
分散ロック
設計目標
デザインのアイデア
境界条件
デザインのポイント
異なる実装
結論

序文

私は突然の歴史の中で繁栄を考え、想像力は本当に長寿命を確保したい呼び出すことができます感じたが、ほとんどは3〜4年、どのように我々は3、4年の間でなければならない生活の中で大きな時間を（確保することができますが、本当に未来が良くなっていることを願って、一般的な傾向が優れている、個人も）良いことがあります。安定した仕事は、自分の愛する人は、ちょっと贅沢を感じ、自分自身を愛しています。私は過去を振り返るますゆっくりと、おそらく目の点滅しますこれらは生命の種で発見され知っており、これらのものの選択が自由でないことがわかったが、時間駆動型です。年齢とともに、より多くの過去とより多くの当然の結論の小さな物事の感触、および以下の選択肢の将来だけでなく、あまりオプションなどがあります。
まあ、自宅にクローサー、それはCAPを終えることが最後だっただろう、かなり良い書き込み、多くの情報を確認感じました。今で書かれているものを、振り返ります！それとも愚かな脳は、理解するのが遅い遅いものの一つは、すぐに人のようなものを忘れていることを覚えておいてください。それでは、どのように言っていない。この考えるかまあ、少なくとも最後に良いより。はい、1に私は最初に言うためにフラグを設定し、詳細に補充する時間を持っています。

冪等

定義

リソースのプライマリと複数の要求：HTTP / 1.1の冪等することと定義されるリソース自体の（ネットワークタイムアウトの問題を除く）と同じ結果を有するべきです。機能語によって表される（F（x）は、f .... Fである）= F（X）。

目的

1.の重要な（例えば、トランザクション、転送）をもたらす壊滅的な結果は、操作を再試行要求しないようにするには。

冪等の範囲

リクエスト

1.読み出し要求-生まれの冪等
2.書き込み要求-非冪等を制御する必要があります。

データベースレベル

1.INSERT--非冪等は、コンテンツによって制御する必要があります。
WHERE条件2.UPDATE--冪等を制御することにより、相対値の操作を最小限にします。COLUMN1 = COLUMN1 + 1のUPDATE TABLE1のSET ; COLUMN2 = 2
、各実行の結果が変化し、これは冪等ではありません。UPDATEのTABLE1セットCOLUMN1 = 1 COLUMN2 = 2; どんなに状態の成功の実装が同じ回数、したがって電力および他の操作。
また3.DELETE-- WHERE条件を制御することにより、相対値の操作を最小限にします。もし
COLUMN1 <今（）DELETE TABLE1 ; WHERE column1の< "2019年10月1日" TABLE1をDELETEお読みください。より良いです。

運用レベル

冗長展開複数のサービスは、同時要求の消費量の存在は、シリアル変換するパラレルによって要求される必要がある場合には1。

電源や他の戦略の保証

冪等本質はシリアル処理リソースを行うことであることを確認し、そのような直列化は多面的です。
言うまでもなくクエリは、新しい要求が抗重いプロセスの重要な特性を制御するために行う必要がある、楽観的ロックにより、更新要求を十分に制御することができます。
分散ロックの並列処理によってシリアル化分散システムを要求します。

ロック属性

1.リエントラント/非リエントラント

リエントラント：同じスレッドのロック機能を得た後層、内部コードを含む機能がロックを取得する影響を受けず、ロックが再び適用する必要はなく、それは直接呼び出すことができます。
非リエントラント：逆同書を、私たちは同じ内部を取得し、実行前にロックするスレッド外でなければなりません。これは、簡単にデッドロックにつながることができます。
彼らは、同期とリエントラントロックReentrantLockのさ

2.フェア/不公平

フェア：最初の最初に来る消費者ロックで構成されるロックキューのスレッドを要求し、役立ちました。
非エクイティ：ロックの取得を待機しているキューの末尾に投げ取得しないように最初の要求、実現への要求を、ロックします。
同期不公平
ReentrantLockのオプション

3.読み取り/書き込み

人が読むことができますが、リードロックを読んだときに、書きません：ロックをお読みください。
ロックを書く：あなたは、読み取り、書き込み、および一人だけ、書き込みロックできない場合に記述します。

4.共有/独占

排他ロック：1つのスレッドだけがロックを保持しているが、ミューテックスReentrantLockのは、排他的に実装されています。独占は、ペシミスティック・ロック・ストラテジーです。
共有ロック：ロックは、ReadWriteLockなどの複数のスレッドによって保持することができます。複数のスレッドが同時に共有リソースへのアクセスを読むことができますリラックスロック戦略。
注：AQS（AbstractQueuedSynchronized）は、排他モード（排他的）と共有モード（共有）は、2つの異なる同期論理を提供します。

5.割り込み/非割り込み

割り込み：ロックの操作が中断することができます。ReentrantLockのが中断されること。
中断することはできません：上記とは対照的。中断することはできません同期ロック。

分散ロック

特定の非同一システム内の共有リソースのマルチプロセス環境下で相互に排他的なアクセスを確保します。エッセンスは、繰り返しを避けるために、リソース要求によってシリアライズされます。しかし、問題が解決しないべき等の要求はまだ冪等ビジネスコードで制御する必要があります。私たちは、ロック情報を格納するために使用する外部システム、共有ストレージサーバーを作成する必要があります。

設計目標

セキュリティのプロパティ

1. 相互に排他的。かかわらず、任意の時間に1つのクライアントだけが同じロックを保持しているが存在することができます。そのロックは、強力なグローバル一貫性の存在です。
2. デッドロックロックの故障メカニズムと、。まず、自身が高可用性システムロックサービス、堅牢なシステムを提供します。マルチサービス・ノードは、任意のノードがクラッシュまたはネットワークパーティションは、ロックへのアクセスには影響を与えません。第二は、自動更新と自動解除ロックのクライアントです。
3. 対称同じロックとクライアントのロックを解除しなければなりません任意のロックのため、。

効率プロパティ

1. フォールトトレラント、高可用性、高パフォーマンス。サービス自体可用性の高い、堅牢なシステム。マルチサービス・ノードは、任意のノードがクラッシュまたはネットワークパーティションは、ロックへのアクセスには影響しません。
2. リエントラント効果的にデッドロックの発生を低減することができ、。
3.マルチ選択、あなたはロックを取得時刻にしようとするかを選択することができます。
4.クライアントは、単純な呼び出します。ロックコードは非常に抽象的、ミニマルなサービスへのアクセスが必要です。

デザインのアイデア

共有リソースの1制御。リソースは独自のプロセスに制御することができるように、キー識別子は、リソースのロックとして使用することができます。
唯一の制御2つのロック。ロックが解除されたときに、別のプロセスによって解放されたロックを回避するために、条件として、単一の一意の識別子（値）を取得するためのプロセスでロックされます。また、分析とは、アトミック・デル・オペレーションは、誤って削除の動作を防ぐことを確認する必要があります。通常、スクリプトをLUA。
3.避けるプロセスがロックを実行していない解放され、リソースが並列にアクセスされます。未完の仕事のロックを回避タイムリーな更新プロセスは、解放されます。
4.デッドロックを防ぎます。定期的なリリースロック、リリースタイムを設定します。

境界条件

1.ロック登録されているサービス自体、安定性と一貫性を提供します。
2.ロックが期待通りに更新することができませんでした。ハートビート更新が成功しなかったような、サービスはように効果的な時間ロックを超え、サービス中断時間の間、GC、GCを開始します。
3.事業は、アニメーションを停止し、TTLが続行されます。

デザインのポイント

1.ロック登録。ロックレジスタがアトミックであることを確認し、即ち、ロック・レジスタがあるか否かを判断し、直列化されます。
ロックの2リニューアル。どのように最小のビジネスコードの侵入の場合には、リースの更新をロックします。CASの原子。
3.ロックを解除します。ユーザロックは唯一の開催彼らのロックを解放します。

異なる実装

Redisの実現

原則

1.シングル・インスタンスの実装原理

固有のシリアル処理Redisのスレッドは、すなわち、システム自体は、線形冪等です。しかし、これは単一障害点を持つことになります。Redisのは、マスタースレーブモードを使用する場合は、Redisのレプリケーションは非同期なので、そこになりますので。

1.客户端A在master节点获取到锁。
2.master节点在将信息写入slave之前宕机。
3.slave被提升为master。
4.客户端B获取到与A同一资源的锁。此时该资源进入多进程并行消费状态。有悖互斥原则。

リソースは通常、許容可能なこのような状況に敏感でない場合はもちろん、この出来事の確率は、非常に低いです。
又はこの場合には、すなわち、障害のより高い公差の問題ジョブ単一ポイントに必要なプロセスを単一インスタンスRedisの実装を使用して。

2.RedLockアルゴリズム

この実装では、唯一のキーを達成するためのRedisクラスターにおける協調プロトコルを達成するために本質的です。それは、すべてのノードがRedisのマスターノードであり、互いに完全に独立して、マスター・スレーブ複製または他のクラスタの調整メカニズムが存在しないことを要求します。

如果要获取锁，客户端进行的操作需要有：

1.客户端获取当前时间（毫秒）
2.使用相同的key和不同的value去顺序请求存在的N个master节点。（
该步骤需要客户端设置一个比自动释放时间小的多请求超时时间。比如说，当自动释放时间为10秒时，设置超时时间为5~50毫秒。这是用来防止在宕掉的节点上消耗过多的时间。一个节点不可用，应立即进行下个节点的请求。
）
3.客户端计算获取锁消耗的时间（step2消耗的时间——当前时间-step1获取到的时间）。当且仅当在N/2+1个节点获取到锁，获取锁的消耗时间小于锁的失效时间，才认为锁的获取是成功的。
4.若锁被获得，其有效时间可以被视为——初始的过期时间-获取锁的消耗时间。
5.如果客户端获取锁失败，无论什么原因（其实就两种原因，一是成功节点小于N/2+1，二是超时），都将在所有节点进行锁的释放（即便是哪些根本没有获取到锁的节点）；

で、上記のアルゴリズムに従って、Redisのクラスタマスターノードは、少なくとも3つが必要となります。そして、実現はまた、より複雑です。オーバーヘッドをロックすると、大きすぎます。要件は、Redisの運用上の問題のためにも高くなっています。全体の実装コストが高すぎます。しかし、幸いなことに、それはすでに達成されている--Redisson

単一インスタンスの実装

このコマンドsetNXとロックを登録する前に、データが一般的に見られているが、コマンドだけではない、実際には、非常に良いタイムスタンプ値を設定することによって制御することが可能期限切れ自動有効期限を設定することはできません。今、Redisの関係者はまた、SETコマンドを使用することをお勧めします。

SET resource-name anystring NX EX max-lock-time

自2.6.12版本SET命令支持多种操作：
    EX seconds -- Set the specified expire time, in seconds.
    PX milliseconds -- Set the specified expire time, in milliseconds.
    NX -- Only set the key if it does not already exist.
    XX -- Only set the key if it already exist.

ロックが解除されたとき、私たちは、原子行われたロックの解除を確実にするために使用さLUAスクリプト言語を使用することができます

    if redis.call("get",KEYS[1]) == ARGV[1]
    then
        return redis.call("del",KEYS[1])
    else
        return 0
    end

特定のコードの実装
ここで使用レタスです

1. Lock実装

 /** 
 *  如果锁处于空闲状态，当前线程获取到锁 
 *  如果锁已经被其它线程持有，禁用当前线程，直到当前线程获取到锁 
 */
 @Override
 public void lock() {    
 //选定同步方式    
    while (true){        
        if (tryLock())return;        
        this.sleepByMillisecond(renewalTime >> 1);    
    }
 }
 /** 
 *  尝试获取锁 
 *  如果锁可用返回true 否则返回 false 
 * @return 
 */
 @Override
 public boolean tryLock() {    
    //使用ThreadLocal保存当前锁对象 作为可重入锁的控制
    if (threadLocal.get() != null) return true;
    String set = statefulRedisConnection.sync().set(lockKey, lockValue, new SetArgs().nx().ex(lockTime));   
    if (set != null && "OK".equals(set)){        
        System.out.println("线程id:"+Thread.currentThread().getId() + "加锁成功!时间:"+ LocalTime.now());        
        isOpenExpirationRenewal = true; 
        threadLocal.set(this);
        this.scheduleExpirationRenewal();        
        return true;    
    }    
    return false;
 }
 /** 
 *  尝试获取锁 
 *  在指定时间内可以获取到  返回true 否则返回false 
 * @param time 
 * @param unit 
 * @return 
 * @throws InterruptedException 
 */
 @Override
 public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {   
     //获取进入时间    
     LocalTime now = LocalTime.now();    
     while (now.isBefore(now.plus(time, (TemporalUnit) unit))){       
        if (tryLock())return true;    
     }    
     return false;
 }

リニューアルの2.ロック

第二は、自分自身を更新する失敗であり、1はメインスレッドは、ハングスレッドを閉じることができません更新することで、二つの問題があるかもしれません。現在、異常な感覚が最初にロックコード、最善の方法をキャプチャするために提供され、最終的にfinallyブロックは、ロック解除を行います。第2のアプローチは、特定の問題を解決するために、ログ解析コードを作成する必要があることです。しかし、あなたは説教よくある質問を歓迎するためのより良い方法があれば実現します。


@Override
protected void scheduleExpirationRenewal() {    
    Thread thread = new Thread(new ExpirationRenewal());    
    thread.start();
}
private class ExpirationRenewal implements Runnable{    
    @Override    
    public void run() {        
        while (isOpenExpirationRenewal){            
            try {                
                Thread.sleep(renewalTime);           
            } catch (InterruptedException e) {               
                e.printStackTrace();           
            }            
            String expirFromLua = "if redis.call('get', KEYS[1]) == ARGV[1]"                    
                    + " then "                    
                    + "return redis.call('expire',KEYS[1],ARGV[2])"                    
                    + " else "                   
                    + "return 0"                   
                    + " end";            
            Object eval = statefulRedisConnection.sync().eval(expirFromLua, 
                ScriptOutputType.INTEGER, new String[]{lockKey}, lockValue, lockTime.toString());            
            System.out.println("续租获取的结果值：" + eval + ((long)eval==1?" 续租成功":" 续租失败"));        
        }   
    }
}

3.ロック解除

@Override
public void unlock() {    
//关闭续租    
isOpenExpirationRenewal = false;    
    //删除锁    
    String delFromLua = "if redis.call(\"get\", KEYS[1]) == ARGV[1]"    
        + " then "    
        + "return redis.call(\"del\",KEYS[1])"    
        + " else "    
        + "return 0"    
        + " end";    
    Long eval = statefulRedisConnection.sync().eval(delFromLua, ScriptOutputType.INTEGER, new String[]{lockKey}, lockValue);    
    if (eval == 1){       
        System.out.println("锁释放成功");    
    }else {       
        //最好做好日志记录
        System.out.println("锁 早已经释放");    
    }
}

4.まとめ

上記は公正かつ非株式スイッチを実現する方法を検討し、読み書きロックをする必要があり、リエントラントを達成しました。ロックの鍵は、それが唯一のRedis自体によって達成することができ、公正クロスプロセスロック要求のキューを維持することです。

2.RedLockアルゴリズム

1.Redissonプロフィール

レイジー、公式の導入に直接移動

高性能非同期とロックフリーのJava Redisのクライアントとネッティーフレームワークに基づきます。

Redissonの関数は（中国語でOH文書を）行って見て時間を持って、それが推奨され、非常に強力です。

2.RedLockを達成するためのアルゴリズム

Redissond赤ロック（RedissonRedLock）RedLockオブジェクトはアルゴリズム記載のロックを実現します。以下を使用

RLock lock1 = redissonInstance1.getLock("lock1");
RLock lock2 = redissonInstance2.getLock("lock2");
RLock lock3 = redissonInstance3.getLock("lock3");

RedissonRedLock lock = new RedissonRedLock(lock1, lock2, lock3);
// 同时加锁：lock1 lock2 lock3// 红锁在大部分节点上加锁成功就算成功。
lock.lock();
...
lock.unlock();

私たちは、複数のredissonInstance1 RLOCKを作成し、複数のオブジェクトを作成し、分散ロックを作るためにそれらを使用する必要があります。選択されたデータ構造はRedisのハッシュである種は、公正ロックを達成するために便利です。

使用することは非常に面倒です。

飼育係達成

原則

飼育係は、コヒーレンス・プロトコルを達成するために、分散コーディネーションサービスです。クライアント側のエンドとSeverを分けています。配布されるサーバー側のアプリケーション。ZABコヒーレンス・プロトコル、ノードのznodeの中間順序は、機構は、飼育係分散ロックを達成するための鍵であるwatchs。

1.zookeeperデータモデル

階層ネーム・スペース（階層的な名前空間）、分散ファイルシステムとして見ることができます。ツリー構造の各ノード「/」のセパレータ。ほとんどのUnicode文字は、ノード名として使用することができます。
飼育係の木は、ノードのznodeと呼ばれています。znodeノードは、データの変更を保存するのstatのデータ構造を維持し、ACL（アクセスコントロールList--アクセス制御リスト、各ノードは、アクセス権のノードのリストに相当するものを、行うことができますリストの制限が存在する、以下のとおりです。、READの作成、書き込み、削除、）ADMIN バージョン番号と対応するタイムスタンプを変更します。
znodeの書き込みがアトミックです。

znodeノードは、に分けることができます。

持続的な永続的なノードのノード
も、この特定のznodeのクライアントの切断を作成した後、持続的なノードがまだ存在しています。デフォルトでは、特に断りのない限り、全てのznodeは永続的です。
一時的なノードエフェメラルノード
の一時的なノードは、それがのznodeは削除されます対応し、セッションでセッションが終了したときに作成したクライアントとサーバを伴っています。そのため、一時的なノードが子ノードを作成することができません。暫定リーダーノードは、選挙で重要な役割を果たしています。
配列は、ノードシーケンスノード
ノードの順序は、永続的または一時的であってもよいです。新しいノードは、元の名前のセットのznodeパスに追加の10ビットシリアル番号によって配列、ZooKeeperのように作成されるのznode。シーケンス番号は、列の単調増加です。パスは、シーケンシャルのノードの/ MYNODE用のznodeを作成する場合、例えば、そのパスは0000000002へのZooKeeper / mynode0000000001、および次のシーケンス番号を変更します。場合2,147,483,647上インクリメント-と（2 ^ 311）、カウンタ（名称「-2147483648」をもたらす）オーバーフローします。ためにはノードロックと同期が重要な役割を果たしています
ノードコンテナ 3.5.3バージョンが追加され
たノードタイプは特別な条件に設定されているように、このようなリーダー、ロックなどを作ります。コンテナ内の最後の子ノードが除去されると、コンテナはいつか将来的に（個人的な感情はRedisの中に定期的に似て削除）削除する候補サーバになります。したがって、子ノードは例外がスローされるかどうかを判断し、投げた後、コンテナノードを再作成する必要があるのでとき、子ノードがKeeperException.NoNodeExceptionをスローしたときにコンテナノードを作成することが可能です。
ノードTTL 3.5.3のリリースでは、追加
クラスノードのノードのみが持続することができます。あなたはノードのノード永続的または恒久的な順序を作成するときは、ノードを設定TTLを選択することができます。ノード変更のTTL時間は発生しなかった場合、および子ノードません、そのノードのサーバーは、将来のある時点で削除されます。彼らはデフォルトで無効になっているので、TTLノードは、システムプロパティを使用して有効にする必要があります。

2.Watchs

クライアントは、変更情報ノードを取得するためにWatchsのznodeノード情報を監視するように設定することができます。

実装手順

キーロックは、通常のノードとWatchsメカニズムの一時的な順序を実現しています。watchs機構による監視データの消費量は、彼らが支出されているかどうかを判断する前に、キューの作成は、ノードの一時的な順序によるロックを取得します。

1.创建持久节点lock作为锁的父节点。
2.请求锁的客户端A在lock节点下创建临时顺序节点lock000000N;
3.获取lock下的节点列表，获取编号比客户端A次小的节点，若不存在，表示当前线程序号最小，获取到锁。
4.若编号比客户端A次小的节点存在，设置Watchs监听次小节点。次小节点删除，判断自己是不是最小的节点，是则获取到锁。

Apacheのオープンソースライブラリのキュレーターは、対応する提供分散ロック・実装を。
しかしながら、上記従来の手段を使用するよりも、それはまた、コンテナTTLノードまたはノードを使用することができ、自分自身を達成するための時間があります。

概要

飼育係の実装では、大きなトラブルの必要性を排除し、一貫性のロックに関係なく、用語をRedisのために比較しました。だから私は、学芸員のソースを見て時間を持っています。

etcd達成

etcdは何ですか

分散キー値ペア（KV）ストレージサービス。コンセンサスアルゴリズム筏を（ああ忘れてしまった、この感覚コンセンサスアルゴリズムの十分な詳細な記述されたかどうか、私は慎重に見て時間を持っている）達成する、それは2N + 1 Geの高可用性を実現する必要があります。主にまれに発生するデータの変更を格納するために使用される、監視クエリを提供します。使用する際に契約延長を気にしない、grpcの方法は、APIを来て、HTTP / HTTPS / grpcコールサーバのAPIを使用することができます。Grpc v3のバージョンは、追加することが可能です。v3のバージョンは、まだ残りの道HTTP / HTTPSの呼び出しをサポートしていますが、バージョンはV2およびV3と互換性がないことに注意して、コマンドのほとんどは、このようなバージョンV2で作成したデータを使用して、データを交換しない、変更され、V3は表示されません。そして、V3バージョンのサポートは、双方向通話の残りのために良いではありません。

原則

データモデル

etcdキー値は、基本的な構造です。

論理ビュー：
記憶領域の論理ビューは、フラットバイナリ（フラットバイナリである私は、この言葉を理解していない真実を伝えるために、私は、データの階層構造、そこにツリー状の構造が希望を知っていることを理解し、情報を検索する必要があります。翼、Baoquan）鍵空間。複数のリビジョンを維持するための鍵空間。すべてのトランザクションは、キースペースに新しいリビジョンが作成されます。キーは作成からライフサイクル（世代）の破壊への鍵です。（鍵を握る作成手段が繰り返し詳細な記録の破壊を修正）よりライフサイクルを持っている可能性が各キー。キーは、最初から現在の変更、キーの（バージョン）の現在のバージョンに存在しない場合。（バージョン0をリセットして）キーを現在の鍵生成情報をオフになっている含まフラグが生成され、削除、。あなたがキーを変更するたびにバージョンをインクリメントします。キーライフサイクルのバージョンでは単調に増加しています。圧縮が発生すると、（終了世代）の締固め改正前の任意のキーのライフ・サイクル・レコードが削除され、（最新除く）締固め改正前の設定値を削除します。
物理ビュー
KVは書籍Bの+の形式のデータは、そのデータ構造を更新するために元のデータを更新しないように、ディスクの種類に永続etcdが、更新後のデータ構造を生成します。Redisのが好きでだから、読み取りと書き込みの性能を比較することはできません。

分散ロックの基礎etcd実装

リースメカニズム（その有効期限にそれに関連付けられたキーを削除短命再生可能な契約）：リースメカニズム（TTL、時間は生きること）。リニューアルの問題。
リビジョン機構（鍵空間が変更されるたびにインクリメントされる64ビットのクラスタ全体カウンタ）：各単調リビジョンを増大キー改訂、新しいトランザクションはリビジョンキー空間内に作成されるたびに、を備えゼロの初期値。リビジョンは、サイズ、シーケンシャル書き込み操作によって知ることができます。分散ロックを実装する場合、ロックは、リビジョンの株式とロックの大きさの順に合わせて取得することができます。
プレフィックスメカニズム：プレフィックスメカニズム、またディレクトリのメカニズムとして知られています。キーは、キー1 = "/ mylock / 00001"、KEY2 = "/ mylock / 00002" として、ディレクトリの形式で作成することができます。プレフィックス/ mylock範囲クエリによって、KVは、制御ロック、ロック、公平性の大きさの取得改定の順序によって、リストを取得します。
ウォッチ・メカニズムは：メカニズムを感知し、ウォッチは、単一のキーを監視するだけでなく、範囲の監視をサポートすることができます。

実装手順

Etcdコントラスト飼育係と我々は全体として同じメカニズムがあります。これは、実質的に同じように達成されます。
それは、以下のステップを含みます。

1.创建对应资源的分布式锁的全局key的前缀，如/mylock，则第一个请求的客户端创建的key则为/mylock/uuid001，第二个为/mylock/uuid002。
2.为该对应资源创建租约Lease为特定合适时间。
3.客户端put自己的key，如/mylock/uuid001。这里的value不为空即可。获取自己put后的revision号，并记录。
4.获取key前缀下的所有键值对信息，并根据revision号大小排序，小的在前。
5.对比put的revision值是否是最小的，是的话获取锁，并开启续租线程。不是，则获取前一个加锁操作索引，并创建一个Watcher，用于监听前一一个key（将处于阻塞状态）。

最新バージョンのetcdは、分散ロックの実装を提供してきました。ロック解除を気にしてロック解除を呼び出すときにリリースされ、自動的に更新しないでください。キーロックは、上記と同じ基本的な実装の原理を話します。
etcd Javaクライアントはそうでetcd4j、jetcdとしています。

概要

etcd実装は比較的簡単であり、そして独自分散ロックは、ロックコマンドを使用して、達成された容易にロックを取得することができます。だけにして非常に費用対効果ではない実際には、取得の分散ロックを使用した場合でも、Javaで他の生態系の用途では非常に一般的etcdいないようです。

結論

最後に完成し、実際には、飼育係の真ん中のクラッシュと書き込みがありません詳細は、公正のRedisがロックしていることに気づいていませんでした。今、これらの事は、より包括的な提供し、いくつかは、自分自身を記述する必要はありませんが、原理は理解しなければなりません。リニューアル- -実際には、これらは比較的ある特定の放出を達成します。それでも、ソースコードを見て、あなた自身のアイデアを開発する機会を持って、私はキュレーター、Jetcd実装のソースコードがロックを確認するために、次の時間がRedissonことができると思います。残念ながら、直立フラグは、クールされているにもより多くの1が...できるかわからない、クールなドラッグされた
ことを眠り、それを眠る...
分散-分散ロック

参考资料：
Redisのします。https：//redis.io/topics/distlockの
飼育係ます：http：//zookeeper.apache.org/
etcdます。https：//etcd.io/

冪等：HTTPS：//www.cnblogs.com/javalyy/p/8882144.html
のZooKeeperは、分散ロックの実装：HTTPS：//www.cnblogs.com/javalyy/p/8882144.html
ETCDロック達成します。http ：//blogspring.cn/view/120
jetcd：HTTPS：//github.com/etcd-io/jetcd