分散クラスターシステムの開発では、スレッドロックがすべてのシナリオの使用をサポートできないことが多く、分散ロックの新しい技術ソリューションを導入する必要があります。
スレッドロック、プロセスロック、分散ロック
スレッドロック**：誰もがよく知っています。主にメソッドとコードブロックをロックするために使用されます。メソッドまたはコードブロックがロックを使用する場合、最大で1つのスレッドのみが同時にコードを実行します。複数のスレッドが同じオブジェクトのロック方法/コードブロックにアクセスする場合、同時に実行されているスレッドは1つだけであり、残りのスレッドは現在のスレッドが実行されるのを待ってからコードセグメントを実行する必要があります。ただし、残りのスレッドは、オブジェクト内のロックされていないコードブロックにアクセスできます。
プロセスロック：同じオペレーティングシステム内の複数のプロセスの共有リソースへのアクセスを制御することもできますが、プログラムの独立性のため、各プロセスはリソースへの他のプロセスのアクセスを制御できませんが、ローカルシステムのセマフォ制御（オペレーティングシステムの基本知識）。
分散ロック：複数のプロセスが同じシステムにない場合は、分散ロックを使用して、複数のプロセスによるリソースへのアクセスを制御します。
主要メーカーのインタビュー資料やビデオチュートリアルについては、クリックして直接入力し、無料で入手できます。パスワード：CSDN
分散ロックとは何ですか、そしてそれを実装する方法
Intsmazeはそれをより簡単に言います、分散ロックの実現はロックメタデータと他の情報を保存するためにサードパーティのストレージメディアに依存しなければなりません。たとえば、分散クラスターが特定のデータ行を操作する場合、このデータのシリアル番号は一意であり、このシリアル番号をロックのIDとして使用します。プロセスがデータを操作する場合は、最初に次の手順を実行します。サードパーティのストレージメディアロックIDが存在するかどうかを確認し、存在しない場合は、ロックIDを書き込んでから、データに対して操作を実行します。他のプロセスがデータにアクセスする場合は、最初にサードパーティに移動します。このデータが存在するかどうかを確認するためのパーティストレージメディアロックIDがある場合、このデータ行はすでに他のプロセスによって使用されていると見なされ、サードパーティのストレージメディアを継続的にポーリングして他のプロセスが存在するかどうかを確認しますロックを解放します。プロセスがデータの操作を終了すると、プロセスはサードパーティのストレージメディアからロックIDを削除し、他のポーリングプロセスがロックを制御できるようにします。
もちろん、Redisはgetおよびset操作では判断できません。getおよびset操作はアトミックではありません。redisのjedis.set（String key、String value、String nxxx、String expx、int time）コマンドを使用して、アトミック性を確保できます。
そうは言っても、もう1つポイントを追加しましょう。スレッドロック、プロセスロック、分散ロックはすべて同じ機能を持っていますが、アクションの範囲は異なります。範囲サイズ：分散ロック-プロセスよりも大きいロック-スレッドよりも大きいロック。プロセスロックの場合はスレッドロックと分散ロックを使用することもでき、スレッドロックの場合はプロセスロックを使用することもできます。ただし、範囲が広いほど、技術的な複雑さが増します。
分散ロックの問題点
分散ロックに関しては、javaEE開発の経験がある人は、高い同時実行性に対処するために、システムはTomcatクラスターを構築すると言うでしょう。クラスター内のサービスは同じデータベースからアクセスされ、複数のサーバーが同じデータベースデータを変更します。同時に操作しますが、サーバーで分散ロックを使用していませんか？上記の分散ロックの説明によると、2つの異なるシステム上のJVMプロセスは、データベースの同じリソースに同時にアクセスします。現時点では、制御に分散ロックを使用する必要があります。
これは間違いではありませんが、データベースの特性を忘れてしまいました。2つのサーバーが（URLを介して）直接アクセスし、サーバーのハードディスク上のファイル内の同じ行のデータを操作するだけの場合は、この時点で分散ロックを使用する必要があります。
ただし、2つのサーバーがアクセスするデータはデータベースに格納されるため（データベース自体はサービスプログラムであり、外部システムからの要求を受信するためにマルチスレッド化されます）、2つのサーバーの要求はネットワークIOを介してデータベースサーバーに送信されます。 、その後、リクエストはデータベースサービスプロセスに渡されて処理されます。データベースサーバーはリクエストを受信して複数のスレッドで処理します。このとき、テーブル内のデータ行のマルチスレッドアクセス制御はデータベースサービスによって制御されます。 （つまり、データベースサービスのコードはスレッドでロック処理を実行します）、これはデータベースサーバーの行ロックおよびその他の特性です。データベース側はすでに複数の外部システムからの要求に対してロック操作を実行しているためです。アプリケーションサーバー側で分散ロックを開発する必要はありません。
データベース内のデータの複数の行を同時に更新する場合、現時点ではデータベースの行ロックは保証されません。現時点では、分散ロックを使用します。はい、現時点で使用できます。使用できることに注意してください。なぜそれが言えるのですか？データベース自体がこのメカニズム、トランザクション、および彼の分離レベルを提供するためです。もちろん、データベースによって提供されるトランザクションの代わりに分散ロックを使用することもできます。
分散ロックとビジネスのバランス
分散ロックのデザインは完全に美しくはありません。特定のビジネスシナリオでのみ使用できます。すべてのビジネスで使用する場合は、ビジネス要件と合理的なデザインを十分に理解する必要があります。理由としては、 j2eeを開発するときのmybatisの第2レベルのキャッシュ。名前付けに関して注意を払う必要のあるビジネス上の問題は同じです。
Intsmazeは分散ロックを使用します。テーブルの2行目と3行目をIDとしてロックします。同じ操作が発生したときにテーブルの2行目と3行目が更新された場合、彼はそれを変更できません。彼はそれを手に入れます。それはロックすることができます。ただし、2番目の行のみを変更する操作がある場合、彼はこの時点でその行の操作を取得し、データベースが前の操作の行のロックを解放するのを待ちます。
したがって、分散ロックはどこでも使用できるわけではありませんが、特定のシナリオで使用できます。たとえば、ビジネスシステムには、2行目を個別に変更する操作はありません。
分散ロックはhbaseストレージシステムで使用されます
実際の開発シナリオでは、hbase操作で分散ロックを実行します。優れた非メモリデータベースとして、hbaseは従来のデータベースと同じトランザクションの概念を提供しますが、HBaseトランザクションは行レベルのトランザクションであり、行のアトミック性を保証できます。レベルのデータ。パフォーマンス、一貫性、分離、および耐久性は、一般にACID特性と呼ばれます。
トランザクション特性を実現するために、HBaseは、さまざまなロックメカニズム、MVCCメカニズムなど、さまざまな同時実行制御戦略を採用しています。
hbaseは行レベルのトランザクションのみをサポートするため、ビジネスが2つ以上の行のレコードを同時に操作する必要がある場合、hbase自体はACIDサポートを提供できません。
データベースアクセスの負荷圧力
データベースは、クライアント要求ごとにスレッドを作成します。これらのスレッドは、データ変更の特定の行の行ロックを取得する必要があります。他のクライアントスレッドがデータを変更する場合は、前のスレッドがロックを解放するのを待ってから許可する必要があります。 。。
クライアント側の多くのスレッドがデータの行を変更する必要がある場合、ロックを取得していないスレッドはデータベース側のマシンでポーリングを継続し、データベース側のプレッシャーを増大させます。
分散ロックを使用して、データベース側のスレッドの継続的なポーリングを回避するために、各クライアントマシンで取得されるのを待機しているデータベース行ロックのポーリングを実装できます。
たとえば、クライアントがデータベース内の特定のデータ行に対して操作要求を送信する前に、クライアントマシンのロックを競合します。ロックが取得されていない場合、データベース側のように操作要求は送信されません。 、データベース側がなくなります。ポーリング圧力。
もちろん、分散ロックの導入は、ビジネスのニーズに合わせて設計する必要があります。そうしないと、ロックIDの名前が不完全になり、データの読み取りに一貫性がなくなり、データの有効期限が切れるなどの問題が発生します。
分散ロックの実装オプション
現在、ZookeeperとRedisが人気であり、どちらにも独自の利点があります。Redisの人気のあるメモリキャッシュは、水平方向に拡張でき、リクエストの負荷を増やすこともできます。高並列分散ロックデータの読み取りおよび書き込みリクエストに迅速に応答できます。同時に、Aofがあります。センチネルメカニズムは、特定のダウンタイム分散ロックのデータ損失によって引き起こされる問題を防ぐことができます。
分散整合性アルゴリズムpaxosアルゴリズムの実装であるため、動物園の飼育係の方が好きです。高負荷のリクエストに直面してもプレッシャーはありません。同時に、ダウンタイムは分散ロックのデータ整合性に影響を与えません。は監視メカニズムを備えています。プログラムがロックを解放すると、分散ロックの制御を取得するために他のプログラムに時間内に通知できます。ここでのポーリングの実装では、ロックを開発する必要はありません。
分散ロックとスレッドロックの導入は1年前にエディターで行われ、明確かつ明確な方法ですべての人にそれらを導入する時間はありませんでした。多くのフォーラムで、ビッグデータ分野に参入したばかりの多くの新規参入者が分散ロックについて言及しているが、分散ロックとスレッドロックについて深く理解していないため、多くの場合、スレッドロックは修正できますが、分散ロックは、システム全体の設計をより複雑にします。
さらに、著者は、zookeeperは優れたテクノロジーであると考えていますが、ビッグデータの分野では特定のフレームワークのコーディネーターとしてしか表示されないため、多くの開発者はその優れた機能を無視しています。しかし、私が言いたいのは、現在のホットなマイクロサービスでは、zookeeperは実際には、分散ロックや構成センターなどの多くの機能を実現するために使用されるということです。
読者のメリット
ここを見てくれてありがとう！
以下に示すように、2021年の最新のJavaインタビューの質問（回答を含む）とJava研究ノートをここにまとめました。
上記の面接の質問に対する回答は、ドキュメントノートにまとめられています。インタビューだけでなく、いくつかのメーカーに関する情報をまとめ、Zhentiの最新の2021コレクション（両方ともスクリーンショットのごく一部を文書化）を誰でも無料で共有できます。必要な場合は、クリックしてシグナルを入力できます：CSDN！自由に共有できます〜
この記事が気に入ったら、転送して気に入ってください。
私に従うことを忘れないでください！
