バイト両面: 10Wqps 会員システム、どのように設計するか?

前もって言う

Nien (50 歳以上) の読者コミュニティでは、非常に頻繁に面接で聞かれる次のような質問によく遭遇しますが、答えるのは非常に困難です。

数千万のデータ、システムアーキテクチャをどのように行うか?

10億レベルのデータ、システムアーキテクチャをどうするか?

数千万のトラフィック、システムアーキテクチャをどうするか?

数十億レベルのトラフィック、システムアーキテクチャをどうするか?

同時実行性の高いシステムを構築するにはどうすればよいでしょうか?

最近、小規模パートナーの Byte Ermian が再びこの問題に遭遇しました。

実際、ニンはいつも教科書的な答えを導き出したいと思っていました。

「数千万のデータのパフォーマンスを最適化するにはどうすればよいか?」に対する教科書のような答えが、実はこの業界の事例の中に隠されています。

これは、新しい業界事例「東城永龍会員制システムの高同時実行アーキテクチャ」です。ニエンは、このソリューションをインタビューの側面から再構築して整理し、「Nin Java 」インタビューブック PDF V96 バージョンの参考回答として使用しています。

以下の内容は、ニエン氏自身の 3 レベルアーキテクチャノートとニエンの 3 レベルアーキテクチャ知識体系 (3 レベルアーキテクチャユニバース) に基づいた二次分析です。

『Nin Architecture Notes』、『Nin High Concurrency Trilogy』、『Nin Java Interview Collection』の PDF は、公式アカウント [Technical Freedom Circle] から入手してください。

記事ディレクトリ

東城エロン会員制度のビジネスシナリオ

Tongcheng Elongは、Tongcheng NetworkとTongcheng Travel Group傘下のeLong Travel Networkが2017年12月29日に共同設立した会社です。新会社は、交通機関やホテルなどの両社の有利なリソースを統合し、より先進的な旅行サービスプラットフォームを構築します。。

2018年6月21日、東城エロンは香港証券取引所に目論見書を提出し、共同スポンサーはモルガン・スタンレー、JPモルガン・チェース、CMBインターナショナルであった。

2018 年 11 月 26 日、Tongcheng-Elong は香港証券取引所に正式に上場されました。

Tongcheng-Elong は、空港、ホテル、目的地などの旅行業界チェーンの上流と下流に技術力を提供し、業界のデジタルインテリジェンスのプロセスを加速します。エンドユーザーアプリケーションには次のものが含まれます。

同城APP
eLongアプリ
同城 WeChat ミニプログラム
eLong WeChat ミニプログラム

2021 年第 3 四半期、東城エロンの月間平均アクティブユーザー数は 2 億 7,700 万人に達し、前年比 12.7% 増加し、平均月間有料ユーザーは 3,360 万人に達し、前年比 12.8% 増加しました。。

2021 年 9 月 30 日までの 12 か月間で、Tongcheng-Elong の有料ユーザーは前年比 29.6% 増加して 1 億 9,600 万人に達しました。

東城エロン社内では会員制が基本システムとなっております。

この基本システムは、会社のすべての事業分野の主要な注文プロセスと密接に関連しています。

Tongcheng-Elong プラットフォーム内では、会員システムに障害が発生すると、ユーザーは注文できなくなります。

つまり、会員制度が破綻した場合、その影響範囲は会員制度そのものだけではなく、企業の事業全般に及びます。

したがって、メンバーシップシステムは、高いパフォーマンス、高可用性、および高い同時実行性を確保し、大規模なビジネスプラットフォームに安定した効率的な基本サービスを提供する必要があります。

Tongcheng と eLong の合併に伴い、Tongcheng APP、eLong APP、Tongcheng WeChat Mini Program、および eLong WeChat Mini Program などのマルチプラットフォームのメンバーシップシステムをオープンにする必要があるシステムがますます増えています。

たとえば、WeChat アプレットのクロスマーケティングでは、ユーザーが鉄道の切符を購入し、この時点でホテルの赤い封筒を送りたいとします。これには、ユーザーの統一されたメンバーシップ関係を照会する必要があります。

