分散ロックとは何かと聞かれたら、この記事を送ってください。

最近では、面接では分散システムについて話すことが多いです。通常、面接官はサービス フレームワーク (Spring Cloud、Dubbo) から始め、次に分散トランザクション、分散ロック、ZooKeeper などの知識について話します。

それでは、分散ロックの知識についてお話ししましょう。まず、Redis 分散ロックの実装原理を詳しく見てみましょう。

正直に言うと、社内の本番環境で分散ロックを使用する場合は、Redis 分散ロックなどのオープンソース ライブラリを必ず使用することになります。一般的には、非常にシンプルで使いやすい Redisson フレームワークを使用できます。

ご興味があれば、Redisson の公式 Web サイトにアクセスして、Redisson の依存関係をプロジェクトに導入し、Redis に基づいて分散ロックとリリースロックを実装する方法を確認してください。

ここに、使用できる簡単なコード スニペットを示します。まずは直感的に感じてみてください。

上記のコードはどうでしょうか?とてもシンプルだと思いませんか？さらに、Redis シングルインスタンス、Redis Sentinel、Redis クラスター、Redis マスタースレーブなど、さまざまなデプロイメントアーキテクチャもサポートされており、実装できます。

RedissonはRedis分散ロックの基本原理を実装している

さて、次に手描きの図を使用して、オープンソース フレームワーク Redisson が Redis 分散ロックをどのように実装するかを説明します。

ロック機構

上の写真を見てみましょう。今、クライアントはそれをロックしたいと考えています。クライアントが Redis クラスターに直面している場合、最初にハッシュ ノードに基づいてマシンを選択します。

選択されているマシンは 1 台だけであることに注意してください。これは重要です!次に、Lua スクリプトが Redis に送信されます。 Lua スクリプトは次のとおりです。

Lua スクリプトを使用する理由は何ですか?大量の複雑なビジネス ロジックを Lua スクリプトにカプセル化して Redis に送信することで、この複雑なビジネス ロジックの実行のアトミック性を確保できるためです。

それで、この Lua スクリプトは何を意味するのでしょうか?ここでKEYS[1]はロックしたキーを表します。例: RLock lock = redisson.getLock("myLock");ここで自分で設定したロックキーは「myLock」です。

ARGV[1]はロックキーのデフォルトの有効期間を表し、デフォルトでは30秒です。 ARGV[2]はキーをロックしたクライアントのIDを表し、次のようになります：8743c9c0-0795-4907-87fd-6c719a6b4586:1。

最初の if ステートメントでは、「exists myLock」コマンドを使用して判断することを説明します。ロックしたいロックキーが存在しない場合は、ロックされます。どうやってロックするんですか？とても簡単です。次のコマンドを使用するだけです: hset myLock。

8743c9c0-0795-4907-87fd-6c719a6b4586:1 1. このコマンドはハッシュ データ構造を設定します。このコマンドを実行すると、次のようなデータ構造が表示されます。

上記は、クライアント「8743c9c0-0795-4907-87fd-6c719a6b4586:1」がロックキー「myLock」のロックを完了したことを意味します。

次に、「pexpire myLock 30000」コマンドが実行され、myLock ロック キーの有効期間が 30 秒に設定されます。はい、これでロックが完了しました。

相互排他ロック機構

では、この時点でクライアント 2 がロックを試み、同じ Lua スクリプトを実行すると、何が起こるでしょうか?

とても簡単です。最初の if ステートメントは "exists myLock" を実行し、ロック キー myLock がすでに存在することを検出します。

2 番目の if ステートメントは、myLock ロック キーのハッシュ データ構造にクライアント 2 の ID が含まれているかどうかを確認しますが、クライアント 1 の ID が含まれているため、明らかに含まれません。

したがって、クライアント 2 は、pttl myLock によって返される数値を取得します。これは、ロック キー myLock の残りの有効期間を表します。

たとえば、生存時間は 15000 ミリ秒残っています。この時点で、クライアント 2 は while ループに入り、ロックを試行し続けます。

ウォッチドッグ自動伸長機構

クライアント 1 によって追加されたロック キーのデフォルトの有効期間は 30 秒のみです。 30 秒を超えてもクライアント 1 がロックを保持したい場合は、どうすればよいですか?

単純！クライアント 1 が正常にロックされている限り、ウォッチ ドッグが開始されます。 10 秒ごとにチェックするバックグラウンド スレッドです。クライアント 1 がまだロック キーを保持している場合、ロック キーの存続時間は継続的に延長されます。

