テクノロジーとインフラストラクチャ→Redis：インメモリソリューション

Redis： インメモリソリューション

1） Redisが適切である場合

• キャッシュ（読み取り/脇、TTL、 SWR）とセッション。
• カウンターとクォータ：レート制限、不正防止、キャンペーン制限。
• リーダーボード/評価（ZSet）、 「トップN」推奨。
• イベントキュー/バス（ストリーム/PubSub）、アウトボックス/受信トレイ、リトレイ。
• Idempotence （TTLのキー）、dup webhook。
• Geo（最寄りのポイントを検索）、Bitmap（フラグ、DAU）。
• エイリアス/トークンと短命の承認キャッシュ。

2）データ構造と適用時期

文字列：値/カウンタ（'INCRBY'）、 idempotentキー。
ハッシュ：プロファイル/コンフィギュレーションの集計、「軽量」オブジェクトの保存。
リスト：単純なキュー（ただし、リプレイ/オフセットセマンティクスなし）。
Set：ユニークな要素、重複排除。
ZSet：速度によるソート（リードボード、TTLカレンダー-「延期」イベント）。
ストリーム：コンシューマーグループと安定したキュー、'XREADGROUP'/リプレイ-Webhook、 CDC、リトレイ用。
Geo： 「GEOADD/GEORADIUS」-最寄りのポイント/商人。
ビットマップ/ビットフィールド：フラグのシリーズ（日ごとのログイン、DAU/WAU）。
HyperLogLog： Approximate Unique （UU）はメモリ上で安価です。
Bloom/Cuckoo（モジュール）：迅速な可用性チェック、ソースに「MISS」を削減します。

• RedisJSON （JSONドキュメント）、RediSearch（インデックス/検索）、RedisBloom（確率構造）、TimeSeries（メトリック/集計）。

3）キー、TTL、メモリポリシー

tenant:{t}:domain:{d}:{entity}:{id}:v{schema}    region={R}    currency={C}    lang={L}

バージョン管理（'vN'）には、意味のある寸法（地域/通貨/言語/テナント）のみが含まれます。
テナントごとのキースペースを分離します。

• TTL行列（sec/min/hr）を使用し、スタンピードを避けるためにジッタ（± 10-20％）を追加します。
• ホットキーの場合-リフレッシュアヘッドとシングルフライト（1つのリーダーの更新）。

• 'allkeys-lru/lfu'はTTL依存なしの共有キャッシュです。
• 'volatile-lru/lfu'-TTLのキーのみ。
• 'noeviction'-オーバーフロー時の書き込み失敗（重要なキュー/カウンタの方が安全）。
• スクリプトを選択し、常に'evicted_keys'を監視します。

4）トランザクション、パイプライン、スクリプト

パイプライン：RTTを削減します。、グループ10-100チーム。
トランザクション（MULTI/EXEC）-読み取りを分離せず、バッチをアトミックに実行します。
最適なロック：'WATCH key'→MULTI/EXEC→check。
Luaスクリプト：サーバー側の原子ロジック（レート制限、ロック、複合操作）。

5）キューとバス： リストとストリーム

リスト+'BRPOP'-シンプルですが、消費者グループ、オフセット/リプレイ、ドロップに対する弱い抵抗はありません。
ストリーム：'XADD→XREADGROUP→XACK'、 retry-deadletter （N分では撮影されません）、キーで分割。PSP/KYC Webhook、繰延支払い/通知に推奨されます。

優先順位キュー：優先順位でいくつかのストリーム、消費者は最初の場所で高いから「吸う」。
繰延タスク：ZSetここでscore=timestamp；定期的な'ZRANGEBYSCORE' ≤現在→Streamに転送されています。

6）高可用性と拡張性

Replication： master→replica（読み取りスケール）。
Sentinel：自動フェイルオーバマスター、検出、クライアントURI。
Redisクラスター：16384スロットシャーディング、水平スケールアウト。'{order： 123}'ハッシュタグで複数の構造を使用するキーをラップします。

• キャッシュ/セッション-クラスタ/レプリカの場合、'クライアントサイドハッシュ'SDKがサポートされています。
• キュー/ストリームの場合-クロススロット操作を最小限に抑えます。ドメインキーによるパーティション。

7）持続性： RDB、 AOFおよびバックアップ

RDB（スナップショット）：より速く、より経済的。最後の秒/分の損失の危険。
AOF（ジャーナル）：損失が少ない；'everysec/always'モード。AOF圧縮と定期的な再パッケージ化。
ハイブリッド：RDB+AOF→高速回復+中程度の損失。
バックアップ：オブジェクトストレージへのAOFのスナップショットとコピー；定期的に回復をチェックしてください。

クリティカルキュー/idempotencyの場合は、AOF 'everysec'+レプリケーションを選択します。

8）安全性とコンプライアンス

AUTH/ACL：アプリケーションごとの役割、「危険」コマンドの禁止（'FLUSHALL'、 'KEYS'）。
クライアント・サーバおよびノード間リンクへのTLS；egress-IPを修正しました。
ネットワークセグメンテーション：プライベートサブネット、SG/NACL；必要なサービス/名前空間からのみアクセスできます。
秘密を記録しないでください。RedisのPAN/PII-トークン/デリバティブのみ。
キーコマンド：'KEYS'を避ける-'SCAN'を使用します。

9）観察可能性およびSLO

• レイテンシー（P95/P99）、 'instantaneous_ops_per_sec'、 'connected_clients'。
• ヒット率、 、 。
• メモリ：使用、フラグメンテーション比、RSS、アロケータの統計。
• レプリケーションラグ、AOF/RDB周波数とサイズ、フォーク時間。
• ストリーム：PEL（保留中のエントリーリスト）、配信遅延、再試行数。