鉄道の切符は東城会員システムを使用し、ホテルは eLong 会員システムを使用しているため、対応する eLong 会員カード番号が見つかった後でのみ、赤い封筒を会員アカウントに取り付けることができます。

クロスマーケティングシナリオに加えて、統一されたメンバーシップ関係をクエリする必要があるビジネスシナリオは数多くあります。

例えば、注文センター、会員レベル、マイレージ、赤い封筒、頻繁な旅行、実名、各種マーケティング活動など。

したがって、メンバーシップシステムのリクエスト量はますます大きくなり、同時実行性はますます高くなっています。

2022 年のメーデー休暇中の 1 秒あたりの同時 TPS は 20,000 を超えました。

このような大量のトラフィックの影響下で、メンバーシップシステムはどのようにして高いパフォーマンスと高可用性を実現するのでしょうか?

メンバーデータ用の異種ストレージアーキテクチャソリューション

Tongcheng-Elong 内の会員システムは、mysql クラスター + ES クラスターを組み合わせた異種ストレージアーキテクチャを採用しています。

具体的には下図のようになります

mysql の
現在最も注目されているリレーショナルデータベースを使用する理由

しかし、次の 2 つの大きな欠点があります。
- (1) 全文検索には向いていない、インデックスなしの全文検索が発生すると全表検索になり、パフォーマンスが低下する
- (2) mysqlを使用するにはサブデータベースとサブテーブルが必要ですが、現時点では完全なテーブル関連付けを行うことはできません。
elsaticsearch を使用することが検索において本質的な利点である理由
- (1) 転置インデックス、自然な全文検索
- (2) 大きなテーブル、幅の広いテーブル、および非構造化データをサポートします。リレーショナルデータベースとは異なり、単純な検索にはテーブル間の結合テーブルとデータベース間の関連付けが必要です。
mysql+elasticsearch の利点

mysql を使用してデータにアクセスし、es を検索エンジンとして使用してパフォーマンスを確保します

MySQL メンバーのメインライブラリ: 高可用性 + 高同時実行アーキテクチャ

前述したように、すべてのプラットフォームメンバーのバインディング関係データは ES に存在し、メンバーの登録詳細はリレーショナルデータベースに存在します。

当初、メンバーが使用していたデータベースは SQL Server でした。

ある日まで、単一の SQL Server データベースに 10 億を超えるメンバーデータが保存され、サーバーは物理的な限界に達し、それ以上拡張できなくなりました。

自然な成長傾向によれば、SQL Server データベース全体が崩壊するまで、そう長くはかからないでしょう。

皆さん、考えてみてください。SQL Server データベースが崩壊しました。これはどのような災害シナリオですか。

会員データベースが崩壊すると、会員システムも崩壊します。

会員制度が崩壊したとき、会社のすべての事業が崩壊しました。

そう思うと身震いするほどに清々しい気持ちになり、同市のeLongチームは早速DBの移行作業を開始した。

MySQL デュアルセンターパーティションクラスターソリューション

調査の結果、チームはデュアルセンターのサブデータベースとサブテーブルを備えた MySQL クラスターソリューションを選択しました。

mysqlのテーブル構造

メンバーは合計 10 億を超えるデータを保有しており、チームは主要なメンバーデータベースを 1,000 以上のシャードに分割しました。

単一シャードのサイズで言えば、各シャードは約 100 万、単一シャードは数千万未満であり、十分に使用できます。

mysqlマスタースレーブアーキテクチャ

MySQL クラスター全体は 1 つのマスターと 3 つのスレーブのアーキテクチャを採用しています。

マスターライブラリは計算機室Aに、スレーブライブラリは計算機室Bに配置されています。2つの計算機室間でのデータの同期は専用線を介して行われ、遅延は1ミリ秒以内です。

mysqlトラフィックルーティングアーキテクチャ

書き込みルーティング: 書き込みデータは、マスターノードが配置されているコンピュータルーム A にルーティングされます。
読み取りルーティング: すべての読み取りデータは近くのアクセスのためにローカルコンピュータールームにルーティングされ、ネットワーク遅延が短縮されます。

メンバーシステムは、DBRoute を通じてデータの読み取りと書き込みを行います。DBRoute は、トラフィックスイッチに応じてトラフィックを切り替えることができる統合データベースアクセス SDK コンポーネントです。

