1. オンライン機能システム

主流のインターネット製品では、古典的な計算広告、検索、推奨から、垂直分野のルート計画、ドライバー派遣、インテリジェントな材料設計まで、人工知能技術に基づく戦略システムが製品機能のあらゆる側面に浸透しています。それに応じて、各戦略システムは、モデルアルゴリズムまたは手動ルールの要求に対する正確な応答をサポートするために、多数のオンライン機能と切り離すことはできません。そのため、機能システムは、オンライン戦略システムをサポートする重要な柱となっています。 Meituan Dianping の技術ブログでは、これまでにも、機能システムに関する多数の記事を公開しています。たとえば、「機械学習におけるデータクリーニングと機能処理の概要」では、機能生成プロセスにおけるオフラインデータクリーニングとマイニングの方法の紹介に焦点を当てています。また、「Takeaway Feature Archives: ビジネスエンパワーメントツール」では、さまざまなストレージエンジンを使用してさまざまな機能データクエリ要件を解決することに焦点を当てています。テイクアウト注文システムの機能生成フレームワークは、機能計算、データ同期、オンラインクエリの機能生成パイプラインに重点を置いています。

この記事では、Meituan ホテルと旅行のオンライン機能システムをプロトタイプとして取り上げ、オンラインデータアクセスの観点から実際によく見られる技術的なポイントを紹介し、高同時実行状況下でオンライン機能システムが直面する問題を解決することに重点を置いています。

1.1 オンライン機能システムフレームワーク - 生産、スケジュール、サービスの統合

オンライン フィーチャ システムは、システム コンテキストを通じて関連するフィーチャ データを取得するオンライン サービスです。その機能は、オンラインでフィーチャ クエリ サービスを提供する単純なキー値 (KV) ストレージになることも、一般的なフィーチャ生成、統合フィーチャ スケジューリング、リアルタイム フィーチャ モニタリングなどのフィーチャ サービス システムの完全なセットにまで及ぶこともできます。シンプルで使いやすい機能システムは、わずか数人日で完成できると言えますが、複雑なビジネスシナリオでは、これをより便利に、より速く、より安定したものにするには、チームの長期的な蓄積が必要です。

上記の構造図は統合機能システムの概要です。下から上に向かってデータの流れの方向を示しています。各部分の機能は次のとおりです。

• データ ソース: 機能を計算するために使用される生データ。ビジネスニーズに応じて、データソースは分散ファイルシステム (Hive など)、リレーショナルデータベース (MySQL など)、メッセージキュー (Kafka など) などになります。
• 機能生成: この部分は、さまざまなデータ ソースからデータを読み取り、機能を生成するためのコンピューティング フレームワークを提供する役割を担います。運用フレームワークは、データ ソースの種類とさまざまなコンピューティング要件に基づいて包括的に設計する必要があるため、運用フレームワークのセットが複数存在することになります。
• フィーチャのインポート: この部分は、フィーチャ サービスが読み取れるように、計算されたフィーチャをオンライン ストレージに書き込む役割を担います。このセクションでは、インポート ジョブ間の依存関係、同時書き込みの速度と一貫性などの問題に焦点を当てます。
• 機能サービス: この部分は、機能システム全体の中核機能部分であり、オンライン機能ストレージおよびアクセス サービスを提供して、上位レベルの戦略システムに直接サービスを提供します。

上記のプロセスに従って、機能のライフサイクルは、読み取り、計算、書き込み、保存、取得の 5 つのステップに抽象化できます。プロセス全体が機能システム フレームワーク内で一体となり、機能エンジニアリングの統合ソリューションとして機能します。この記事では、主にフィーチャー サービスのコア機能である「保存」と「検索」に焦点を当て、一般的な実践的な経験をいくつか紹介します。機能制作、システムフレームワークなど、機能システムの拡張部分については、以降の記事で詳しく紹介します。

1.2 フィーチャシステムの核 - 保存と検索

簡単に言えば、フィーチャ システムのコア機能は、各リクエスト内の関連するディメンションのフィーチャ セットを保存し、すばやく抽出するために使用される大規模な HashMap と考えることができます。しかし、実際の状況はHashMapほど単純ではありません。当社の一般的なオンライン機能システム（Datahub）のシステム指標を例にとると、そのコア機能は主に保存と読み取りの面で課題に直面しています。