再入可能ロック機構

クライアント 1 がすでにロックを保持している場合はどうなりますか?ロックが再入可能の場合はどうなりますか?たとえば、次のコード:

それでは、上記の Lua スクリプトを分析してみましょう。最初の if ステートメントは明らかに true ではなく、「exists myLock」はロック キーがすでに存在することを示します。

2 番目の if ステートメントは、myLock のハッシュ データ構造に含まれる ID がクライアント 1 の ID (「8743c9c0-0795-4907-87fd-6c719a6b4586:1」) であるため、true になります。

このとき、再入可能ロック ロジックが実行されます。次のコマンドを使用します: incrby myLock 8743c9c0-0795-4907-87fd-6c71a6b4586:1 1。このコマンドにより、クライアント 1 のロック数が 1 ずつ増加します。

この時点で、myLock データ構造は次のようになります。

ご覧のとおり、myLock のハッシュ データ構造内のクライアント ID はロックの数に対応しています。

リリースロック機構

lock.unlock() を実行すると、分散ロックを解除できます。このときのビジネスロジックも非常にシンプルです。実際、簡単に言えば、myLock データ構造内のロックの数は毎回 1 ずつ減少します。

ロックカウントが 0 の場合、クライアントはロックを保持していないことを意味します。このとき、「del myLock」コマンドを使用して、Redis からキーを削除します。

その後、別のクライアント 2 がロックの完了を試みることができます。これは、分散ロック用のオープンソース Redisson フレームワークの実装メカニズムです。

一般的に、実稼働システムでは、Redisson フレームワークによって提供されるクラス ライブラリを使用して、Redis に基づいて分散ロックをロックおよび解放できます。

上記のRedis分散ロックの欠点

上記のソリューションの最大の問題は、myLock などのロック キーの値を Redis マスター インスタンスに書き込むと、対応するマスター スレーブ インスタンスに非同期的にコピーされることです。

ただし、このプロセス中に Redis マスターに障害が発生した場合、マスターとスレーブの切り替えが発生し、Redis スレーブが Redis マスターになります。

その後、クライアント 2 がデータをロックしようとすると、新しい Redis マスターでデータがロックされ、クライアント 1 はデータが正常にロックされたと認識します。

これにより、複数のクライアントが分散ロックをロックすることになります。この時点で、システムにはビジネス セマンティクスに関する問題が確実に発生し、さまざまなダーティ データが生成されます。

したがって、これが Redis クラスター、または Redis マスター スレーブ アーキテクチャのマスター スレーブ非同期レプリケーションによって引き起こされる Redis 分散ロックの最大の欠陥です。Redis マスター インスタンスがダウンすると、複数のクライアントが同時にロックを完了する可能性があります。

ZooKeeper分散ロックの実装原理を7枚の画像で徹底解説

次に、ZooKeeper が分散ロックを実装する原理について説明します。同様に、広く利用されているオープンソースフレームワーク Curator をベースにした ZooKeeper (以下、ZK) 分散ロックの実装について説明します。

一般的に、分散ロック フレームワークを独自にパッケージ化する大企業を除き、これらのオープン ソース フレームワークによってパッケージ化された分散ロック実装を使用することをお勧めします。これは比較的早くて簡単な方法です。

ZooKeeper 分散ロック機構

次に、複数のクライアントが ZK 分散ロックを取得および解放するプロセス全体とその背後にある原理を見てみましょう。

まず、次の図を見てみましょう。 2 つのクライアントが ZK の分散ロックを競うとどうなるでしょうか?

ZK についてよく知らない場合は、まず Baidu で検索して、ZK にはどのようなノードタイプがあるのか​​など、基本的な概念を理解することをお勧めします。

上の写真をご覧ください。 ZK にはロックがあり、このロックは ZK 上のノードです。次に、両方のクライアントがロックを取得する必要があります。彼らはどうやってそれを手に入れるのでしょうか?

クライアント A が主導権を握り、ZK への分散ロックの要求を開始すると仮定します。このロック要求は、ZK の「一時シーケンシャル ノード」と呼ばれる特別な概念を使用します。

簡単に言うと、ロックノード「my_lock」の直下にシーケンスノードを作成します。このシーケンス ノードには、ZK 自体によって管理されるノード シリアル番号があります。

たとえば、クライアントがシーケンシャルノードを作成すると、ZK はそれに xxx-000001 という名前を付けます。

