分散ロックのカプセル化も非常に特殊である

通常、分散ロックには、Redis ベース、Zookeeper ベース、データベース ベースなど、多くのオプションがあります。

Redis はデータをキャッシュするために使用され、すべてのプロジェクトで使用されるため、分散ロックには Redis がよく使用されます。

ロックに Redis を使用する場合は、redisson などのオープンソース ソリューションを直接使用できます。

最も一般的な使用法は次のとおりです。

 RLockロック= redisson .getLock("anyLock");  
ロック。ロック();  
走る（）;
ロックを解除します。

ロック オブジェクトを取得し、lock() を呼び出してロックし、ビジネス ロジックを実行して、unlock() を呼び出してロックを解除します。

フレームワークによって提供される使用法は非常に簡潔ですが、それでもロックをラップする必要があります。パッケージ化の目的は、スケーラビリティと使いやすさを向上させることです。

抽象インターフェース

ロックに redisson のネイティブ API を直接使用すると、多くの場所に RLock 関連のコードが出現します。ある日突然、何らかの理由で鍵を交換する必要が生じ、変更の範囲が比較的大きくなります。 RLock が使用されているすべての場所を変更する必要があります。

以下に示すように、多くのサービスは RLock.lock() メソッドを使用します。ロックを交換する必要がある場合は、関係するすべてのクラスとメソッドを変更する必要があります。変更されたポイントは赤で表示されます。

したがって、抽象化のレイヤーを作成する必要があります。 DistributedLock インターフェースを定義してロック関連の機能を提供し、複数の実装を提供できるため、置き換えや拡張が容易になります。

次の図に示すように、各サービスは DistributedLock インターフェースを使用してロックします。ロック実装を置き換える必要がある場合、使用場所を変更する必要はなく、DistributedLock 実装を置き換えるだけで済みます。

自動リリース

自動解放とは、ロック後、ビジネス ロジックの実行後にロックを自動的に閉じる必要があることを意味します。以前の Redisson メソッドによれば、保持されているロックを解除するには、unlock() を手動で呼び出す必要があります。

もちろん、Redisson はタイムアウト解除機能も提供します。通常の状況では、業務の実行後にロックを解除する必要があり、同じロックに対する次の要求は引き続き処理できます。

リソースを手動で解放する場合に最もよくある問題は、解放を忘れてしまうことです。そのため、リソースを自動的に解放する try-with-resources が JDK7 で導入されました。これは皆さんもよくご存知だと思います。

したがって、カプセル化する場合、エラーの可能性を減らすために、ユーザーが手動で解放しないようにします。結果については、Supplier を使用してロジックを渡すことができます。結果がない場合は、Runnable を使用してロジックを渡すことができます。

 /**  
 * ロック 
 * @param key ロックキー 
 * @param waitTime ロックを試行、待機時間 (ミリ秒)  
 * @param リースタイム ロック後の有効期限 (ミリ秒)  
 * @param success ロックの実行が成功した場合のロジック 
 * @param fail ロックが失敗したときに実行するロジック 
 * @戻る 
 */  
 < T > T ロック(文字列キー、int 待機時間、int リース時間、サプライヤー< T >成功、サプライヤー< T >失敗);

使用：

文字列結果=分散ロック.lock("1001", 1000, () - > {  
    System.out.println("入ってください...");  
    試す {  
        スレッドをスリープ状態にします(1000);  
    } キャッチ (InterruptedException e) {  
        e.printStackTrace();  
    }  
    「成功」を返します。  
 }, () - > {  
    System.out.println("ロックに失敗しました...");  
    「失敗」を返します。  
 });

災害復旧

注意が必要なもう一つの問題は、ロックの可用性です。対応する Redis に問題がある場合、この時点でロックは確実に失敗します。何も対策を講じなければ、通常の業務運営に影響が及び、業務が行えなくなります。

Redis ロックの実装に加えて、データベース ロックなどの他のロックも実装できます。 Redis ロックが使用できない場合は、データベース ロックにダウングレードされます。パフォーマンスは影響を受けますが、ビジネスには影響しません。

ロック処理

データベースのロックも利用できない場合は（余談ですが、すべてが利用できなくなる可能性は非常に低いです）、業務処理を失敗させる方がよいでしょう。同時実行シナリオによって発生する問題を防ぐために、ロック シナリオを使用するためです。ロックが利用できない場合、異常消費して業務処理を継続することになり、ロックなしでは業務上の問題が発生する可能性があります。

もちろん、Redis やデータベースの監視などの監視も非常に重要です。障害が発生した場合、担当者が適時に介入します。

監視システム

分散実装を実行する Redis、データベース、Zookeeper などのミドルウェアの監視は絶対に必須です。もう 1 つのタイプの監視は、ロック アクションのよりきめ細かい監視です。

たとえば、ロックにかかる時間、ロックを解除するまでの時間、ロック内で業務を実行する時間、ロックの同時実行性、実行回数、ロック失敗回数などです。

これらのデータ指標は非常に重要であり、問​​題をタイムリーに検出するのに役立ちます。たとえば、10 秒以内に数百回のロック試行が失敗した場合、それらはすべてデータベース ロックにダウングレードされます。このとき、アラームを受信して​​、Redis に問題があることを認識し、時間内に解決します。

監視方法は各社によって異なりますので、ご自由にお選びください。クロールのためにデータを Prometheus に公開することも、Cat を統合して追跡を行うこともできます。監視してアラートを発行できれば問題ありません。