1. 高い同時実行性: ポリシー システムはユーザー指向であり、サーバーのピーク QPS は 10,000 を超え、データベースのピーク QPS は 100 万を超えます (バッチ要求による)。
2. 高いスループット: 各リクエストには数千の機能が含まれる可能性があり、ネットワーク IO が高くなります。平均的なサーバー ネットワーク出力トラフィックは 500 Mbps で、ピークは 1.5 Gbps です。
3. ビッグデータ: オンラインで必要な特徴データはオフラインの Hive ライブラリほど大きくはありませんが、データ項目数は 10 億を超え、バイト数は TB レベルに達します。
4. 低レイテンシ: ユーザーのリクエストに応答してユーザー エクスペリエンスを維持するには、インターフェイスのレイテンシを可能な限り低くする必要があり、サーバー側の TP99 インジケーターは 10 ミリ秒未満である必要があります。

上記の指標数値は、当社のシステムの参考値です。各部門や各企業の機能システムの実際の規模は大きく異なる場合があります。ただし、機能システムの規模に関係なく、その中核となる目標は、高同時実行性、高スループット、ビッグデータ、低レイテンシを考慮することですが、それぞれ優先順位が異なります。システム最適化の方向が複数の目的である場合、限られたリソース内ですべてを達成するために 1 つの方法を独立して使用することはできません。私たちに残されているのは、最も重要なビジネス要件と、それらの特性に対応するソリューションです。

2. オンライン機能アクセス技術

このセクションでは、オンライン機能システムで一般的に使用されるアクセス手法をいくつか紹介し、私たちの武器庫を充実させます。主な内容は詳細なシステム設計ではなく、いくつかの一般的な問題に対する一般的な技術的解決策です。しかし、前のセクションで述べたように、適切なテクノロジーを使用して、戦略的なニーズに基づいて対応する計画を策定する方法は、すべての建築家の中心的な価値です。

2.1 データの階層化

フィーチャデータの総量が TB レベルに達すると、単一のストレージ メディアでは完全なビジネス ニーズをサポートすることはほとんどできなくなります。高性能オンライン サービス メモリまたはキャッシュは、データ量に関してはほんのわずかです。分散 KV ストレージはより大きなストレージ スペースを提供できますが、シナリオによっては速度が十分ではありません。 Redis/Memcache、HBase、Tair など、オープンソースの分散 KV ストレージまたはキャッシュ ソリューションは数多くあります。これらのオープンソース ソリューションには、機能とパフォーマンスの向上に継続的に取り組んでいる多数の貢献者がいるため、この記事では詳細には触れません。

オンライン機能システムを構築するには、実際に機能データがどのようなものかを理解する必要があります。一部のデータは非常にホットであり、メモリコピーまたはキャッシュを通じて最小限のメモリコストで多数のリクエストをカバーできます。一部のデータはホットではありませんが、アクセスに安定した高速な応答速度が必要な場合は、フルメモリに基づく分散ストレージ ソリューションが適切な選択肢です。非常に大きいデータや急速に増加しているデータの場合、ディスク バックアップを備えたストレージ ソリューションを選択する必要があります。また、さまざまな読み取りおよび書き込みの分散に基づいてストレージ テクノロジを選択する必要があります。

ビジネスが一定レベルまで発展すると、単一の機能タイプではすべてのビジネスニーズをカバーすることが難しくなります。したがって、ストレージ ソリューションを選択するときは、特徴の種類に応じてデータを階層化する必要があります。階層化後、さまざまなストレージ エンジンがポリシー サービスに機能データを均一に提供します。これは、システムのパフォーマンスと機能性の両方を維持するためのベスト プラクティスです。

2.2 データ圧縮

多数のオフライン機能をオンライン システムにロードし、システム間で転送すると、メモリやネットワーク帯域幅などのリソースにかなりのオーバーヘッドが発生します。データ圧縮は、時間とスペースの交換の典型的な例であり、多くの場合、スペースの使用量を大幅に削減できるため、貴重なオンライン メモリと帯域幅のリソースに大きな恩恵をもたらします。データ圧縮の基本的な考え方は、情報の冗長性を減らすことです。フィーチャシステムのアプリケーションシナリオでは、いくつかの実践的な経験を蓄積しており、それを皆さんと共有します。