次に、2 番目のクライアントがシーケンシャル ノードを作成し、ZK はそれに xxx-000002 という名前を付けます。

各番号は 1 から順に増加しますので、ご注意ください。ZK はこの順序を維持します。

したがって、この時点でクライアント A が最初にリクエストを開始すると、順次ノードが作成されます。下の図に示すように、Curator フレームワークは次のようになります。

クライアント A がロック要求を開始すると、まずロックするノードの下に一時的なシーケンシャル ノードが作成されます。これらの長い名前は、Curator フレームワーク自体によって生成されます。

そして最後の数字は「1」です。クライアント A が最初にリクエストを開始するため、クライアント A に対して生成されるシーケンス ノード番号は「1」になることに注意してください。

次に、クライアント A はシーケンシャル ノードを作成します。まだ終わってませんよ。ロック ノード「my_lock」の下にあるすべての子ノードをチェックし、これらの子ノードはシーケンス番号でソートされます。この時点で、彼はおそらく次のようなコレクションを手に入れるでしょう:

次に、クライアント A は、「ねえ、このセットでは、私が作成したシーケンス ノードが 1 位にランクされていますか?」という重要な判断を下します。

もしそうなら、ロックを追加できます!なぜなら、私はシーケンシャルノードを作成した最初の人物であり、分散ロックを追加しようとした最初の人物だからです。

ビンゴ！ロック成功しました！全体のプロセスを直感的に体験するには、以下の図をご覧ください。

次に、クライアント A がロックを終了し、クライアント B がロックを開始するとします。このとき、同じことを行います。まず、ロック ノード「my_lock」の下に一時的なシーケンス ノードを作成します。このとき、名前は次のようになります。

次の図を見てみましょう。

クライアント B は 2 番目に連続ノードを作成するため、ZK は内部的にシーケンス番号を「2」として維持します。

次に、クライアント B はロック判断ロジックに従い、「my_lock」ロック ノードの下にあるすべての子ノードを照会し、シーケンス番号の順に並べ替えます。この時点で彼が見ているのは次のようなものです:

同時に、作成したシーケンシャルノードを確認します。それはセットの最初のものですか？明らかにそうではありません。このとき、最初のノードはクライアント A によって作成された、シリアル番号が「01」の連続ノードです。つまりロックが失敗したのです!

ロックが失敗すると、クライアント B は ZK API を介してそのシーケンス ノードの前のシーケンス ノードにリスナーを追加します。 ZK は当然ながら特定のノードを監視できます。

ZK の基本的な使い方がわからない場合は、Baidu で確認できます。非常に簡単です。クライアント B の連続ノードは次のとおりです。

彼の前の連続ノードは下のものではありませんか?

これはクライアント A によって作成されたシーケンシャル ノードです。したがって、クライアントBは

このノードが削除されたかどうかなどの変更を監視するには、このノードにリスナーを追加します。次の図をご覧ください。

その後、クライアント A はセッションをロックした後、何らかのコード ロジックを処理してロックを解除する場合があります。では、ロックを解除するプロセスとは何でしょうか?

実際、それは非常に簡単で、ZK でシーケンス ノードを作成するだけです。

このノードは削除されます。ノードを削除した後、ZK はこのノードを監視するリスナー、つまりクライアント B によって以前に追加されたリスナーに、「監視しているノードが削除され、誰かがロックを解除しました」と通知する責任があります。

このとき、クライアント B のリスナーは、前のシーケンシャル ノードが削除されたこと、つまりロックを解除する前のクライアントが削除されたことを感知します。

この時点で、クライアント B はロックを再度取得するように、つまり、「my_lock」ノードの下に設定されたサブノードを取得するように通知されます。

この時点で、クライアント B によって作成されたセットには連続ノードが 1 つだけあります。次に、クライアント B は、それが実際にセット内の最初の連続ノードであると判断します。ビンゴ！ロックできます！ロックを完了し、後続のビジネス コードを実行するだけです。実行後は再度ロックを解除してください。

実際、クライアント C やクライアント D など、ZK 分散ロックを競合する N 個のクライアントがある場合でも、原理は同様です。

• 全員が立ち上がり、ロックノードの下に次々に一時的な連続ノードを直接作成します。
• 最初のノードでない場合は、前のノードにリスナーを追加します。
• 前のノードがロックを解除する限り、そのノードはキューの先頭に配置されます。これはキューイング メカニズムと同等です。