• Redis P99の操作≤ 5-10ミリ秒です。
• Evictions ≤ 1 ％/hour（キャッシュスペース）。
• ストリームデリバリーP 99 ≤ 500％、再試行レート<2％。

10） FinOpsとリソース計画

メモリは高価です：$/GB-month RAMとorigin/DBへのリクエストの保存を測定します。
値の圧縮を有効にする>1-2 KB （CPUを参照）。
LFUは、より少ないボリュームでより良いヒットを与えることができます。
画像/大きなブロブの場合-Redisではありません：CDN+オブジェクトストレージを使用します。

11） iGaming/fintechのパターン

11.1料金制限（Lua）

アイデア：ウィンドウキー+TTLの'INCRBY'；Luaは原子的に限界をチェックし、増加します。

lua
-- KEYS[1]=key ARGV[1]=limit ARGV[2]=ttlSec ARGV[3]=inc local cur = redis. call('INCRBY', KEYS[1], ARGV[3])
if cur == tonumber(ARGV[3]) then redis. call('EXPIRE', KEYS[1], ARGV[2]) end if cur > tonumber(ARGV[1]) then return {0, cur} else return {1, cur} end

11.2 idempotenceを要求する

キー'idemp： {request_id}'とTTL 24h、 value-result/status。操作を行う前に、私たちは存在を確認します。

11.3リーダーボード

'ZINCRBY leaderboard： game： {g} score user： {u}'→'ZREVRANGE……WITHSCORES'。
地域/テナント別の上位Nの場合-個々のZSetまたはプレフィックス。

11.4 PSP Webhooksキュー

'XADD psp： webhooks……'→コンシューマーグループ'XGROUP CREATE psp： webhooks g1$'。
PELスキャン（'XPENDING'→'XCLAIM'）による「スタック」メッセージのリトレイ。

11.5遅延支払い

ZSet 'payout： due' （score=epoch）→作業者は、重複排除を使用して終了したアイテムをStream 'payout： exec'に定期的に転送します。

11.6アンチフラウドメーター

'PFADD'（ユニーク）+'INCR'（強度）+geo/ASNタグの組み合わせ。手動検証のトリガー。

12）記憶および性能を使用

クライアント接続プール；RTT （keep-alive）を減らす。
コマンドのパックにパイプラインを設定します。
大きなキー（'MEMORY USAGE'、 'SCAN'）を見る-オブジェクトを分割することをお勧めします。
少数のフィールドを持つハッシュは、多くの個々のキーよりも経済的です。
テストによって利益が確認された場合、io-threads （read-heavy）を有効にします。
prodの頻繁な'FLUSHDB/ALL'を避けて下さい；安全な削除のためにプレフィックスと'UNLINK'を介して管理します。

13）複数のテナントおよび分離

個々のクラスタ/インスタンスまたはテナントごとの論理DB（負荷が小さい場合）。
キー/メモリクォータ、ACLの分割。
名前空間によるキーとメトリックの接頭辞。

14）ロックおよび一貫性

SET key val NX PX=ttl-単純なミューテックス。
Redlock：慎重に使用してください。分散した重要なトランザクションの場合は、「真実の源」（DB/レジャー）とidempotent操作に頼ることをお勧めします。
「長い」ロックの代わりに原子演算とLuaを好む。

15）アンチパターン

大きなブロブ/イメージのストレージ-RAMとネットワークの過負荷。
Redisでのみ財務不変量（貸借対照表）。
PRODの「KEYS」と「世界をスキャンする」。
TTL/ジッタなし-有効期限にドッグパイル。
重要なキューの「allkeys-」ポリシー→圧力でのデータ損失。
クォータと優先順位のない1つのインスタンスにキュー、キャッシュ、セッションをミキシングします。
クラスタ内のさまざまなスロットのキーで動作するLuaスクリプト。

16）実装チェックリスト

1.ロールの定義：キャッシュ/セッション、キュー/ストリーム、カウンタ/リミット-インスタンス/クラスタへのポスト。
2.タスクのmaxmemory-policyを選択します。制限を設定し、立ち退きを監視します。
3.キーの名前付け、回路のバージョン、TTLマトリックス+ジッタ；上のキーのための単一飛行。
4.キューの場合-ストリーム（グループ、リトレイ、DLQ）、延期の場合-ZSet+転送。
5.HA： replication+SentinelまたはRedis Cluster；クライアントのフェイルオーバーを確認します。
6.持続性：スクリプトの下のRDB/AOF；定期的なバックアップとリカバリテスト。
7.セキュリティ：ACL、 TLS、プライベートネットワーク、危険なコマンドの禁止。
8.観測可能性：レイテンシ、ops/sec、メモリ、立ち退き、レプリケーションラグ、ストリームPEL。
9.FinOps：メモリプロファイル、大きなキー、圧縮、LFU；大きな塊のためにRedisを避けてください。
10.パターン文書（rate-limit、 idempotency、 leadboards）および負荷テスト。

［結果］

Redisは、キャッシュ、キュー、カウンター、リードボード、ジオナイフ、確率構造など、スピードの「多機能スイスナイフ」です。その強みは、データ構造の正しい選択、TTL/障害規律、操作の原子性、および十分に考え抜かれたHA/持続性と観測性にあります。重要な不変量（お金、会計）を「真実の源」に残しながら、ミリ秒と高いRPSが重要であるRedisを使用してください。これにより、プラットフォームは高速で信頼性があります。