2.2.1 保存形式

特徴データは、単に特徴名と特徴値を指します。ユーザーのポートレートを例にとると、ユーザーには年齢、性別、趣味などの特性があります。通常、このような機能データを保存する方法はいくつかあります。

1. JSON 形式。機能名と機能値のペアを完全に保持し、JSON 文字列の形式で表現されます。
2. メタデータ抽出は、Hive と同様に、特徴名 (メタデータ) が個別に保存され、特徴データは文字列形式の特徴値のリストで表されます。
3. メタデータの固定化でもメタデータは個別に保存されますが、統一された文字列型ではなく、Integer、Double などの強力な型を使用して各機能を定義します。

3 つの形式にはそれぞれ長所と短所があります。

1. JSON 形式の利点は、特徴の数を可変長にできることです。ユーザーのポートレートを例にとると、ユーザー A には年齢と性別のラベルがある場合があります。 Bユーザーは出身地や趣味のタグをつけることができます。タグの種類はユーザーによって大きく異なり、すべて便利に保存できます。ただし、欠点は、各機能セットに機能名を保存する必要があり、機能タイプが非常に同質である場合、冗長な情報が多数含まれることになることです。
2. メタデータ抽出の特性は、JSON 形式とは逆です。特徴値そのもののみを保持し、特徴名はメタデータとして別途保存されるため、冗長な特徴名の保存が削減されます。ただし、欠点は、データ形式が均一である必要があり、特徴を追加または削除する必要がある場合、メタデータを変更した後にデータセット全体を更新する必要があることです。
3. メタデータの固定化の利点はメタデータの抽出の利点と同じであり、より多くのスペースを節約できます。ただし、そのアクセス プロセスには独自のシリアル化が必要であり、実装が難しく、読み取りと書き込みの速度にコストがかかります。

フィーチャー システムでは、フィーチャー データのバッチは通常完全に同質です。同時に、高同時実行でのバッチ リクエストに対処するために、実際にはメタデータ抽出をストレージ ソリューションとして使用しており、JSON 形式と比較して 2 ～ 10 倍のスペースを節約できます (具体的な比率は、フィーチャー名の長さ、フィーチャーの数、フィーチャー値の種類によって異なります)。

2.2.2 バイト圧縮

データ圧縮に関しては、ロスレス バイト圧縮アルゴリズムの使用を考えるのが簡単です。ロスレス圧縮の主な考え方は、頻繁に発生するパターンをより短いバイトコードで表現することです。オンライン フィーチャ システムの読み取りおよび書き込みモードは、データ全体を 1 回書き込み、それを 1 つずつ複数回読み取るものであるため、グローバル圧縮ではなく、単一のデータに対して圧縮を実行する必要があります。現在、Java で実装されている主流の短いテキスト圧縮アルゴリズムには、Gzip、Snappy、Deflate、LZ4 などがあります。私たちは、主に 1 つのメッセージの平均圧縮速度、1 つのメッセージの平均解凍速度、および圧縮率という 3 つの指標から上記のアルゴリズムを比較する 2 セットの実験を実施しました。

データセット: それぞれ 100,000 個の特徴レコードを含む 2 つの実際のオンライン特徴データセットを選択しました。レコードはプレーンテキスト形式で、平均長さは 300 ～ 400 文字 (600 ～ 800 バイト) です。

圧縮アルゴリズム: Deflate アルゴリズムには 1 ～ 9 の圧縮レベルがあります。レベルが高いほど圧縮率が高くなりますが、操作時間は長くなります。 LZ4 アルゴリズムには 2 つの圧縮レベルがあり、0 と 1 で表されます。また、LZ4 には JNI、Java Unsafe、Java Safe という異なる実装バージョンがあります。詳細な違いについては、https://github.com/lz4/lz4-java を参照してください。ここでは詳しく説明しません。