一時シーケンス ノードを使用するもう 1 つの目的は、一時シーケンス ノードを作成した後にクライアントが誤ってクラッシュしても問題にならないことです。 ZK はクライアントのクラッシュを感知し、対応する一時シーケンス ノードを自動的に削除します。これは、ロックを自動的に解除するか、独自のキューを自動的にキャンセルすることと同じです。

***、Curator フレームワークを使用してロックをロックおよび解除するプロセスを見てみましょう。

実際、オープンソース フレームワークを使用することの良い点は、便利なことです。 Curator フレームワークの ZK 分散ロックのロックと解放の実装原理は前述のとおりです。

ただし、そのコードセットを手動で実装したい場合。それでも少し面倒で、さまざまな詳細、例外処理などを考慮する必要があります。そのため、ZK 分散ロックの使用を検討している場合は、この記事のアイデアを参考にすることができます。

1秒あたり数千件の注文が発生するシナリオでの分散ロックの高同時実行最適化の実践

次に、興味深いトピックについてお話しします。1 秒あたり数千の注文があるシナリオで、分散ロックの同時実行性を最適化するにはどうすればよいでしょうか。

まず、この質問の背景を見てみましょう。以前、友人が社外で面接を受けていたのですが、ある日彼が私に話しかけてきてこう言いました。「国内に優良な電子商取引会社があるんですが、面接官が彼に次のようなシナリオの質問をしました。

注文時に過剰販売を防ぐために分散ロックが使用されているが、注文が 1 秒あたり数千の注文がある高同時実行シナリオで行われる場合、このシナリオに対処するために、分散ロックを高同時実行向けに最適化するにはどうすればよいでしょうか。

彼は、その質問をしたことがなく、何も知らなかったため、その時点では答えられなかったと言いました。実際、私はこの面接の質問を聞いたとき、非常に興味深いと思いました。なぜなら、私が候補者を面接するなら、おそらくもっと幅広い範囲の質問をするだろうからです。

たとえば、インタビュー対象者に、電子商取引の高同時フラッシュセールシナリオにおける在庫過剰販売の解決策、さまざまな解決策の長所と短所、およびその実践について話してもらい、その後、分散ロックのトピックについて話してもらいます。

なぜなら、売られ過ぎ在庫の問題には、悲観的ロック、分散ロック、楽観的ロック、キューのシリアル化、Redis アトミック操作など、多くの技術的な解決策があるからです。

しかし、インタビュアーの兄弟は在庫の過剰販売を解決するために分散ロックの使用を厳しく制限していたので、彼が尋ねたかったのは、高同時実行シナリオで分散ロックの同時実行パフォーマンスを最適化する方法という 1 点だけだったと思います。

インタビュアーの質問の角度は受け入れられると思います。なぜなら、実際に本番環境に導入すると、分散ロックによってデータの正確性は確保されますが、その自然な同時実行能力は少し弱いからです。

偶然にも、私は以前、自分のプロジェクトの他のシナリオで、高同時実行シナリオ向けの分散ロック最適化ソリューションに取り組んだことがあります。したがって、私はこの友人の面接の質問を利用して、分散ロックの高同時実行性最適化のアイデアについてお話ししたいと思います。

在庫の過剰販売はどのようにして発生しますか?

まず、分散ロックを使用しない場合、いわゆる電子商取引の在庫の過剰販売が何を意味するのかを見てみましょう。次の図を見てみましょう。

この図は実は非常にわかりやすいです。注文システムが 2 台のマシンに展開されており、異なるユーザーが同時に 10 台の iPhone を購入したいと考え、各ユーザーが注文システムにリクエストを送信するとします。

次に、各注文システムインスタンスがデータベースをチェックし、現在の iPhone の在庫が 12 台であることを確認しました。 2 人の兄弟はそれを見て大喜びしました。在庫が 12 個あり、購入したいと思っていた 10 個より多かったからです。

したがって、各注文システム インスタンスは、データベースに SQL を送信して注文を行い、10 株を差し引きました。 1 つは在庫を 12 個から 2 個に減らし、もう 1 つは在庫を 2 個から -8 個に減らしました。

もう終わりです、在庫はマイナスです！泣けてくるよ。2人のユーザーに20台のiPhoneを送るなんて無理！どうすればいいですか？

分散ロックを使用して在庫の売れ過ぎの問題を解決するにはどうすればよいでしょうか?

在庫過剰の問題を解決するために分散ロックをどのように使用すればよいでしょうか?実のところ、それは非常に簡単です。前回説明した分散ロックの実装原則を思い出してください。