具体的なアーキテクチャ図を次の図に示します。

このように、デュアルセンターMySQLクラスタアーキテクチャを採用することで可用性が大幅に向上し、たとえコンピュータ室A全体が崩壊しても、コンピュータ室Bのスレーブをマスターにアップグレードしてサービスを提供し続けることができます。

デュアルセンター MySQL クラスターの構築後、チームはストレステストを実施しました。テスト後、同時実行数は 1 秒あたり 20,000 以上に達し、平均所要時間は 10 ミリ秒以内であり、パフォーマンスは基準を満たしています。

会員マスターライブラリのスムーズな移行計画

次の作業は、メンバーシップシステムの基盤となるストレージを SQL Server から MySQL に切り替えることです。これは非常に危険な作業であり、主に次のような問題があります。

メンバーシップシステムは一時的にシャットダウンできません。シャットダウンせずに SQL Server から MySQL への切り替えを完了することは、高速自動車の車輪を交換するようなものです。
会員システムは多くのシステムやインターフェースから構成されており、10年以上開発されてきたため、歴史的な理由から古いインターフェースが多数残されており、ロジックも複雑です。非常に多くのシステムを 1 つずつ整理し、DAL 層のコードを問題なく書き換える必要があります。そうしないと大惨事になります。
データの移行はシームレスである必要があり、10 億を超える在庫データの移行だけでなく、リアルタイムに生成されたデータもシームレスに MySQL に同期される必要があります。また、データ同期のリアルタイム性を確保するだけでなく、データの正確性や SQL Server と MySQL データの整合性も確保する必要があります。

上記の問題点に基づいて、チームは「完全同期、増分同期、およびリアルタイムのトラフィックグレースケールスイッチング」の技術的ソリューションを設計しました。

まず、シームレスなデータの切り替えを実現するために、リアルタイム二重書き込み方式を採用しています。

ビジネスロジックの複雑さと SQL Server と MySQL の技術的な違いにより、MySQL を二重に書き込むプロセスでは書き込みが成功しない可能性があり、書き込みに失敗すると SQL Server と MySQL のデータに不整合が生じます。許可された。

したがって、チームが採用した戦略は、試行中にメインで SQL Server を書き込み、次にスレッドプールを介して MySQL を非同期に書き込むことです。

書き込みに失敗した場合は、3 回再試行し、それでも失敗する場合は、ログを記録し、手動で原因を確認し、解決した後、二重書き込みが失敗せずに一定期間実行されるまで、二重書き込みを続けます。

上記の戦略により、ほとんどの場合、二重書き込み操作の正確性と安定性が保証され、試行中に SQL Server と MySQL のデータに不整合が発生した場合でも、SQL Server に基づいて MySQL を完全に再構築できます。なぜなら、チームが二重書き込み戦略を設計すると、SQL Server が正常に書き込みできること、つまり SQL Server 内のデータが最も完全で正しいことが保証されるからです。

以下に示すように:

二重書き込みについて話した後、チームは「データの読み取り」がどのようなグレースケールであるかを検討します。

全体的なアイデアは、A/B プラットフォームを介してトラフィックを段階的にグレースケールすることです。最初は、トラフィックの 100% が SQL Server データベースを読み取り、その後、MySQL データベースを読み取るトラフィックを徐々に減らします。最初は、1% (ある場合)問題がない場合は、徐々にトラフィックを解放し、最終的には 100% のトラフィックが MySQL データベースを通過します。

徐々にグレースケールのトラフィックが増加するプロセスでは、検証メカニズムが必要であり、検証が OK の場合にのみ、トラフィックをさらに拡大できます。

では、この検証メカニズムはどのように実装されているのでしょうか?

解決策は、非同期スレッドを使用して、クエリリクエスト内の SQL Server と MySQL のクエリ結果が一致しているかどうかを比較し、一致していない場合はログを記録し、不一致の問題が完全に解決されるまで手動で不一致の原因を確認します。その後、トラフィックを徐々にグレースケール化します。

以下に示すように:

したがって、全体的な実装プロセスは次のようになります。