実験結果グラフのミリ秒時間は、単一レコードの圧縮または解凍時間です。圧縮率は、圧縮前のバイトコードの長さ / 圧縮後のバイトコードの長さとして計算されます。すべての圧縮アルゴリズムの圧縮/解凍時間は、一般的に圧縮率が増加するにつれて長くなることがわかります。その中で、LZ4 の Java Unsafe バージョンと Java Safe バージョンは、プラットフォームの互換性の問題により、明らかな速度異常を示しました。

使用シナリオ (1 回の完全書き込み、1 つずつの複数の読み取り) に基づいて、機能システムの主なサービス指標は、高い機能同時実行性における応答時間と機能データ ストレージ効率です。そのため、実際に圧縮機能で重視される指標は、解凍速度が速いことと圧縮率が高いことであり、圧縮速度は必ずしも高い必要はありません。したがって、上記の実験におけるさまざまなアルゴリズムのパフォーマンスを考慮すると、Snappy の方が私たちのニーズに適しています。

2.2.3 辞書圧縮

圧縮の本質は、共通性を活用し、情報量に影響を与えずに再エンコードして、スペースの使用量を削減することです。前のセクションのバイト圧縮は単一行の圧縮であるため、同じレコード内の共通点にのみ適用でき、グローバルな共通点を考慮することはできません。たとえば、あるユーザーディメンションの特徴量がすべてのユーザーでまったく同じであるとします。バイト圧縮では、各値を 1 つずつ圧縮することでストレージスペースを節約することはできませんが、繰り返し出現する繰り返し値は実際には 1 つだけであることがわかっています。圧縮アルゴリズムのウィンドウ サイズの制限により、単一のレコード内であっても長いパターンを考慮することは困難です。したがって、グローバル特徴値に対して辞書統計を実行し、頻繁なパターンを自動または手動で辞書に追加して再エンコードすることで、短いテキストバイト圧縮の制限を解決できます。

2.3 データ同期

各リクエストと戦略の計算に大量の機能データが必要な場合 (たとえば、一度に何千もの広告主機能をリクエストする場合)、非常に強力なオンライン データ取得機能が必要になります。機能を保存するさまざまな方法の中で、ローカル メモリにアクセスすることが、間違いなく最高のパフォーマンスを実現するソリューションです。ローカル メモリ内の機能データにアクセスするには、通常、メモリ コピーとクライアント キャッシュという 2 つの効果的な方法があります。

2.3.1 メモリコピー技術

データの総量が大きくない場合、ポリシー ユーザーは機能データのコピーをローカルに完全にミラーリングできます。このミラーはメモリ コピーと呼ばれます。メモリ コピーの使用はローカル データの使用とまったく同じであり、ユーザーはリモート データ ソースの存在を心配する必要がありません。メモリ コピーは、特定のプロトコルを介してデータ ソースと同期して更新する必要があります。このタイプの同期テクノロジは、メモリ コピー テクノロジと呼ばれます。オンライン機能システムのシナリオでは、データ ソースは KV タイプのデータ セットとして抽象化でき、メモリ コピー テクノロジでは、このようなデータ セットをメモリ コピーに完全に同期する必要があります。

プッシュとプル – タイムリーさと一貫性

一般的に、データ同期にはプッシュとプルの 2 種類があります。プッシュ テクノロジーは比較的シンプルで、現在一般的なメッセージ キュー ミドルウェアに依存しており、要求に応じてデータの変更をメモリ コピーに送信できます。ただし、重複や漏れのない信頼性の高いメッセージ キュー通知が実現されたとしても (通常は多大なコストがかかります)、初期化中にバッチ データ同期の問題が残ります。したがって、Push はメモリ コピーの適時性を向上させる手段としてのみ使用できます。本質的に、メモリ コピーの同期は依然として Pull プロトコルに依存しています。プル型同期プロトコルには、べき等性という非常に優れた特性があります。同期が失敗しても成功しても、次の新しい同期には影響しません。

プル プロトコルには多くのオプションがあります。最も単純なのは、毎回すべてのデータをプルするという基本的なプロトコルです。ただし、ビジネス ニーズではデータ同期の効率を追求する必要があるため、より効率的な Pull プロトコルを使用することが重要です。取得されるデータの量を減らすために、これらのプロトコルは基本的に、可能な限り最も正確なデータの違い (Diff) を効率的に計算し、必要なデータの変更を同期することを目指しています。ここでは、エンジニアリングの実践で使用した 2 つの Pull 型データ同期プロトコルを紹介します。