同じロック キーの場合、同時にロックを取得できるのは 1 つのクライアントのみです。他のクライアントはロックを取得しようと急いで待機します。ロックを取得したクライアントのみが次のビジネス ロジックを実行できます。

コードはおおよそ上記のようになります。では、なぜこれによって在庫の過剰販売を回避できるのかを分析してみましょう。

上記のステップ番号を読めばすぐに理解できるでしょう。

上の図からわかるように、分散ロックを正常に追加できるのは 1 つの注文システム インスタンスのみであり、その後、この 1 つのインスタンスのみが在庫を確認し、在庫が十分かどうかを判断し、在庫を差し引く注文を出し、ロックを解除することができます。

ロックが解除された後、別の注文システムインスタンスをロックできます。次に在庫を確認すると、在庫は 2 個しかないことがわかります。在庫が不足しており購入できないため、注文が失敗します。在庫は-8まで減少しません。

在庫過剰の問題に対する他の解決策はありますか?

もちろんありますよ！たとえば、悲観的ロック、分散ロック、楽観的ロック、キューのシリアル化、非同期キューの分散、Redis アトミック操作などです。当社には、在庫の過剰販売に対する独自の最適化メカニズムがあります。

しかし、前述したように、この記事は分散ロックの同時実行の最適化に関するものであり、在庫過剰の解決策に関するものではないため、在庫過剰は単なるビジネス シナリオです。

同時実行性の高いシナリオにおける分散ロックソリューション

さて、次に、同時実行性の高いシナリオで分散ロック ソリューションがどのような問題を抱えているかを見てみましょう。

これは大きな問題です！兄さん、君がそれを理解したかどうかは分からないよ。分散ロックが追加されると、同じ製品に対する注文リクエストにより、すべてのクライアントが同じ製品の在庫ロック キーをロックすることになります。

例えば、iPhone 製品を注文する場合、ロックキー「iphone_stock」を使用してロックする必要があります。これにより、同じ製品に対する注文リクエストをシリアル化して 1 つずつ処理する必要が生じます。

上の図を何度も見直すと、この問題を理解できるはずです。

ロック後、ロック解除前に在庫確認→注文作成→在庫減算を行うとします。このプロセスのパフォーマンスは非常に高くなるはずです。全体のプロセスには 20 ミリ秒かかりますが、これは良好なはずです。

1 秒は 1000 ミリ秒なので、この製品を連続して処理するには 50 件のリクエストしか処理できません。

たとえば、1 秒あたり 50 件のリクエストが届き、そのすべてが iPhone の注文である場合、各リクエストの処理には 20 ミリ秒かかります。リクエストが 1 件ずつ届いた場合は、50 件のリクエストすべてを処理するのに 1000 ミリ秒かかります。

より深く理解するために、以下の画像をご覧ください。

したがって、これを読んだ後、誰もが少なくとも、過剰在庫の問題に対処するために分散ロックを単純に使用することの欠点を理解します。

不具合としては、複数のユーザーが同時に同じ商品を注文した場合、分散ロックに基づいて処理がシリアル化され、同じ商品に対する大量の注文要求を同時に処理できなくなるというものがあります。

このソリューションは、同時実行性が低く、フラッシュセールのない通常の小規模な電子商取引システムには適している可能性があります。

同時実行性が非常に低く、1 秒あたり 10 リクエスト未満で、単一の製品をフラッシュ販売する瞬間的な高同時実行シナリオがない場合、小規模な電子商取引システムではそのようなシナリオがないため、1 秒間に同じ製品を 1,000 件注文することは実際にはまれです。

高い同時実行性を実現するために分散ロックを最適化するにはどうすればよいでしょうか?

さて、ようやく本題に入りましたが、次は何をすればいいでしょうか?

面接官は「もう行き詰まっています」と言いました。売れ過ぎ在庫は分散ロックを使用することで解決されます。さらに、iPhone には 1 秒間に何千もの注文が入ります。どうすれば最適化できるでしょうか?

先ほどの計算によれば、1秒間に処理できるiPhoneの注文は50件だけです。実際、言うのは非常に簡単です。多くの人が Java の ConcurrentHashMap のソース コードと基本原理を読んでおり、その中心となるアイデアがセグメント化されたロックであることを知っているはずです。

