etcdと分散ロックに関する記事

[[400328]]

1. 分散ロックを実装するためのコンポーネント

分散システムでは、分散ロックを実装するために一般的に使用されるコンポーネントは、Redis、Zookeeper、etcd です。それぞれの特徴を比較すると次のようになります。

上の図は3つのコンポーネントの特性を示しています。その中でも、分散ロックにとって最も重要な点は CP 要件です。ただし、Redis クラスターは CP をサポートしていませんが、AP をサポートしています。公式の redlock ソリューションも提供されていますが、複数のインスタンスの展開 (インスタンスの半分以上が成功と見なされる) が必要なため、展開とメンテナンスが比較的複雑です。したがって、一貫性要件が高いビジネス シナリオ (電子商取引、銀行支払い) では、通常、zookeeper または etcd が選択されます。パフォーマンス、同時実行性、メンテナンスコストを考慮して、Zookeeper と etcd を比較します。 etcd は Go 言語で開発されているため、バイナリ実行ファイルに直接コンパイルされ、他のものに依存しないという利点があります。この記事では、etcd を取り上げ、特定の観点について説明します。

2. APが分散ロックに適さない理由

CAP 理論では、分散システムにおけるマルチノード通信は必然的にネットワーク遅延、パケット損失などの問題につながるため、ネットワーク パーティションが必然的に発生します。ネットワーク分割が発生した場合、通常は CP または AP の 2 つのオプションがあります。

① 分散ロックを実装するために AP モデルを選択した場合、クライアントはクラスターマスターノードのロックに成功した後、すぐにロック成功のフィードバックを受け取ります。このとき、マスター ノードがスレーブ ノードにデータを同期する前にダウンした場合、システムはスレーブ ノードからノードを新しいマスター ノードとして選択します。新しいマスター ノードには古いマスター ノードに対応するロック データがないため、他のクライアントが新しいマスター ノードで同じロックを取得できるようになります。このとき、複数のプロセス/スレッド/コルーチンが同じ重要なリソース データを操作するため、データの不整合などの問題が発生します。

②分散ロックを実装するためにCPモデルを選択します。マスター ノードがデータをスレーブ ノードの半分以上に同期した後にのみ、ロックが成功したと見なされます。このとき、何らかの理由でマスターノードがダウンした場合、システムはデータ損失などの問題を回避するために、スレーブノードからより新しいデータを持つスレーブノードを新しいマスターノードとして選択します。

したがって、分散ロックの場合、データに強力な一貫性要件が課されるシナリオでは、AP モデルは適切な選択ではありません。少量のデータ損失を許容できる場合は、メンテナンス コストなどの理由から、AP モデルの Redis が優先される場合があります。

3. 分散ロックの特徴と動作

分散ロックの場合、操作には次のものが含まれます。

1. ロックを取得
2. ロックを解除
3. ビジネス処理中に、ロックを更新するために別のスレッド/コルーチンが開始されます。

4. etcdについて

公式ドキュメントは常に最高の学習教材です。 etcd の公式紹介には次のように書かれています:

• 分散システムでは、構成管理、サービス検出、分散作業の調整のための一貫したキー値ストアとして etcd を使用します。多くの組織では、コンテナ スケジューラ、サービス検出サービス、分散データ ストアなどの運用システムを実装するために etcd を使用しています。 etcd を使用する一般的な分散パターンには、リーダー選出、分散ロック、マシン アクティビティの監視などがあります。
• 分散システムでは、構成管理、サービス検出、分散作業の調整のための一貫したキー値ストアとして etcd を使用します。多くの組織では、コンテナ スケジューラ、サービス検出サービス、分散データ ストレージなどの実稼働システムを実装するために etcd を使用しています。 etcd を使用する一般的な分散パターンには、リーダー選出、分散ロック、マシンの活性状態の監視などがあります。
• https://etcd.io/docs/v3.4/learning/why/

分散ロックは、etcd が実現できる多くの機能のうちの 1 つにすぎません。サービス登録と検出は、etcd でより多く使用されます。

当局者はまた、多くのコンポーネントを比較し、次のように分類しました。

比較してみると、それぞれの特徴が分かります。どちらを選択するかについては、あなた自身の心の中に答えがあるかもしれません。

5. etcdは分散ロックの関連インターフェースを実装する

分散ロックの場合、etcd の対応する追加、削除、更新インターフェースが主に使用されます。

 // KV: キー値関連の操作
タイプKVインターフェース{
    // ストレージ。
    Put(ctx context.Context、 key 、val string、opts ...OpOption) (*PutResponse、error)
    // 得る。
    Get(ctx context.Context、キー文字列、opts ...OpOption) (*GetResponse、エラー)
    // 消去。
削除(ctx context.Context、キー文字列、opts ...OpOption) (*DeleteResponse、エラー)
    // rev で指定されたバージョンより前の履歴データを圧縮します。
    Compact(ctx context.Context, rev int64, opts ...CompactOption) (*CompactResponse, error)
    // 操作セットを走査するために使用できる一般的な操作実行コマンド。 Put/Get/ Deleteも Do に基づいています。
    Do(ctx context.Context, op Op) (OpResponse, error)
    // トランザクションを作成します。If/ Then / Else / Commit操作のみをサポートします。
    Txn(ctx コンテキスト.コンテキスト) Txn
 } 
 
 
 // リース: リース関連の操作