バージョン番号に基づく同期 - 再生ログ（RedoLog）と劣化アルゴリズム

データ ソースが更新されると、データの変更ごとに、バージョン番号ベースの同期アルゴリズムによって、この変更に一意の増分バージョン番号が割り当てられ、更新キューを使用して、すべてのバージョン番号に対応するデータの変更が記録されます。

メモリ コピーが同期要求を開始すると、最後に同期を完了したときのコピーの最新バージョン番号が保持されます。つまり、このバージョン番号以降のすべてのデータ変更をプルオーバーする必要があります。要求を受信すると、データ ソースは更新キューからバージョン番号より大きいすべてのデータ変更を検索し、データ変更を要約し、更新が必要な最終的な Diff を取得して、イニシエーターに返します。このとき、メモリ コピーでは Diff データの更新のみが必要です。

ほとんどのビジネス シナリオでは、機能データの生成は統合された更新サービスに統合されるため、増分バージョン番号を連続的に生成できます。分散データ更新環境の場合は、分散 ID ジェネレーターを使用して増分バージョン番号を取得する必要があります。

もう 1 つの問題は、キューの長さを更新することです。最適化を行わない場合、更新キューは理論上は可能な限り長くなり、データセットのサイズを超えることもあります。最適化方法の 1 つは、更新キューの最大長を制限することです。長さが制限を超えると、マージ操作が実行されます。マージ操作は、キュー内のデータをペアでマージします。大きい方のバージョン番号が、マージ後のバージョン番号として使用されます。マージされた更新されたデータ セットは、2 つのデータ セットの結合です。マージ後、新しいキューの長さは元の更新キューの半分に短縮されます。

マージ後の更新キューでは、同期 Diff 計算に同じアルゴリズムを使用できます。つまり、最後の更新よりもバージョン番号が大きいキュー内のすべてのデータ セットを検索します。バージョン番号のマージにより、計算された Diff は完全に正確な更新データではなくなったことがわかります。キュー内の最も古い更新データ セットには、同期されたデータが含まれている可能性がありますが、このような劣化は同期の正確性には影響せず、わずかな同期冗長性を引き起こすだけです。冗長性の量は、Diff 内の最も古いデータ セットがマージされた回数によって異なります。

MerkleTree 同期 - データセット比較アルゴリズム

バージョン番号ベースの同期は、ビジネスの変更履歴を記録し、同期されていない履歴レコードを再生して Diff を取得する RedoLog と同様の考え方を使用します。増え続ける RedoLog を記録するにはかなりのオーバーヘッドが必要になるため、元のログを縮退させるために Merge 戦略が使用されます。バッチ更新またはマイクロバッチ更新の場合、バージョン番号ベースの同期アルゴリズムは適切に機能します。逆に、データがリアルタイムで更新される場合は、大量の RedoLog が発生し、すぐに劣化し、同期の効率に影響します。

Merkle Tree 同期アルゴリズムは別のアプローチを採用しています。簡単に言うと、2 つのデータ セットの差異を毎回直接比較して Diff を取得します。まず、最も単純なアルゴリズムを見てみましょう。メモリコピーがすべてのデータのハッシュ値をデータソースに送信するたびに、データソースはデータセット全体を比較し、ハッシュ値が異なるデータに対して同期操作を実行します。これにより、2 つのデータセット間の Diff が正確に計算されます。しかし、明らかな問題は、すべてのデータのハッシュ値を毎回送信することが、さらにいくつかのデータを送信することよりも簡単ではない可能性があることです。 Merkle Tree 同期アルゴリズムは、Merkle Tree データ構造を使用してこの比較プロセスを最適化します。

簡単に言えば、Merkle Tree はすべてのデータ セットのハッシュ値をツリーに整理し、このツリーのリーフ ノードは 1 つのデータ (またはデータ グループ) のハッシュ値を表します。中間ノードの値は、そのすべての子のハッシュ値をハッシュすることによって取得され、それをルートとするサブツリーに含まれるデータの全体的なハッシュを表します。明らかに、ハッシュの競合を考慮せずに、2 つの Merkle Tree ルート ノードが同じである場合、これらは 2 つの完全に同一のデータ セットであることを意味します。