まず、暗くて風が強い夜の真夜中に、トラフィックが最も少ないときに、SQL Server から MySQL データベースへの完全なデータ同期を完了します。

次に、二重書き込みを有効にします。

このとき、ユーザー登録があればリアルタイムで２つのデータベースに二重書き込みされます。

次に、完全同期とリアルタイム二重書き込み有効の間では、この期間中も 2 つのデータベースのデータに差異が存在するため、データの不整合を防ぐために、データを完全にするために再度増分同期が必要になります。

残りの時間は、さまざまなログの監視に費やされ、二重書き込みの問題がないかどうか、データの比較に一貫性があるかどうかなどが確認されます。

この期間は最も長く、最も問題が発生しやすい期間です。

重大な問題が発生し、データの不整合が発生した場合は、最初からやり直す必要があります。

SQL Server に基づいて完全な MySQL データベースを再度構築し、最終的にトラフィックの 100% が MySQL にグレースケールされるまで、トラフィックを再度グレースケールします。この時点で、作業は完了です。グレースケールロジックはオフラインであり、すべての読み取りと書き込みが行われます。 MySQL クラスターに切り替えられます。

MySQL および ES アクティブ/スタンバイクラスターソリューション

このステップを終えると、メインメンバーのライブラリは大丈夫だと思いますが、dal コンポーネントの重大な障害により、チームの考え方が変わりました。

この失敗はひどいもので、社内の多くのアプリケーションがデータベースに接続できなくなり、作成された注文の量が激減しました。

これにより、チームは、データベースが良好であっても、dal コンポーネントの異常によってメンバーシップシステムがハングする可能性があることに気づきました。

そのため、チームはメンバーマスターデータベースのデータソースを再度ヘテロジナイズし、次のようにデータを ES に二重書き込みしました。

dal コンポーネントが失敗するか、MySQL データベースがハングアップした場合は、読み取りと書き込みを ES に切り替えることができます。

MySQL が回復したら、データを MySQL に同期し、最後に読み取りと書き込みのために MySQL データベースに戻ります。

以下に示すように:

ES高可用性ソリューション

ES デュアルセンターアクティブ/スタンバイクラスターアーキテクチャ

Tongcheng と eLong の統合後、プラットフォーム全体のすべてのシステムのメンバーの総数は 10 億人を超えました。

データ量がこれほど大きいと、ビジネス分野のクエリの次元も比較的複雑になります。

一部のビジネスラインは携帯電話番号に基づいており、一部は WeChat Unionid に基づいており、また一部は eLong カード番号などに基づいて会員情報を照会します。

このような大量のデータと非常に多くのクエリディメンションに基づいて、チームは統合されたメンバーシップ関係を保存するために ES を選択しました。

ES クラスターはメンバーシップシステムアーキテクチャ全体において非常に重要ですが、ES の高可用性を確保するにはどうすればよいでしょうか?

まず、チームは、次の図に示すように、ES クラスター自体が高可用性を保証していることを知っています。

ES クラスターの 1 つのノードがダウンすると、他のノードに対応するレプリカシャードがプライマリシャードにアップグレードされ、サービスを提供し続けます。

しかし、それでも十分ではありません。

たとえば、ES クラスタがコンピュータルーム A に展開されているが、コンピュータルーム A が突然電源を失った場合、どうすればよいでしょうか?

たとえば、サーバーハードウェアに障害が発生し、ES クラスター内のほとんどのマシンがダウンした場合、どうすればよいでしょうか?

または、突然非常に人気のあるフラッシュセールイベントが発生し、非常に大規模なトラフィックの波が発生し、ES クラスターが直接破壊されました。どうすればよいでしょうか?

このような状況に直面して、運用保守の兄弟たちをコンピューター室に急行させて問題を解決させますか?

会員制度は会社のすべての事業部門の発注という主要なプロセスに直接影響を及ぼし、障害回復にかかる時間は非常に短くなければならないため、これは非常に非現実的です。運用および保守担当者による手動介入が必要な場合、その時間は非常に短くなります。長すぎるでしょう、これは絶対に耐えられません。

ES の高可用性を実現するにはどうすればよいですか?

