Java 高同時実行アーキテクチャ設計の概要 (図とテキスト)

この記事は、Java の高同時実行アーキテクチャ設計についての概要 (写真とテキスト) を提供します。必要な方は参考にしていただければ幸いです。

序文

高同時実行性は、フラッシュセールス活動、赤い封筒の受け取りなど、多数のアクティブユーザーと高密度のユーザーが存在するビジネスシナリオでよく発生します。一定の間隔などで

ビジネスをスムーズに実行し、ユーザーに優れたインタラクティブなエクスペリエンスを提供するには、ビジネスの推定同時実行数などの要素に基づいて、独自のビジネス シナリオに適した高同時実行処理ソリューションを設計する必要があります。シナリオ。

ビデオコースの推奨→: 「1000万レベルのデータ同時実行ソリューション (理論と実践)」

インターネット ビジネス関連の製品を長年開発してきた中で、私は幸運にもさまざまな落とし穴に遭遇しましたが、その過程では多くの血と涙がありました。ここにまとめたものを私自身のアーカイブ記録として共有します。それをみんなと一緒に。

1. サーバー アーキテクチャ

開発の初期段階からビジネスが徐々に成熟するまで、サーバー アーキテクチャも比較的単一からクラスタ化、そして分散化へと進化してきました。サービス。

優れたサーバー アーキテクチャには、高い同時実行性をサポートできるサービスが不可欠です。サービスには、負荷の分散が必要であり、データベースにはマスター/スレーブ クラスターが必要で、nosql キャッシュにはマスター/スレーブ クラスターが必要で、静的ファイルにはこれらはすべてビジネスプログラムを可能にするものです。 スムーズな動作を強力にバックアップします。

サーバー部分では、主に運用保守担当者が構築に協力する必要があります。詳細については説明しません。

大まかに必要なサーバー アーキテクチャは次のとおりです:

サーバー

分散負荷 (nginx、Alibaba Cloud SLB など)

リソース監視

分散

データベース

マスター/スレーブ分離、クラスター

DBAテーブル最適化、インデックス最適化など

分配式

nosql

マスタスレーブ分離、クラスタ

マスタスレーブ分離、クラスタ

マスタスレーブ分離、クラスタ

redis

mongodb

memcache

cdn

html

css

js

image

同時実行テスト

高同時実行関連のビジネスでは同時実行テストが必要であり、アーキテクチャ全体の同時実行量を評価するために大量のデータ分析が使用されます。サポートできる。

高い同時実行性をテストするには、サードパーティのサーバーまたは独自のテスト サーバーを使用し、テスト ツールを使用して同時リクエストをテストし、テスト データを分析して同時実行数の見積もりを取得します。これは、危険を冒さずに百戦錬磨のことわざにあるように、早期警告の参考として使用できます。

サードパーティ サービス:

Alibaba Cloud パフォーマンス テスト

同時実行テスト ツール:

Apache JMeter

Visual Studio パフォーマンス負荷テスト

Microsoft Web Application Stress Tool

実践計画

一般計画

毎日のユーザー トラフィックは多いですが、比較的分散しており、場合によってはトラフィックが発生することもあります。

シナリオ: ユーザーのチェックイン、ユーザー センター、ユーザーの順序など

サーバー アーキテクチャ図:

##注:

シナリオ内のこれらのビジネスは、基本的にユーザーがアプリに入った後に操作するものです。ただし、イベント日 (618、ダブル 11 など)、これらのビジネスのユーザー数は多くありません。同時に、これらのビジネス関連のテーブルはすべてビッグ データ テーブルであり、ビジネスのほとんどがクエリ操作であるため、クエリを減らす必要があります。ユーザーは DB に直接アクセスし、最初にキャッシュをクエリし、キャッシュが存在しない場合は DB クエリを実行し、クエリ結果をキャッシュします。

ユーザー関連のキャッシュを更新するには、ハッシュ グループ化にユーザー ID を使用したり、ユーザーを別のキャッシュに分散したりするなど、分散ストレージが必要です。この方法では、キャッシュ セットの合計量は大きくならず、クエリには影響しません。効率。

次のようなスキーム:

ユーザーがサインインしてポイントを獲得

ユーザー分布のキーを計算し、ユーザーの今日のチェックイン情報を見つけるin redis hash

チェックイン情報がクエリされた場合は、チェックイン情報を返します

#チェックイン情報がクエリされなかった場合、DB はチェックインが行われたかどうかをクエリします。そうであれば、チェックイン情報は Redis キャッシュと同期されます。

今日のチェックイン レコードが DB でクエリされていない場合、チェックイン ロジックが実行され、DB が操作されて今日のチェックイン レコードとチェックイン ポイントが追加されます (この DB 操作全体はトランザクション)

キャッシュ チェックイン Redis に情報を送信し、チェックイン情報を返します

Note

同時実行状況では、次のような論理的な問題が発生します。 1 日に複数回チェックインし、ユーザーに複数のポイントを発行します。

私のブログ投稿 [Big Talk プログラマーの目に映る高い同時実行性] には、関連するソリューションが記載されています。