レプリカによってMerkle Tree同期プロトコルが開始され、レプリカのルートノード値がデータソースに送信されます。データソースのルートノードのハッシュ値と一致している場合は、データの変更はなく、同期が完了します。それ以外の場合、データ ソースはルート ノードのすべての子ノードのハッシュを再帰比較のためにレプリカに送信します。異なるハッシュ値については、リーフノードまで取得し続けることで、変更されたデータを完全に判別できます。バイナリ ツリーを例にとると、すべてのデータ同期は最大 LogN 回のやり取りで完了できます。

2.3.2 クライアントキャッシュ技術

データが大きすぎてメモリに完全に収まらない場合、ホット データとコールド データが明確に分離されており、データの適時性に対する要件が高くない場合は、通常、あらゆる種類のビジネスでクライアント キャッシュが使用されます。クライアント キャッシュの集中実装は、フィーチャ サービス拡張の一部です。一般的なキャッシュ プロトコルとその使用方法については詳しく説明しません。オンライン機能システムのビジネスの観点から、いくつかのトピックに関する考えと経験を紹介します。

インターフェースの一般化 - キャッシュロジックとビジネスの分離

機能システムはさまざまなビジネス ニーズを満たす必要があり、そのインターフェイスは充実している必要があります。データの意味の観点からは、ユーザークラス、マーチャントクラス、製品クラスなどがあります。データ転送プロトコルの観点からは、Thrift と HTTP があります。メソッドの呼び出しの観点からは、同期と非同期があります。データ編成の観点からは、単一値、リスト、マップ、ネストなどがあります。優れたアーキテクチャ設計では、データ処理をビジネスから可能な限り分離し、各インターフェースの共通部分を抽象化し、実装を一度キャッシュし、複数のインターフェースを同時に再利用するメリットを享受する必要があります。以下では、同期インターフェイスと非同期インターフェイスを例として使用して、クライアント インターフェイスの一般化を紹介します。

同期インターフェースには 1 つのステップのみがあります。

1. サーバーにリクエストを送信し、結果を取得します。

非同期インターフェースは 2 つのステップに分かれています。

1. Future インスタンスを取得するためにサーバーにリクエストを送信します。
2. データを取得するには、Future インスタンスにリクエストを送信します。

同期インターフェースと非同期インターフェースのデータ処理は順序が異なるだけなので、各ステップの実行順序を整理するだけで済みます。キャッシュ導入後のデータ処理フローは次のように比較されます。

異なる色の処理ボックスは異なるリクエストを表します。非同期プロセスでは、データを取得するためにコンシューマーからの 2 つのリクエストが必要です。図に示すように、非同期プロセスでは、「キャッシュをサーバーデータで更新する」および「サーバーデータをキャッシュデータとマージする」という手順が 2 番目のリクエストで完了します。これは、すべての手順が最初のリクエストで完了する同期プロセスとは異なります。データ フローをこれらのサブステップに分割すると、同期と非同期はこれらのステップの異なる順序の組み合わせになります。したがって、キャッシュの読み取りと書き込み (検索キャッシュ、更新キャッシュ) の 2 つのステップを抽象化し、ロジックの残りの部分から分離することができます。

データ保存 - 時間は空間に先行し、クライアントとサーバーは分離されている

クライアントとサーバーの関係は、サーバーとデータベースの関係と同じです。実際、データ ストレージの圧縮の考え方はまったく同じです。具体的なデータ圧縮と保存戦略については、上記のデータ圧縮セクションで詳しく説明しました。ここでは主に次の 2 つの点について説明します。

アプリケーション シナリオが異なるため、クライアント側圧縮とサーバー側圧縮の目的は異なります。サーバー側圧縮の使用シナリオは、1 回限りの高スループット書き込みと、高同時実行性および低レイテンシの 1 つずつの読み取りです。主に、読み取り時の解凍時間とデータ保存時の圧縮率に重点を置いています。クライアント キャッシュは、データ ストレージ レイヤーの最上部に属します。読み取りと書き込みのシナリオは、高同時実行性と低レイテンシのローカル メモリ操作であるため、圧縮速度、解凍速度、データ サイズに対する要件が非常に高く、トレードオフが多くなります。

