実戦編-08. クーポンフラッシュセール-cluster_bilibili_bilibili下でのスレッド同時実行セキュリティ問題
高い同時実行性に対処するには、プロジェクトを複数のマシンにデプロイしてクラスターを形成する必要があるため、nginx を構成する必要があります。
1. クラスターをシミュレートする方法
アイデアの ctrl + d を使用して構成を変更し、シミュレーション クラスターを実行する複数の Tomcat を実装します。
次に、nginx 上でノードを構成し、8080/api がバックエンドにプロキシし、バックエンドが各ノード (アップストリーム) の情報を構成します。
ポーリング ノードを実装して負荷分散を実現します。
2. クラスターにより新たな同時実行の問題が発生する
前回の記事では、単一ノードの場合に同時実行セキュリティを実現しましたが、ユーザーが 2 つのフラッシュ セール リクエストを送信し、nginx によって 2 つのノードに割り当てられた場合、ユーザーは 1 つのノードでロックされます (ユーザー ID をモニターとして使用)。異なるノードで有効になるため、同じユーザーの複数のフラッシュ セールス アクションをロックすることはできず、1 人のユーザーと 1 つの注文を保証することもできません。したがって、分散ロックが必要になります。
理由：
上記の intern() 関数は、内容が同じであれば new を使用しても同じアドレスを返すのはなぜですか? 文字列定数プールから文字列のアドレスを求めるので、何度来ても定数プール内の文字列のアドレスが返ってくるので同じです。Tomcat でどのスレッドを実行するかに関係なく、jvm が 1 つしかない場合、定数プールは 1 つだけです。
クラスターにデプロイする場合、異なるサーバーには独自の Tomcat があり、各サーバーには独立した jvm があるため、定数プールも異なります。したがって、intern() の戻り値が同じであるという保証はなく、2 つのサーバー上のロック モニターが同じであるという保証はなく、同じユーザーをロックすることはできません。
1 つの JVM が同じユーザーを内部的にロックすることのみを保証できますが、すべての JVM が同じユーザーをロックすることは保証できません。