ユーザー注文

ここでは、最初のページにユーザーの注文情報のみがキャッシュされます。通常、ユーザーは 1 ページに 40 個のデータしか表示されません。最初のページで

ユーザーが順序リストにアクセスする場合、それがキャッシュを読み取る最初のページである場合、DB を読んでいない場合は

ユーザーによって配布されたキーを計算します。 、redis ハッシュでユーザーの注文情報を検索します。

If ユーザーの注文情報を照会し、注文情報を返します

存在しない場合は、最初のページで注文データの DB クエリを実行し、Redis をキャッシュして注文情報を返します

ユーザー センター

ユーザー分布のキーを計算し、redisハッシュでユーザーの注文情報を検索

ユーザー情報を問い合わせた場合はユーザー情報を返す

存在しない場合はユーザーDBに問い合わせてキャッシュするredis を実行し、ユーザー情報を返します。

Other Business

上記の例は、比較的単純な高同時実行アーキテクチャであり、同時実行がそれほど高くない場合でも適切にサポートできます。ただし、ビジネスが成長するにつれて、ユーザーの同時実行性も増加し、各サービスは独自の同時実行性アーキテクチャ、独自の分散データベース、NoSQL マスター/スレーブを備えています。ユーザー サービスや注文サービスなどのクラスター。

メッセージ キュー

セカンド セール、インスタント グラブ、その他のアクティビティ ビジネスでは、ユーザーが即座に殺到し、大量の同時リクエストが生成されます

シナリオ: 赤い封筒を定期的に受け取るなど。

サーバー アーキテクチャ図:

#説明:

シナリオでのスケジュールされた収集 たとえば、フラッシュ セール活動のユーザーが適切なタイミングで殺到すると、瞬時にクリティカル ヒットが発生します。保持できず、ダウンしてしまい、ビジネス全体に影響を及ぼします。

like この種のビジネスには、クエリ操作だけでなく、高度な同時データの挿入や更新も含まれます。上記の一般的なソリューションでは解決できません。同時実行時に DB に直接アクセスします。

このビジネスは、メッセージ キューを使用するときに使用されます。メッセージ キューに参加ユーザー情報を追加して書き込むことができます。キューを消費し、キュー内のユーザーに赤い封筒を発行するマルチスレッド プログラム。

解決策は次のとおりです。

赤い封筒を定期的に受信します

通常、redis リストを使用するのが通例です。

ユーザーがアクティビティに参加するとき、ユーザーの参加情報をキューにプッシュします。

次に、ポップするマルチスレッド プログラムを作成します。

##これにより、同時実行性の高いユーザーが通常どおりアクティビティに参加し、データベース サーバーのダウンタイムの危険を回避できるようになります

#レベル 1 キャッシュ

高同時リクエスト接続キャッシュ サーバーが、サーバーが受信できるリクエスト接続の数を超えているため、一部のユーザーは接続の確立がタイムアウトしてデータを読み取れないという問題を抱えています。

したがって、同時実行性が高い場合にキャッシュ サーバーへのヒット数を減らすことができるソリューションが必要です。

現時点では、1 次キャッシュ ソリューションがサイトを使用します。サーバー キャッシュにはデータが保存されます。大規模なデータは一部のみ保存されるため、サイト サーバーのメモリが過剰に使用され、サイト アプリケーションの通常の動作に影響を与えることがないように注意してください。一次キャッシュには有効期限を秒単位で設定する必要があります。具体的な時間はビジネス シナリオに応じて設定されます。目的 同時リクエストが多い場合、接続せずに一次キャッシュからデータを取得できます。キャッシュされた nosql データ サーバーにより、nosql データ サーバーへの負荷が軽減されます。たとえば、APP の最初の画面にある製品データ インターフェイスでは、これらのデータはユーザー向けにカスタマイズされず、公開されません。このインターフェイスのリクエスト量が比較的大きい場合は、一次キャッシュに追加できます。

サーバー アーキテクチャ図:

#nosql キャッシュ データベースを合理的に標準化して使用し、ビジネスに応じてキャッシュ データベース クラスターを分割することで、基本的にビジネスを適切にサポートできます。サイトサーバーのキャッシュを使用しているので、それを有効に活用する必要があります。 静的データ

同時リクエストの多いデータが変化しない場合、データを取得するために独自のサーバーをリクエストする必要がない場合、リソースの負荷を軽減できます。サーバー。

更新頻度が高くなく、データが短い遅延を許容する場合は、データを JSON、XML、HTML などのデータ ファイルに静的に変換し、データを取得するときに CDN にアップロードできます。データが取得できない場合は、管理者がバックグラウンドで操作する際にデータを編集し、静的ファイルを再生成してCDNにアップロードすることでデータを取得できるようになります。同時実行性が高いときに CDN サーバー上で実行されます。 CDN ノードの同期にはある程度の遅延が発生するため、信頼できる CDN サーバー プロバイダーを見つけることも重要です。

#

以上がJava 高同時実行アーキテクチャ設計の概要 (図とテキスト)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。