第二に、クライアントとサーバーは完全に独立した 2 つのモジュールです。率直に言うと、クライアント コードを記述することはできますが、それはサービスの一部ではなく、呼び出し元サービスの一部です。クライアントのデータ圧縮は、サーバーのデータ圧縮から可能な限り分離する必要があります。便宜上、両者のデータ形式を結合しないでください。サーバーとのデータ通信形式は、サーバーとデータベース間の通信と同様に、独立したプロトコルとして理解する必要があります。データ通信形式は、データベースの保存形式とは関係ありません。

メモリ管理 - キャッシュと世代リサイクルの矛盾

キャッシュの目的は、キャッシュヒット率を向上させるために、ホットデータ（頻繁にアクセスされるデータ）をメモリ内に保持することです。 JVM ガベージ コレクション (GC) の目的は、参照を失ったオブジェクトのメモリ領域を解放することです。両者の目標は似ているように見えますが、微妙な違いがあるため、同時実行性の高いシナリオでは共存することが困難です。キャッシュを削除すると大量のメモリガベージが生成され、フル GC が非常に頻繁に発生します。この矛盾はクライアントに限定されず、すべての JVM ヒープ キャッシュが直面する共通の問題です。シナリオを詳しく見てみましょう。

リクエストによって生成されたデータは継続的にキャッシュに追加されるため、QPS が高い場合は Young GC が頻繁に発生し、キャッシュによって占有されているメモリが新しい世代から古い世代に継続的に移動します。キャッシュがいっぱいになると、Least Recently Used (LRU) アルゴリズムを使用してコールド データが削除され、キャッシュから追い出されてガベージ メモリになります。残念ながら、Young GC が頻繁に行われるため、多くのコールド データが Old Generation に入ります。Old Generation のキャッシュを削除すると、Old Generation にガベージが生成され、Full GC がトリガーされます。

キャッシュ削除メカニズムが新世代の GC 戦略目標と一致していないため、キャッシュ削除によって旧世代で大量のメモリ ガベージが生成されることが分かります。また、ガベージ生成の速度はキャッシュ サイズとはほとんど関係がなく、新世代の GC 頻度とヒープ キャッシュの削除速度に関係しています。どちらの指標も QPS と正の相関関係にあります。そのため、ヒープ内キャッシュは古い世代につながるガベージ パイプになっているようです。QPS が高くなるほど、ガベージの生成が速くなります。

したがって、高同時実行キャッシュ アプリケーションでは、JVM のバンド メモリ管理の使用は避ける必要があります。言い換えると、GC メモリ回復メカニズムのオーバーヘッドと効率は、高同時実行シナリオでのメモリ管理要件を満たすことができません。 JVM 仮想マシンの必須メモリ管理制限により、オブジェクトをシリアル化してヒープ外に保存し、JVM メモリ管理をバイパスすることができます。たとえば、Ehcache や BigMemory などのサードパーティのテクノロジがこれを行います。または、JVM の基礎となる実装を変更して (Taobao が以前行ったのと同様に)、ヒープ内ストレージを実現し、GC を回避します。

3. 結論

この記事では、主にオンライン機能システムの技術的なポイントをいくつか紹介します。高同時実行性、高スループット、ビッグデータ、低レイテンシというシステム要件から始めて、実際の機能システムをいくつかプロトタイプとして取り上げ、オンライン機能システムの設計アイデアをいくつか提案します。前述のように、機能システムの境界はデータの保存と読み取りに限定されません。データ インポート ジョブのスケジュール設定、リアルタイム機能、機能の計算と生成、データ バックアップ、災害復旧などはすべて機能システムの一部と見なすことができます。この記事は、オンライン機能システムに関する一連の記事の第 1 回目です。当社の機能システムも、需要と課題に応じて常に進化しています。今後、より多くの実践的な経験を皆さんと共有していきます。一人の意見に抜けや偏りがあるのは仕方がないが、他の山の石を使って翡翠を磨くこともできる。建築家が自分の仕事に向き合う上で、何かのヒントになればいいなと思う。