データは多数のセグメントに分割され、各セグメントには個別のロックがあるため、複数のスレッドが同時にデータを変更する場合、異なるセグメントのデータも同時に変更できます。同時に 1 つのスレッドだけが ConcurrentHashMap 内のデータを排他的に変更できるというわけではありません。

さらに、Java 8 では新しい LongAdder クラスが追加されました。これも Java 7 以前の AtomicLong の最適化です。これにより、CAS 操作が高並行性のシナリオで楽観的ロックの考え方を使用するため、多数のスレッドが長時間ループを繰り返すという問題が解決されます。

LongAdder も同様のセグメント化された CAS 操作を使用し、失敗した場合は自動的に次のセグメントに移行して CAS を実行します。

実際、分散ロックの最適化の考え方も同様です。私たちは以前、過剰在庫の問題ではなく、別のビジネス シナリオでこのソリューションを本番環境に実装しました。

ただし、売れ過ぎ在庫のビジネス シナリオはわかりやすく、わかりやすいので、このシナリオを使用して説明します。

次の図を見てみましょう。

これはセグメント化されたロックです。現在 1,000 台の iPhone の在庫がある場合、それを 20 個の在庫セグメントに分割できます。

必要に応じて、stock_01、stock_02 などのデータベース テーブルに 20 個の在庫フィールドを作成したり、Redis などの場所に 20 個の在庫キーを配置したりできます。

つまり、1,000 個の在庫がセグメントに分割され、各セグメントに 50 個の在庫が含まれたことになります。たとえば、stock_01 は在庫 50 個に対応し、stock_02 は在庫 50 個に対応します。

すると、1 秒あたり 1,000 件のリクエストが届きます。素晴らしい！この時点で、実際に単純なランダム アルゴリズムを自分で記述することができます。各リクエストでは、ロックする 20 個のセグメント化されたインベントリからランダムに 1 つが選択されます。

ビンゴ！それでおしまい。最大 20 件の注文リクエストを同時に実行できます。各注文リクエストは在庫セグメントをロックします。そして、ビジネスロジックでは、データベースやRedis内のセグメント化された在庫に対して、在庫の確認→在庫が十分かどうかの判断→在庫の減算といった操作を行うことができます。

これは何に相当しますか?これは、20 ミリ秒で 20 件の注文リクエストを同時に処理することに相当するため、1 秒間に、iPhone の 20 * 50 = 1000 件の注文リクエストを順番に処理できます。

特定のデータがセグメント化されると、誰もが注意しなければならない落とし穴があります。特定の注文リクエストがロックされ、このセグメントの在庫が不足していることが判明した場合、どうすればよいでしょうか。

このとき、自動的にロックを解除し、すぐに次のセグメント化された在庫に切り替えて、再度ロックをかけて処理を試みる必要があります。このプロセスを実装する必要があります。

分散ロック同時実行最適化ソリューションの欠点は何ですか?

確かに欠点はいくつかありますが、その最大のものは、実装が非常に不便で複雑​​すぎることです。

• まず、データをセグメントに保存する必要があります。元々問題なかった在庫フィールドを 20 個の在庫フィールドに分割する必要があります。
• 次に、在庫を処理するたびに、処理するセグメントをランダムに選択するための独自のランダム アルゴリズムを記述する必要があります。
• ***、あるセグメントにデータが不足している場合は、自動的に次のセグメントデータに切り替えて処理する必要があります。

このプロセスは、コードを記述して手動で実装する必要があり、それでも少し手間がかかり、面倒です。

ただし、一部のビジネス シナリオでは分散ロックを使用するため、ロックの同時実行性を最適化し、さらにセグメント化されたロックの技術的ソリューションを使用する必要があります。効果はもちろん非常に良好で、同時実行パフォーマンスを一度に数十倍向上させることができます。

この最適化ソリューションに対するその後の改善: この記事で説明した在庫の過剰販売のシナリオを例に挙げます。このようにプレイすると、自分自身が非常に惨めな思いをすることになります。もう一度言いますが、ここでの在庫の売上げ過剰のシナリオは単なるデモンストレーションのシナリオです。

著者: Huperzeda sinensis

Chinese Huperzine: 10 年以上の BAT アーキテクチャ経験、一流インターネット企業のテクニカル ディレクター。数百人のチームを率いて、数億のトラフィックを処理する複数の高同時実行システムを開発しました。長年の研究で蓄積してきた研究論文や経験の要約を文書にまとめましたので、皆様にご紹介したいと思います。 WeChat 公開アカウント: Shishan’s Architecture Notes (ID: shishan100)。