チームのソリューションは、ES デュアルセンターアクティブ/スタンバイクラスターアーキテクチャです。

チームにはコンピューター室 A とコンピューター室 B の 2 つのコンピューター室があります。

チームは ES メインクラスターをコンピュータールーム A に展開し、ES スタンバイクラスターをコンピュータールーム B に展開します。

メンバーシステムの読み取りと書き込みはすべて ES メインクラスター内で行われ、データは MQ を介して ES スタンバイクラスターに同期されます。

このとき、ESメインクラスタがダウンした場合には、統一構成により、メンバシステムの読み書きを計算機室BのESスタンバイクラスタに切り替えることで、ESメインクラスタがダウンしてもフェイルオーバーが可能となります。短期間での会員制度の安定運用を実現します。

最後に、ESメインクラスタの障害が復旧した後、スイッチをオンにして障害時のデータをESメインクラスタに同期し、データが同期され整合性が取れた後、メンバーシステムの読み書きをESメインクラスタに切り替えます。集まる。

以下に示すように:

ES トラフィック分離 3 クラスターアーキテクチャ

デュアルセンター ES のアクティブクラスターとスタンバイクラスターがこのステップを達成できれば大きな問題はないと思われますが、昨年のひどい交通ショックにより、チームは考えを変えました。

休日だったので、ある企業がマーケティングキャンペーンを開始しました。

ユーザーからの 1 つのリクエストでは、メンバーシップシステムが 10 回以上呼び出されたため、メンバーシップシステムの TPS が急増し、ES クラスターが爆発寸前になりました。

このインシデントによりチームは恐怖を感じ、発信者を優先し、より洗練された絶縁、サーキットブレーカー、ダウングレード、および電流制限戦略を実装する必要があることに気づきました。

まず、チームはすべての発信者を分類し、リクエストを 2 種類に分けました。

最初のカテゴリは、注文の主要なプロセスに密接に関連するリクエストであり、これらのリクエストは非常に重要であり、高い優先度で保証される必要があります。

2つ目はマーケティング活動に関するもので、リクエスト数が多くTPSが高いものの、発注というメインプロセスには影響を与えないという特徴があります。

これに基づいて、チームは別の ES クラスターを構築しました。これは、高 TPS マーケティングスパイクリクエストに対処するために特別に使用されるため、メインの ES クラスターから分離され、注文というユーザーの主なタスクに影響を与えません。特定のマーケティング活動のトラフィックへの影響、プロセス。以下に示すように:

ES クラスターの深さの最適化と改善

ES のデュアルセンターアクティブクラスタとスタンバイクラスタの高可用性アーキテクチャについて説明した後、チームは ES のメインクラスタの最適化について詳しく説明します。

しばらくの間、チームは非常に苦しみました。つまり、食事のたびに ES クラスターが警察に電話し始めたため、全員が食事のたびに慌てふためき、ES クラスターだけでは対処できないのではないかと不安になったのです。そして会社全体が爆破されるだろう。

では、なぜ食事の時間になったらすぐに警察を呼ぶのでしょうか？

トラフィックが比較的大きいため、ES スレッドの数が急増し、CPU が高速化され、クエリ時間が増加し、それがすべての呼び出し元に送信され、その結果、遅延の範囲が広がります。

では、この問題をどうやって解決すればいいのでしょうか？

ES クラスターを詳しく調べたところ、チームは次の問題を発見しました。