リースインターフェース型{
    // リースを割り当てます。
許可(ctx context.Context、ttl int64) (*LeaseGrantResponse、エラー)
    // リースを解放します。
取り消し(ctx context.Context、id LeaseID) (*LeaseRevokeResponse、エラー)
    // 残りの TTL 時間を取得します。
    TimeToLive(ctx context.Context、id LeaseID、opts ...LeaseOption) (*LeaseTimeToLiveResponse、エラー)
    // すべてのリースを取得します。
    リース(ctx context.Context) (*LeaseLeasesResponse, エラー)
    // 更新は引き続き有効です。
    KeepAlive(ctx context.Context, id LeaseID) (<-chan *LeaseKeepAliveResponse, error)
    // アクティベーションを 1 回だけ更新します。
    KeepAliveOnce(ctx context.Context、id LeaseID) (*LeaseKeepAliveResponse、エラー)
    // 更新アクティベーション機能を無効にします。
閉じる（）エラー
}

6. etcd分散ロックコードの例

パッケージメイン
 
輸入 （
 "コンテクスト"  
 「fmt」  
 「go.etcd.io/etcd/clientv3」  
 "時間"  
 ） 
 
 var conf clientv3.Config 
 
 // ロック構造
EtcdMutex 構造体型 {
    Ttl int64 //リース時間
 
    Conf clientv3.Config //etcd クラスター構成
キー文字列//etcdキー 
    キャンセルcontext.CancelFunc //更新関数を閉じる
 
    txn クライアントv3.Txn
    リースクライアントv3.リース
    リースID クライアントv3.リースID
 } 
 
 // ロックを初期化する
func (em *EtcdMutex) init() エラー {
    var err エラー
    var ctx コンテキスト.コンテキスト
 
    クライアント、エラー:= clientv3.New(em.Conf)
    err != nil の場合 {
エラーを返す
    } 
 
    em.txn = clientv3.NewKV(クライアント).Txn(コンテキスト.TODO())
    em.lease = clientv3.NewLease(クライアント)
    リース応答、エラー := em.lease.Grant (context.TODO()、em.Ttl) 
 
    err != nil の場合 {
エラーを返す
    } 
 
    ctx、em.cancel = context.WithCancel(context.TODO())
    em.leaseID = リース応答ID
    _, エラー = em.lease.KeepAlive(ctx, em.leaseID) 
 
エラーを返す
} 
 
 // ロックを取得する
func (em *EtcdMutex) Lock() エラー {
    エラー:= em.init()
    err != nil の場合 {
エラーを返す
    } 
 
    // ロック
    em.txn.If(clientv3.Compare(clientv3.CreateRevision( em.Key ), "=" , 0))。
次に、 (clientv3.OpPut(em.Key , " " , clientv3.WithLease(em.leaseID))) を実行します。それ以外（） 
 
    txnResp、エラー:= em.txn。専念（）
    err != nil の場合 {
エラーを返す
    } 
 
    // txn.if 条件が真かどうかを判定する
    !txnResp.Succeeded の場合 {
 return fmt.Errorf( "ロックを取得できませんでした" )
    } 
 
    ゼロを返す
} 
 
 //ロックを解除する
func (em *EtcdMutex) UnLock() {
    // リースは自動的にすぐに期限切れになります
    // cancel は更新をキャンセルし、 revokeは即時に期限切れになります
    em.キャンセル()
    リース。取り消し(context.TODO()、em.leaseID) 
 
    fmt.Println( "ロックが解除されました" )
 } 
 
 // グラウチン1
 try2lock1()関数{
    eMutex1 := &EtcdMutex{
        会議: 会議、
        合計: 10,
キー： 「ロック」 、
    } 
 
    エラー:= eMutex1.Lock()
    err != nil の場合 {
        fmt.Println( "groutine1 はロックを取得できませんでした" )
戻る 
    }
    eMutex1.UnLock() を延期する
 
    fmt.Println( "groutine1 はロックを正常に取得しました" )
時間.スリープ(10 *時間.秒)
 } 
 
 // グルーティン2
 try2lock2()関数{
    eMutex2 := &EtcdMutex{
        会議: 会議、
        合計: 10,
キー： 「ロック」 、
    } 
 
    エラー:= eMutex2.Lock()
    err != nil の場合 {
        fmt.Println( "groutine2 はロックを取得できませんでした" )
戻る 
    } 
 
    eMutex2.UnLock() を延期する
    fmt.Println( "groutine2 はロックを正常に取得しました" )
 } 
 
 // テストコード
EtcdRunTester()関数 {
    conf = クライアントv3.Config{
        エンドポイント: []string{ "127.0.0.1:2379" },
        ダイヤルタイムアウト: 5 *時間。 2番、
    } 
 
    // ロックを競うために2つのコルーチンを開始する
    try2lock1() を実行する
    try2lock2() を実行する
 
時間.スリープ(300 *時間.秒)
 }

要約する

分散ロック機能を提供できるコンポーネントは多数ありますが、それぞれに独自の性質と個性があります。どのコンポーネントを選択するかは、ビジネスにとってのデータの重要性に応じて異なります。データに強力な一貫性が必要な場合は、CP をサポートする etcd と zookeeper が推奨されます。少量のデータ損失が許容され、強力な一貫性が要求されない場合は、AP をサポートする Redis が推奨されます。