ロック粒度の厚さと時空損失が入れ替わる

1 空間が時間に置き換わる場合

1.1 Redis ユーザーグループ電流リミッターとユーザー定義電流リミッター

Redis ユーザー グループのスロットルとユーザー定義のスロットル: ユーザー スロットルまたはカスタム スロットルに Redis を使用するということは、Redis データベースを使用してユーザー アクセス制限を維持することを意味します。電流制限は、カウンター、スライディング ウィンドウ、トークン バケットなどのアルゴリズムを通じて実装できます。ユーザー グループの電流制限は特定のユーザー グループに制限を設定するのに対し、ユーザー定義の電流リミッターは各ユーザーにカスタム制限を設定します。

ユーザー グループの電流制限とユーザー定義の電流制限: Redis でユーザーの電流制限ステータスを維持するには追加のメモリ領域が必要ですが、ユーザーが電流制限のしきい値に達したかどうかをすぐに確認できます。

1.2 seckill シナリオでの、複数のサブインベントリ スキームの設定と 1 つの合計インベントリ スキームのみの設定の比較

フラッシュ セール シナリオにおけるデータベース行ロック ソリューション: 同時実行性の高いフラッシュ セール シナリオでは、在庫データの一貫性を確保するためにデータベース行ロックを使用するのが非常に一般的な方法です。ただし、これは在庫を差し引くために 1 つずつリクエストすることしかできず、同時実行パフォーマンスはあまり良くありません。

したがって、データ テーブルにさらにいくつかのサブ インベントリを設定できます。初期合計は総インベントリと同じなので、リクエストが来たときにロード バランシング戦略を通じて差し引かれるサブ インベントリを選択できます。サブ在庫は 0 に差し引かれ、閉じられます。この在庫のルーティング。

これは空間と時間を交換する実践でもあります。

1.3 マルチサービスでのマルチメッセージキューまたはシングルメッセージキューの使用

マルチサービスで複数のメッセージ キューまたは単一のメッセージ キューを使用する: マルチサービス システムでは、複数のメッセージ キューを使用すると、異なるビジネス プロセスを分離し、システムの拡張性と保守性を向上させることができます。単一のメッセージ キューの使用は、ビジネスが比較的単純なシナリオ、またはメッセージのグローバルな順序を保証する必要があるシナリオに適しています。

• マルチサービスで複数のメッセージ キューまたは単一のメッセージ キューを使用する: 複数のメッセージ キューを使用すると、これらのキューを維持するためにより多くのメモリとストレージ スペースが必要になりますが、異なるビジネス プロセスをより適切に分離し、同時使用の速度を向上させることができます。

1.4 jdk1.7 の HashMap セグメント ロックと 1.8 のスロット ロック

JDK 1.7 の HashMap のセグメント ロックと JDK 1.8 のスロット ロック: JDK 1.7 では、ConcurrentHashMapセグメント ロック テクノロジを使用してデータを複数のセグメントに分割し、各セグメントは独立してロックされます。このようにして、異なるスレッドが異なるセグメントを同時に操作できるようになり、同時実行性が向上します。JDK 1.8 では、ConcurrentHashMapセグメント ロックは使用されなくなりましたが、スロット ロック () が使用されsynchronized、リンク リストの検索パフォーマンスを最適化するために赤黒ツリーが導入されました。

• JDK 1.7 の HashMap セグメント ロックと JDK 1.8 のスロット ロック: セグメント ロックまたはスロット ロックを使用すると、ロックの状態を維持するために追加のメモリが必要になりますが、同時ConcurrentHashMap実行性と検索パフォーマンスを向上させることができます。

1.5 Redis は断片化カウンターを実装します

方法: 複数の Redis インスタンスに複数のサブカウンターを設定する 各リクエストは、負荷分散戦略を使用して特定のカウンターを増加させ、要約が必要な場合にはこれらすべてのカウンターを合計することができます。

利点: カウンターを複数の Redis インスタンスに分散すると、単一の Redis インスタンスへの負荷が効果的に軽減され、全体的な同時処理能力が向上します。各 Redis インスタンスはリクエストを並行して処理できるため、スループットが向上します。
短所: 複数のカウンタはより多くのメモリ領域を占有し、ネットワーク IO の回数が増加し、一貫性の問題が発生する可能性があります。

時間を空間と交換する2つのケース

スペースのための時間は一般的な最適化戦略であり、より多くの時間を費やしてスペースを節約することを意味します。これは、組み込みシステム、モバイル デバイス、その他のリソースに制約のある環境など、リソースに制約のある環境でよく使用されます。一般的な使用シナリオをいくつか示します。

1. データ圧縮: データを圧縮するとストレージ容量が節約されますが、圧縮と解凍に必要な時間が増加します。

2. アルゴリズムの最適化: より単純なアルゴリズムを使用してスペースを節約しますが、時間がかかる場合があります。たとえば、余分なスペースを使用する並べ替えアルゴリズム (クイックソートなど) ではなく、余分なスペースを使用しない並べ替えアルゴリズム (バブル ソートなど) を選択します。

3. オンデマンド計算 (シングルトン モードでの遅延読み込み) : 計算は、事前に計算されて保存された結果ではなく、データが必要なときに実行されます。たとえば、フィボナッチ数列の値は、数列全体を事前に計算して保存するのではなく、必要なときに計算できます。

4. 単純なデータ構造を使用する: 配列やリンク リストなどの単純なデータ構造を使用してスペースを節約しますが、検索や操作に必要な時間が長くなる可能性があります。

5. データベースの正規化: データベースの正規化によってデータの冗長性が減り、ストレージ スペースが節約されますが、クエリの複雑さとクエリ時間が増加する可能性があります。

6. オンライン処理: データを処理する場合、入力ストリームから直接読み取り、処理後に直接出力し、中間結果は保存しません。これによりスペースが節約されますが、データを再処理する必要がある場合は、最初からやり直す必要があります。

空間時間は常に適用できるわけではないことに注意してください。場合によっては、スペースがより重要なリソースになることもありますが、別の場合には、時間がより重要なリソースになることもあります。したがって、Time for Space 戦略を使用するかどうかを決定するときは、特定のアプリケーション シナリオと要件に従って比較検討する必要があります。