ES 負荷は不当であり、ホットスポット問題は深刻です。ES メインクラスタには数十のノードがあります。多くのシャードをデプロイするノードもあれば、少数のシャードをデプロイするノードもあります。その結果、一部のサーバーに大きな負荷がかかります。トラフィックがピークに達すると、警告が頻繁に発行されます。
ES スレッドプールのサイズが大きすぎるように設定されているため、CPU の負荷が急上昇します。チームは、ES のスレッドプールを設定するとき、一般的にスレッド数はサーバーの CPU コア数に設定されることを知っています。ES のクエリ負荷が高く、スレッド数を増やす必要がある場合でも、スレッド数を増やすことが最適です。「CPU コア * 3 / 2 + 1」を超えないようにしてください。スレッド数の設定が多すぎると、CPU が複数のスレッドコンテキスト間を頻繁に切り替えて、大量の CPU リソースを浪費します。
シャードによって割り当てられたメモリが 100G と大きすぎるため、クエリが遅くなります。チームは、ES インデックスがシャードの数を合理的に割り当て、シャードのメモリサイズを 50G 以内に制御する必要があることを認識しています。シャードによって割り当てられたメモリが大きすぎると、クエリが遅くなり、時間がかかり、パフォーマンスに重大な影響を及ぼします。
文字列型のフィールドにはテキストとキーワードのダブルフィールドが設定されており、記憶容量が2倍になります。会員情報のクエリは関連度に応じてスコアを付ける必要がなく、キーワードに従って直接クエリできるため、テキストフィールドを完全に削除でき、ストレージスペースの大部分を節約し、パフォーマンスを向上させることができます。
ES クエリ。クエリではなくフィルターを使用します。クエリは検索結果の関連性スコアを計算するため、より多くの CPU を消費しますが、メンバー情報のクエリではスコアを計算する必要がなく、この部分のパフォーマンスの低下を完全に回避できます。
ES の計算能力を節約し、メンバーシステムの JVM メモリ内の ES 検索結果を並べ替えます。
ルーティングキーを追加します。チームは、ES クエリがリクエストをすべてのシャードに分散し、すべてのシャードが結果を返した後にデータを集計し、最終的に呼び出し元に結果を返すことを知っています。チームがデータがどのシャードに分散されているかを事前に知っている場合、多数の不要なリクエストを削減し、クエリのパフォーマンスを向上させることができます。

上記の最適化後の結果は非常に重要で、ES クラスターの CPU が大幅に削減され、クエリのパフォーマンスが大幅に向上しました。ES クラスターの CPU 使用率:

時間のかかる会員制インターフェース:

メンバーシップ Redis キャッシュソリューション

長い間、メンバーシップシステムは次の 2 つの主な理由によりキャッシュされませんでした。

まず、上記の ES クラスターのパフォーマンスは非常に優れており、同時実行数は 1 秒あたり 30,000 を超え、99 パーセンタイルには約 5 ミリ秒かかり、さまざまな困難なシナリオに十分に対処できます。
第二に、ビジネスによっては、メンバーの結合関係にリアルタイムの一貫性が必要となる場合があり、メンバーシップは 10 年以上開発された古いシステムであり、多くのインターフェースと多くのシステムから構成される分散システムです。

したがって、考慮されていないインターフェイスが存在し、キャッシュが時間内に更新されない限り、データがダーティになり、データの不整合が発生します。

例えば：

ユーザーはアプリで WeChat の注文を確認できません
APPとWeChatの会員レベルとマイレージは統合されません
WeChat と APP はクロスマーケットなどできません。

では、なぜ再度キャッシュする必要があるのでしょうか?

これは、今年の航空券のブラインドボックスアクティビティにより、それがもたらす瞬間的な同時実行性が高すぎるためです。

会員システムは安全で健全ですが、依然として不安は消えず、念のため、最終的にキャッシングソリューションを導入することにしました。

ESの1秒近い遅延によるRedisキャッシュデータの不整合問題の解決策

メンバーシップキャッシュソリューションを作成する過程で、キャッシュされたデータの不整合につながる ES によって引き起こされる問題に遭遇しました。

ES の稼働データはほぼリアルタイムであることをチームは知っています。ES にドキュメントを追加するとすぐに確認できるのですが、そのドキュメントが見つからず、確認するまでに 1 秒待つ必要があります。

以下に示すように:

ES のほぼリアルタイムのメカニズムにより、Redis キャッシュデータの不整合が生じるのはなぜですか?

具体的には、ユーザーが APP アカウントからログアウトすると、ES を更新して APP アカウントと WeChat アカウント間のバインド関係を削除する必要があります。

ES のデータ更新はほぼリアルタイムです。つまり、1 秒後に更新されたデータをクエリできます。

この 1 秒以内に、ユーザーのメンバーシップバインディング関係をクエリするリクエストがあり、最初に Redis キャッシュをチェックインして存在しないことがわかり、次に ES をチェックインしてそれを見つけますが、その前に古いデータが見つかります。アップデート。

