問題インデックス
Luaスクリプト機能はサポートされていますか？
サポートされています。標準アーキテクチャとクラスタアーキテクチャの両方で、Lua機能がデフォルトで有効になっています。クラスタアーキテクチャでLuaスクリプトを使用する場合、スクリプト内で操作するKeyが同じSlot内にあることを確認する必要があります。そうでない場合、実行に失敗する可能性があります。
キャッシュ無効化サブスクリプションイベントはサポートされていますか？
サポートされています。分散キャッシュデータベースはKey有効期限切れイベントのサブスクリプション通知をサポートしており、PSUBSCRIBEコマンドで__keyevent@*__:expiredチャンネルをサブスクライブすることで、キャッシュ失効イベントを監視できます。
大キーとホットキーとは何ですか？検出と処理方法は？
大キー
大きなKeyとは、データ量が多いKeyを指します。データ構造ごとの判断基準は以下の通りです：
|
String | Value サイズが10KBを超えます。 |
Hash、List、Set、ZSet | 要素数が5,000個を超えます。 |
大きなKeyの主な影響：
メモリ不均等：クラスタアーキテクチャでは、大きなKeyが存在するノードのメモリ使用率が著しく高くなり、データの偏りが発生します。
リクエストブロッキング：大きなKeyに対してDEL、GETALLなどの操作を実行すると、Redisのシングルスレッドがブロックされ、他のリクエストがタイムアウトする可能性があります。
同期中断：マスタースレーブ同期中に大きなKeyの書き込みがあると、同期バッファのオーバーフローを引き起こし、全量同期が発生する可能性があります。
ホットキー
ホットKeyとは、頻繁にアクセスされるKeyを指します。判断基準：単一KeyのQPSがインスタンス全体のQPSの10%を超える場合、またはアクセス頻度が他のKeyを大幅に上回る場合です。ホットKeyの主な影響：
クラスタアーキテクチャでは、ホットKeyが存在するシャードのCPU使用率が高くなる傾向があります。
ホットKeyがデキューまたは期限切れになる際に、リクエストのブロッキングが発生する可能性があります。
大キーとホットキーを検出する方法は？
コンソールでの大きなKey分析：インスタンス詳細ページの診断分析で、全Keyをワンクリックでスキャンし、大きなKeyを識別できます。
DBbrainインテリジェント診断：大きなKeyとホットKeyを自動的に検出し、メモリ使用量やアクセス頻度などの詳細情報を表示します。
コマンド方式：redis-cli --bigkeysを使用して大きなKeyをスキャンします（注意：このコマンドはすべてのKeyを走査するため、スレーブノードまたは低ピーク時に実行することをお勧めします）。
対処方法：
大きなKeyの分割：大きなStringをビジネス次元に基づいて複数の小さなKeyに分割します。大きなHashを複数の小さなHashに分割します。
ホットKeyの分散：ホットKeyにビジネスプレフィックスを追加し（例：key_1、key_2、key_3）、異なるSlotに分散します。ビジネス層でローカルキャッシュを追加します。
タイムリーなクリーンアップ：不要になった大きなKeyを速やかに削除し、メモリを解放します。
キャッシュ削除ポリシーの設定方法は？
分散キャッシュデータベースコンソールにログインし、インスタンス詳細ページのパラメータ設定で、maxmemory-policyパラメータを使用してキャッシュ削除ポリシーを設定します。デフォルト値はnoeviction（削除しない）です。ビジネスシナリオに応じて適切なポリシーを選択することをお勧めします： |
volatile-lru
| 有効期限が設定されたKeyから、最も使用頻度の低いものを淘汰します。 |
allkeys-lru
| すべてのKeyから、最も使用頻度の低いものを淘汰します。 |
volatile-ttl
| 有効期限が設定されたKeyから、まもなく有効期限が切れるものを淘汰します。 |
noeviction
| 淘汰を行わず、メモリが満杯の場合は書き込みに失敗します（デフォルト）。 |
インスタンスのメモリが満杯で書き込みに失敗した場合の対処方法は？
インスタンスのメモリ使用量が上限に達し、かつ削除ポリシーがnoeviction（デフォルト）の場合、すべての書き込みリクエストはOOM（Out of Memory）エラーを返します。対処手順は以下の通りです：
ステップ1：現在の削除ポリシーを確認する
コンソールでmaxmemory-policyパラメータを確認します。デフォルトのnoevictionの場合、メモリが満杯になるとシステムはKeyを自動的に削除しないため、手動で介入する必要があります。
ステップ2：短期的な応急処置：不要なデータをクリーンアップする
SCANコマンドを使用して、既知の不要なKeyを走査してクリーンアップします。
ビジネスで一部のコールドデータの消失が許容される場合、一時的に削除ポリシーをallkeys-lruまたはvolatile-lruに変更し、システムが最も使用頻度の低いKeyを自動的に削除するように設定できます。
ステップ3：長期的な解決策：メモリ使用量を分析する
コンソールの大規模Key分析機能を使用して、メモリ使用量が最も多いKeyを特定し、最適化してください。
大量のKeyに有効期限（TTL）が設定されていないかどうかを確認し、一時的なデータに対してTTLを補完設定してください。
データ量が確かに現在の仕様容量を超えている場合は、オンライン拡張操作を実行してメモリ上限を引き上げてください。
削除ポリシー選択の推奨事項：
|
純キャッシュシナリオ（データ損失許容） | allkeys-lru
|
キャッシュと永続化の併用 | volatile-lru
|
データ損失不可 | noeviction（容量アラートと拡張を併用）
|
有効期限を設定したキーがすぐに削除されないのはなぜですか？
RedisのKey有効期限クリーンアップは「遅延削除＋定期スキャン」という二重メカニズムを採用しているため、Keyは有効期限切れ後もすぐにはメモリから削除されません：
遅延削除：Keyは有効期限切れ後、次回アクセスされたときにのみチェックされ削除されます。もしKeyが有効期限切れ後、誰にもアクセスされなければ、そのままメモリを占有し続けます。
定期スキャン：Redisは100msごとに、有効期限が設定されたKeyをランダムに抽出してチェックし、その中で期限切れとなったものを削除します。これは、期限切れKeyのクリーンアップにランダム性と遅延が存在することを意味します。
よくある質問：
Q：なぜDBSIZEを実行して確認したKey数が予想より多いのですか。
有効期限切れ後も遅延削除や定期スキャンにまだヒットしていないKeyは、引き続きDBSIZEにカウントされます。これらのKeyは、その後アクセスされた際に削除されるか、次回の定期スキャンでクリーンアップされるため、業務ロジックには影響しません（GETで有効期限切れのKeyを取得した場合はnilが返ります）。
Q：大量のKeyが同時に期限切れ（集中期限切れ）になった場合、どのような影響がありますか。
大量のKeyに同じ有効期限が設定されている場合、期限到来時に定期スキャンスレッドが大量の期限切れKeyを集中的に処理する必要があり、CPU使用率が短時間上昇したり、リクエスト遅延のジッターを引き起こす可能性があります。有効期限にランダムなオフセットを追加することをお勧めします：
EXPIRE key (3600 + random(0, 300))
Q：从节点上为什么能看到已过期的Key。
从节点は期限切れのKeyを自発的に削除せず、マスターノードからDEL命令が送信された後にのみ削除を実行します。そのため、从节点でDBSIZEまたはSCANを実行すると、期限切れではあるがまだ削除されていないKeyが表示される場合があります。これはRedisのマスタースレーブレプリケーションにおける設計上の動作であり、業務上の読み取りには影響しません（Redis 4.0以降のバージョンの从节点は、読み取り時にTTLをチェックしてnilを返します）。
高リスクコマンドを無効にする理由と設定方法は？
高リスクコマンドとは、データ損失や深刻なパフォーマンス低下を引き起こす可能性のあるRedisコマンドを指します。分散キャッシュデータベースは、コンソール上で高リスクコマンドを無効化またはリネームすることをサポートしており、誤操作によるオンライン事故を防ぎます。
一般的な高リスクコマンドとそのリスク
|
KEYS *
| すべてのKeyを走査するため、インスタンスのKey数が多い場合、Redisが数秒以上ブロックされる可能性があります。 |
FLUSHALL
| すべてのデータベースの全データを消去し、復元できません。 |
FLUSHDB
| 現在のデータベースの全データを消去し、復元できません。 |
CONFIG SET
| 実行構成を動的に変更すると、サービスに異常が発生する可能性があります。 |
無効化方法
コンソールにログインし、インスタンス詳細ページのパラメータ設定に進み、disabled-commandsパラメータを見つけて、無効化するコマンド名を追加します（複数のコマンドはカンマで区切ります）。設定後、クライアントが無効化されたコマンドを実行すると、エラーメッセージが表示されます。具体的な操作については、disable-command-listによるコマンド無効化の設定をご参照ください。 代替案
SCANでKEYS *を置き換えることで、カーソルによるバッチ走査をサポートし、メインスレッドをブロックしません。
データをクリーンアップする必要がある場合は、直接FLUSHALLを実行するのではなく、バックアップから新しいインスタンスに復元して検証してください。
設定変更は、CONFIG SETではなく、コンソールのパラメータ設定機能を通じて統一的に行われます。
アカウントを誤って削除した場合やパスワードを忘れた場合の対処方法は？
アカウントの誤削除：コンソールにログインし、対象インスタンスのアカウント管理ページに移動し、アカウントを再作成してください。
パスワードを忘れた場合：アカウント管理ページで該当するアカウントを見つけ、パスワードのリセット操作を実行してください。
注意：
パスワードをリセットすると、旧パスワードを使用している接続が中断されます。業務の低ピーク時に操作し、事前に関係者に通知してください。
クラスタアーキテクチャのハッシュアルゴリズムはどのようなものですか？
クラスタアーキテクチャのHashアルゴリズムはコミュニティのRedis Clusterと一致しており、CRC16ハッシュアルゴリズムを採用しています：
HASH_SLOT = CRC16(key) mod 16384
すべてのKeyはこのアルゴリズムによって16384個のハッシュスロットに均等に分散され、その後、各シャードが対応するスロットを管理します。
標準アーキテクチャでselect 0 - 15を使用する場合、別々のインスタンスを申請する必要がありますか？
不要です。標準アーキテクチャはデフォルトで16個のデータベース（DB 0 - DB 15）をサポートしており、1つのインスタンスで複数データベースの要件を満たすことができます。クラスタアーキテクチャはProxyを通じて最大256個のデータベースをサポートします。
Pipelineとは何ですか？どのように使用しますか？
Pipeline（パイプライン）は、Redisが提供するコマンドを一括実行するためのメカニズムです。複数のコマンドをまとめて一度にサーバーへ送信することで、ネットワーク往復回数（RTT）を削減し、バッチ操作のスループットを向上させます。
性能比較
|
逐次実行 | ≈ 1000ms（1000回のネットワーク往復） |
Pipeline（100件ごと） | ≈ 10ms（10回のネットワーク往復） |
使用例
import redis
r = redis.Redis(host='<インスタンスアドレス>', port=6379, password='<パスワード>')
pipe = r.pipeline(transaction=False)
for i in range(1000):
pipe.set(f'key:{i}', f'value:{i}')
results = pipe.execute()
使用上の注意事項
1. 単一バッチサイズの制御：各Pipelineには100～500件のコマンドを含めることを推奨します。コマンドが多すぎると、サーバーが一度に大量のデータを返すことになり、過剰なメモリを消費したり、帯域幅制限を引き起こしたりする可能性があります。
2. 非原子性：Pipelineは単なる一括送信であり、原子性を保証しません（途中でいずれかのコマンドが失敗しても、他のコマンドはロールバックされません）。原子性操作が必要な場合は、トランザクション（MULTI/EXEC）を使用してください。
3. クラスタアーキテクチャの制限：クラスタアーキテクチャでは、Pipeline内のコマンドはProxyによって自動的に異なるシャードへルーティングされるため、ビジネス側でSlot分布を意識する必要はありません。ただし、コマンドの順序性を保証する必要がある場合は、同じPipeline内のコマンドが同じKeyにアクセスすることを推奨します。
4. タイムアウト設定：バッチコマンドの全体実行時間は長くなる可能性があるため、クライアントの読み取りタイムアウト時間を適切に長くすることを推奨します。
5. 帯域幅リスクの注意：Pipelineの一括返信により、出力トラフィックが瞬間的に急増する可能性があります。インスタンスで出力トラフィック過多のアラートが発生した場合は、単一Pipelineのコマンド数を減らすか、バッチ操作を複数の時間帯に分散して実行することを推奨します。