まず、分散ロック・デザインのRedisに基づきます
1、実装：setnxキー値の時間を期限切れ
2、問題があります：
、シングル・インスタンス：高可用性を満たすことができません
B、マスタースレーブ：メインロックはスレーブに同期されていない、マスターがダウンし、何もロックが存在しない、ロックが問題を繰り返すことになります
図3は、関係者は提案：確実にするためにredlockアルゴリズムを使用して、成功したと考えられ、最も成功したロックを使用して、少なくとも三つの主要Redisのは、より高いコスト、インスタンスから実現されます。
本質的な問題：分散ロックは、RedisのクラスタがAPモデルである、CPモデルが必要です！
第二に、分散ロックの要件
1、強い一貫性
2、サービスの可用性
3、ダウンタイムが自動的にロック解除を更新することができ
4、ビジュアル管理、モニタリング
第三に、プログラム分散ロック・コントラスト
| 繰り返します | 飼育係 | etcd | |
| コンセンサスアルゴリズム | ノー | パクシ | ラフト |
| キャップ | の | CP | CF /オフ |
| ハイアベイラビリティ | マスタースレーブ | 超半数可用 | 超半数可用 |
| インターフェイスタイプ | クライアント | クライアント | HTTP / grpc |
| 実現 | setnx | createEphemeral一時的なノード | 安らかなAPI |
1、Redisのは、データの一貫性を保証することはできません
etcdよりも低く、一時的なノードと時計のメカニズム、効率、スケーラビリティ、コミュニティ活動を作成します。使用してロックを達成するために2、飼育係
3、etcdを達成するために提案されているオプション