最後に、リクエストはクエリされた古いデータを Redis キャッシュに更新して返します。

このようにして、1 秒後に ES 上のユーザーのメンバーシップデータが更新されますが、Redis キャッシュ内のデータは古いデータのままであるため、Redis キャッシュと ES データの間で不整合が発生します。以下に示すように:

この問題に直面したら、どうやって解決すればよいでしょうか?

チームのアイデアは、ES データを更新するときに 2 秒の Redis 分散同時ロックを追加し、その後、Redis 内のメンバーのキャッシュデータを削除して、キャッシュデータの一貫性を確保することです。

この時点でデータのクエリ要求がある場合は、まず分散ロックを取得し、メンバー ID がロックされていること、つまり ES によって更新されたばかりのデータがまだ有効になっていないことを確認してから、この時点でデータをクエリした後、の場合、Redis キャッシュは更新されず、直接返されるため、キャッシュされたデータの不整合の問題が回避されます。

以下に示すように:

一見すると、上記の解決策には問題がないように見えますが、慎重に分析すると、キャッシュされたデータの不整合が生じる可能性があります。

たとえば、更新リクエストが分散ロックを追加する前に、分散ロックを取得するためのクエリリクエストが 1 つだけありますが、この時点ではロックがないため、キャッシュの更新を続けることができます。

しかし、キャッシュを更新する直前にスレッドがブロックされ、その際に更新要求が来て分散ロックが追加され、キャッシュが削除されました。更新リクエストの操作が完了すると、クエリリクエストのスレッドがアクティブになり、このときに更新キャッシュが実行され、ダーティデータがキャッシュに書き込まれます。

見つかりましたか？この問題の主な核心は、「キャッシュの削除」と「キャッシュの更新」の間に同時実行性の競合があることですが、これらが相互に排他的である限り、問題は解決できます。

以下に示すように:

統計によると、キャッシュソリューションの導入後、キャッシュヒット率は 90% 以上になり、ES への負担が大幅に軽減され、メンバーシップシステムの全体的なパフォーマンスが大幅に向上しました。

Redis デュアルセンターマルチクラスターアーキテクチャ

次に、チームは Redis クラスターの高可用性を確保する方法を検討しました。

以下に示すように:

Redis クラスターの高可用性に関して、チームはデュアルセンターマルチクラスターモデルを採用しました。

一連の Redis クラスターをコンピュータールーム A とコンピュータールーム B にそれぞれデプロイします。

キャッシュされたデータを更新するときは、二重書き込みを行います。両方のコンピュータールームの Redis クラスターが正常に書き込まれた場合にのみ、成功が返されます。

キャッシュされたデータをクエリするときは、遅延を減らすためにコンピュータルームの近くでクエリを実行します。

これにより、たとえコンピュータ室A全体が破綻しても、コンピュータ室Bは引き続き充実した会員サービスを提供することができる。

見通し: より洗練されたトラフィック制御とダウングレード戦略

どのようなシステムでも 100% 問題がないことを保証することはできないため、チームは障害を考慮した設計、つまりより洗練されたフロー制御と劣化戦略を持たなければなりません。

より洗練されたフロー制御戦略

ホットスポット制御。不正請求のシナリオでは、同じ会員 ID に対して大量のリクエストが繰り返され、ホットアカウントが形成され、これらのアカウントへのアクセスが設定されたしきい値を超えると、トラフィック制限戦略が実行されます。
発信側アカウントに基づくフロー制御ルール。この戦略は主に、呼び出し元のコードのバグによって引き起こされる大量のトラフィックを防ぐことを目的としています。たとえば、ユーザー要求では、呼び出し元がメンバーシップインターフェイスをループで何度も呼び出すため、メンバーシップシステムのトラフィックが何度も突然増加します。したがって、発信アカウントごとにフロー制御ルールを設定し、しきい値を超えた場合のフロー制限ポリシーを実装する必要があります。
グローバルフロー制御ルール。チームメンバーシップシステムは、1 秒あたり 30,000 TPS 以上の同時リクエストに耐えることができます。この時点でひどいトラフィックが到来すると、TPS は 100,000 にも達します。このトラフィックの波によってすべてのメンバーシップデータベースと ES が破壊されるのではなく、、メンバーシップシステムの許容範囲を超えるトラフィックをファストフェールした方がよく、少なくとも 30,000 TPS 以内のメンバーリクエストは正常に応答でき、メンバーシップシステム全体が崩壊することはありません。

より洗練されたダウングレード戦略

平均応答時間に基づいてダウングレードします。メンバインターフェイスは他のインターフェイスにも依存しており、他のインターフェイスの呼び出しの平均応答時間がしきい値を超えると、準縮退状態になります。次の 1 秒間の受信リクエストの平均応答時間が引き続きしきい値を超えた場合、次の時間枠でヒューズが自動的に切断されます。
外れ値の数と外れ値の割合に基づく降格。メンバインタフェースが依存する他のインタフェースで例外が発生した場合、1分以内の例外数が閾値を超えるか、例外総数と1秒あたりのスループットの割合が閾値を超えると、縮退状態になり、次の時間枠内で自動的に融合します。

現在、チームの最大の問題点は、メンバーの通話アカウントの管理です。企業内でメンバーインターフェイスに電話をかけたい場合は、通話アカウントを申請する必要があり、チームはアカウントの使用シナリオを記録し、トラフィック制御とダウングレード戦略のルールを設定します。

ただし、実際に利用する過程で、アカウントを申請した同僚が他の部署に異動する場合があり、その際に会員システムに電話をかける場合もありますので、手間を省くため再度会員アカウントを申請することはしませんが、以前のアカウントを直接使用するため、チームはメンバーアカウントの具体的な使用シナリオを判断できなくなり、より洗練されたフロー制御やダウングレード戦略を実装することができなくなります。したがって、次に、チームはすべての発信アカウントを 1 つずつ分類することになります。これは非常に大規模で面倒な作業ですが、方法はなく、しっかりと行う必要があります。

第 33 章ビデオ: 10Wqps の基本的なユーザープラットフォームのアーキテクチャと実践

この記事の内容は、ニエンの「第33章ビデオ：10Wqpsの基本ユーザープラットフォームアーキテクチャと実践運用」のプロジェクト紹介に掲載させていただきます。

また、履歴書のハイライトを再構築およびアップグレードするのに役立つサポート履歴書テンプレートを提供し、最終的には大規模な工場に入社し、構造を構築し、高給与を得るのに役立ちます。

したがって、上記は「教科書的な」答えです

ステーション B の計画と組み合わせると、全員が以前のインタビューの質問に戻ります。

数千万のデータ、システムアーキテクチャをどのように行うか?
10億レベルのデータ、システムアーキテクチャをどうするか?
数千万のトラフィック、システムアーキテクチャをどうするか?
数十億レベルのトラフィック、システムアーキテクチャをどうするか?
同時実行性の高いシステムを構築するにはどうすればよいでしょうか?

上記の解決策は完璧な答えであり、「教科書」の答えです。

フォローアップでは、Nien が業界の事例に基づいて、ますます興味深い回答を提供します。

もちろん、そのような問題が発生した場合は、Nien に助けを求めることができます。

推奨読書

「バースト、“自慢”を頼りにJD.comで暮らし、月給4万」

「激しすぎる、“自慢”を頼りに月給3万のSFエクスプレスで生きていく」

「爆発しました...京東は40の質問を要求し、合格後に50W以上を要求しました」

「質問はしびれます...アリは同時に 27 の質問をし、合格後は 60W 以上でした」

「Baiduは狂ったように3時間要求しました、Dachangはオファーを受け取りました、男は本当に冷酷です！」」

「あなたは無慈悲すぎますか: 高度な Java に直面するのは、どれほど困難で無慈悲なことでしょう。」

「1時間のバイトの狂気、その男はオファーを受け取りました、それはあまりにも冷酷です！」」

" Didi のオファーを受け入れる: この男の 3 つの経験から、何を学ぶ必要がありますか? 」

『Ninのアーキテクチャノート』『Ninの高同時実行性三部作』『NinのJavaインタビュー集』PDFは下記公式アカウント【Technical Freedom Circle】から入手してください↓↓↓